SEO pentru JavaScript: asigură-te că link-urile supraviețuiesc procesului de randare
Google randează JavaScript folosind un Chromium evergreen. Problema este rară legată de procesul de randare în sine. Este vorba despre link-uri care nu devin niciodată ancore și despre pagini care depind de o stare pe care un crawler nu o are.
Echipa de cercetare ArchiLinks ·
Ce vede un crawler
Googlebot folosește un Chromium evergreen din mai 2019. Aceasta a rezolvat întrebarea dacă poate executa JavaScript modern.
Riscurile practice sunt cele mai vechi: randarea are loc după crawlare și poate fi întârziată, conținutul din spatele clicurilor sau al autentificărilor nu apare niciodată, iar un link construit dintr-un handler onclick pe un div nu este un link. Înainte de a verifica backlink-urile către paginile site-ului pe care le-ai mutat recent pe un front-end React, confirmă că acele pagini își afișează conținutul în răspunsul brut sau în HTML-ul randat.
SSR, SSG, CSR: ce se schimbă pentru link-uri
| Abordare | Conținut în primul răspuns | Link-uri interne ca ancore | Potrivit pentru |
|---|---|---|---|
| SSR (Next.js, Nuxt) | Da | Da, dacă folosești ancore reale | Pagini publice cu date care se schimbă |
| SSG sau prerender | Da | Da | Documentație, bloguri, pagini de marketing |
| Aplicație single-page CSR | Nu, schelet gol | Doar după randare | Tablouri de bord protejate prin autentificare |
| Hybrid (SSR pentru homepage, CSR pentru aplicație) | Pe rută | Pe rută | Majoritatea produselor cu o parte publică |
Testul unu: HTML brut versus HTML randat
Dacă linkurile principale apar în primul răspuns, problema este rezolvată. În caz contrar, compară cu o randare headless.
# raw response: are the links there?
curl -s https://new-shop.com/guides/ | grep -o '<a [^>]*href="[^"]*"' | head -20
# rendered DOM with headless Chrome
chrome --headless --dump-dom https://new-shop.com/guides/ | grep -c '<a '
Aici intervin linkurile externe
Un bug de randare îți ascunde conținutul. Nu șterge linkurile pe care alte site-uri ți le-au oferit deja.
După o migrare către Next.js, Vite sau un CMS headless, rulează toppages pentru gazdă și testează cele mai 20 de URL-uri cel mai des linkate pentru status, canonical și conținut vizibil. Fă-o primul. Dacă o pagină cu 40 de domenuri care linkuiesc returnează un schelet gol sau un 404 client-side, repar-o înainte de orice altceva, deoarece acolo ajunge autoritatea ta. Pagina despre echitatea internă versus externă arată cum să compari această listă cu linkurile tale interne, iar checklist-ul de migrare integrează testul într-un plan de lansare.
Framework-urile contează mai puțin decât disciplina. Express cu un motor de șabloane, un temă WordPress și un Next.js app router pot servi toate linkuri crawlabile. Fiecare poate eșua și dacă o echipă livrează ancore care există doar după un click.
Listă de verificare pentru linkuri și randare
- Navigarea și paginare folosesc
<a href>, nu gestionari de evenimente pe alte elemente. - Fiecare rută returnează un cod de stare real. Ecranele de 404 soft trebuie să returneze 404.
- Un
noindexsau canonical injectat prin JavaScript se potrivește cu cel din răspunsul serverului. - Conținutul de rezervă din primul răspuns este pagina reală, nu un spinner care ar putea fi indexat de Google.
- Codul de autentificare nu redirecționează crawlerele pe rutele publice.
- Fișierele CSS și JS necesare pentru redare nu sunt blocate în robots.txt.
- Încărcarea leneșă folosește IntersectionObserver sau atribute native de încărcare, nu evenimente de derulare.
Analiza probelor din Search Console
Search Console răspunde la majoritatea întrebărilor privind redarea dacă accesezi raportul potrivit. Folosește Inspectarea URL-ului, apoi Vizualizează pagina indexată.
Compară trei aspecte: HTML-ul preluat de Google, captura de ecran și resursele paginii care nu s-au încărcat. O pagină care pare completă în browser, dar apare goală în captură, este de obicei blocată din cauza unei erori de script sau a unei resurse interzise, iar remedierea se face la nivel de build, nu de conținut.
Ține cont de întârziere. O modificare publicată astăzi va apărea în instrumentul de inspecție doar după ce Google va recrawlui URL-ul, ceea ce poate dura câteva zile.
Când merită SSR
Paginile publice care trebuie să se clasifice: da. Panourile de control: nu.
Dacă o rută trebuie să atragă trafic organic, servește conținutul în primul răspuns. Dacă este în spatele unei autentificări, renunță la complexitate. Alege pe bază de rută și nu pe bază de proiect, și documentează decizia astfel încât următorul developer să nu o anuleze.
- Folosește testul Rich Results și Inspectarea URL-ului pentru a compara output-ul redat.
- Testează cu testul live din Search Console după fiecare upgrade de framework.
Este necesară redarea pe server sau este suficient prerendering-ul?
Redarea pe server este opțională. Este o modalitate de a face ca primul răspuns să conțină ceea ce are nevoie un crawler. Multe site-uri publice ajung acolo cu prerendering, o construcție statică sau o redare pe server pentru paginile importante, și lasă părțile autentificate deoparte.
Să presupunem că paginile de produse și documentația sunt publice, în timp ce panoul de control este în spatele unei autentificări. Prerenderizează primul grup. Lasă panoul de control pe partea de client. Astfel, paginile publice își vor include link-urile în primul răspuns, iar panoul de control poate rămâne la fel de complex pe cât este necesar.
Prerendering-ul doar al paginii de start
Prerendering-ul paginii de start rezolvă prima căutare, dar lasă fiecare altă rută să aștepte browserul. Dacă pagina de start face link către pagini de categorie redate client-side, link-urile de pe acele pagini depind tot de redare. Verifică fiecare șablon pe care îl deții, nu doar poarta principală.
Păstrează o listă scurtă de rute publice cu metoda lor de redare. Lista va arăta lacunele mai rapid decât un raport de căutare.
Schimbă redarea pe server vizibilitatea locală
Redarea pe server poate modifica modul în care apare primul conținut, iar cititorii simt acest lucru. Nu face o pagină relevantă pentru o interogare locală de la sine. Acele semnale vin din conținutul paginii, detaliile afacerii și link-urile care indică către ea.
Tratează redarea ca pe modalitatea prin care acele semnale devin lizibile pentru un crawler și măsoară link-urile separat cu API-ul.
Aplicații Vite și React care servesc un singur shell
O construcție Vite care servește un singur shell HTML pentru fiecare cale pune toată munca pe client. O astfel de aplicație poate totuși să se clasifice pentru unele interogări, dar fiecare rută publică are nevoie de un plan: prerenderizeaz-o, red-o pe server sau acceptă pierderea și noteaz-o.
Înainte de a verifica backlink-urile pe rutele site-ului după o reconstrucție, decide cum primește fiecare rută publică conținutul său. Altfel, datele despre link-uri vor arăta link-uri externe aterizând pe pagini fără nimic în ele.
Testarea dacă o rută își afișează link-urile
Două teste răspund la majoritatea întrebărilor. Răspunsul brut arată ce primește un crawler înainte ca orice script să ruleze. DOM-ul redat arată ce construiește un browser ulterior. Un link care apare doar în al doilea caz este tot un link, dar depinde de faptul că redarea merge bine.
Citirea testului live din Search Console
Rulează testul live din Inspectarea URL-ului pe o rută pe rând. Uită-te la HTML-ul redat, apoi la lista de resurse care nu s-au încărcat. Un script blocat poate elimina un întreg bloc de navigare, iar pagina pare subțire fără a afișa nicio eroare vizibilă.
Repetă testul după un upgrade de framework, deoarece un nou implicit poate modifica dacă link-urile se redau înainte sau după rularea unui script. Ghidul pagini neindexate acoperă ce trebuie făcut când o pagină redată rămâne totuși în afara indexului.
Când o rută se redă, dar conținutul este un spinner
Fallback-ul din primul răspuns este mai important decât se așteaptă majoritatea echipelor. Un spinner sau un container gol înseamnă că pagina nu conține text pentru crawler în acel moment. Pune titlul, introducere și link-urile principale în primul răspuns, chiar dacă o listă detaliată se încarcă mai târziu.
Un fallback care este pagina reală poate rămâne simplu. Singura sa sarcină este să mențină conținutul până când restul ajunge.
Mutarea unui site client-side fără a-și pierde link-urile
Listează rutele cu link-uri externe
Rulează toppages pentru gazdă și notează primele 50 de URL-uri. Testează acele rute mai întâi, înainte de modificările de cod, astfel încât să știi ce trebuie să păstreze reconstrucția.
Compară output-ul brut cu cel redat
Pentru fiecare rută, verifică HTML-ul brut și DOM-ul redat în construcția veche și în cea nouă. Notează orice link care există în unul și nu în celălalt.
Înlocuiește handler-ele de click cu ancore
Transformă navigarea în ancore reale cu o adresă adecvată. Lucrările de viteză pot aștepta un sprint, în timp ce o ancoră lipsă costă ruta calea ei în site.
Repetă testul după lansare
O săptămână după lansare, rulează testul live pe aceleași rute și compară rezultatele cu cele anterioare. Diferențele arată unde a modificat reconstrucția output-ul.
Coduri de stare și redirect-uri într-o aplicație client-side
O aplicație single-page afișează adesea un ecran de ne-găsit în timp ce serverul returnează status 200. Google poate trata o astfel de pagină ca pe un soft 404, iar link-urile externe care indică către URL-ul lipsă nu te ajută mult. Remedierea aparține serverului.
Rute necunoscute care returnează totuși 200
Returnează un 404 real de pe server pentru orice rută care nu există și păstrează ecranul de ne-găsit din aplicație pentru vizitatorii care ajung printr-o rută client-side. Unde există un înlocuitor, trimite un 301 în schimb.
Verifică câteva adrese inventate pe gazda live după fiecare lansare. Codul de răspuns este ceea ce trebuie citit, nu pagina pe care o vezi în browser.
Redirect-uri care rulează în browser
Un redirect care se declanșează după încărcarea paginii, de exemplu citind un parametru URL în interiorul unui component, este un lucru diferit de un redirect de server. Un crawler poate indexa primul răspuns înainte ca redirect-ul să ruleze. Unde o rută s-a mutat definitiv, returnează un 301 de pe server și păstrează parametrii care modifică conținutul. Rețeta hărții de redirect arată cum să testezi acele reguli.
