Cum facem SEO pentru un site cu conținut JavaScript?

JavaScript este o componentă esențială în WEB-ul modern. Nevoile utilizatorilor devin tot mai complexe, tehnologia evoluează, astfel că majoritatea site-urilor încep să depindă din ce în ce mai mult de JavaScript, motiv pentru care tot mai multe site-uri îl folosesc.

Totuși, JavaScript nu are o reputație tocmai bună (în special în rândul SEO-iștilor), din cauza faptului că poate crea probleme de indexare, crawling și poate afecta viteza viteza de încărcare a site-ului.

Dacă nu știi foarte multe despre ce este și cum funcționează JavaScript, iată un articol care prezintă termenii și conceptele fundamentale. Deși GoogleBot este actualizat pentru a citi mai rapid și într-un procent mult mai mare a conținutului JS, încă există anumite limitări. Din acest motiv, este esențial să înțelegem limitările browserelor și a motorului de căutare pentru a le ajuta să citească mai ușor conținutul și să-l poată reda (actualizat) mai rapid utilizatorilor.

Continut

#Care sunt cele mai frecvente aspecte în cazul cărora apar probleme?
#Cum putem optimiza conținutul astfel încât să fie indexat rapid și complet?
#Ce teste trebuie realizate în timpul procesului de optimizare?
#Ce tool-uri pot fi folosite în auditarea conținutului JS?
- #Tool-uri gratuite și ce verificări pot fi făcute cu fiecare din acestea
- #Tool-uri premium
#Concluzie

#Care sunt cele mai frecvente aspecte în cazul cărora apar probleme?

#1. Viteza de Rendering

Ținând cont de cât de complex este procesul de rendering a unui conținut JS, este mult mai costisitoare procesarea unui astfel de conținut, motiv pentru care pot apărea probleme majore la viteza de rendering. Riscul major este acela de nu permite finalizarea procesului, a nu afișa și a nu indexa conținutul.

De asemenea, este esențial ca serverul să poată susține volumul de accesări făcute de motorul de căutare și de useri. Pentru a asigura finalizarea procesului de rendering făcut de Google, serverul trebuie să aibă resursele necesare (Google recomandă acest lucru și pe blogul oficial).

Un rendering slab poate afecta și viteza de încărcare, lucru care afectează negativ experiența utilizatorilor (și Bounce Rate-ul). Un alt lucru de care trebuie ținut cont este faptul că fiecare dispozitiv are capabilități diferite, motiv pentru care conținutul trebuie testat și optimizat pentru cât mai multe variante diferite.

#2. Activitatea din Main Thread

În întregul proces, există o ordine pentru încărcarea fiecărui element, acest ”main thread”. Fiecare script nou oprește procesul, astfel încât conținutul să poată fi actualizat cu noi informații. Astfel, se pot crea blocaje care afectează negativ viteza de încărcare a paginii.

Este recomandat ca activitatea în main thread să fie întreruptă cât mai rar posibil. Pentru a evita blocajele:

trebuie urmărite toate resursele executate;
trebuie identificate resursele care opresc procesul de rendering;
trebuie identificate zonele în care există request timeouts.

#3. Date diferite în HTML față de cele din JS

Este nerecomandat ca elementele importante pentru indexing (precum meta data, headings) să fie redate prin JS, din pricina faptului că ar fi citite de motoarele de căutare fie mai târziu, fie deloc. Există posibilitatea ca, după finalizarea procesului de rendering, noile datele să nu coincidă cu cele inițiale din HTML, lucru care ar dezorienta motorul de căutare. Din acest motiv, este important ca cele mai importante informații despre pagină (metadata, meta robots, canonical, hreflang, conținut important) să fie stabilite clar în codul HTML și să nu fie alterate de JS.

Având în vedere că informațiile din Google Tag Manager sunt preluate tot prin JS, e indicat ca astfel de informații importante pentru indexing să nu fie implementate astfel. Totuși, implementarea poate funcționa în situații extreme în cazul în care informațiile din HTML nu pot fi modificate (din CMS, de exemplu).

#4. Accesul Googlebot la fișierele JS

Fișierele JS (similar cu cele CSS) nu trebuie să fie blocate prin robots.txt. Fiind esențiale în procesul de rendering, este indicat ca accesul pentru Googlebot să nu fie blocat.

#5. Prezența script-urilor în head

Procesul de rendering și încărcarea completă a paginii pot fi îngreunate de prezența script-urilor în head. Având în vedere că secțiunea <head> este procesată înainte de celelalte, există riscul ca alte tag-uri din <head> și elemente din <body> să nu mai poată fi procesate (sau chiar ignorate).

#6. Conținut duplicat

Dacă procesul de rendering durează prea mult timp, e posibil ca o mare parte din conținut să nu poată fi citit. Astfel, există riscul ca, în pagină, să existe doar conținut de tip boilerplate (conținut identic prezent în multe sau toate paginile), să se creeze conținut duplicat, iar motoarele de căutare să nu identifice conținutul unic, relevant pentru indexing.

#7. Elemente de tip event dedicate userilor

Googlebot nu interacționează cu paginile precum un utilizator real: nu dă click, nu face scroll, nu bifează. Ei ”circulă” doar prin link-uri. Astfel că, dacă există pagini importante la care se poate ajunge doar prin eventuri realizabile de utilizatori reali, Googlebot nu poate ajunge la ele. De asemenea, Googlebot:

nu procesează majoritatea evenimentelor de tip onclick;
nu stochează cookies, astfel că va fi o problemă pentru site-urile care se bazează pe cookies pentru a afișa conținut.

#Cum putem optimiza conținutul astfel încât să fie indexat rapid și complet?

#1. Prioritizarea conținutului important din pagină pentru procesul de rendering

Googlebot trebuie să aibă acces rapid la cele mai importante informații din pagină. Este indicat ca acestea să coincidă cu cele prezente în pagină după ce aceasta a trecut prin procesul de rendering (să nu fie modificate de JS);
prioritizează conținutul important (critical rendering path) să se încarce primul, astfel încât utilizatorul să primească rapid cele mai valoroase informații. Asigură-te că cele mai importante resurse JS nu sunt blocate și pot intra în procesul de rendering cât mai curând posibil;
utilizează Async pentru a te asigura că DOM-ul este construit înainte ca un alt script să întrerupă procesul;
utilizează lazy loading pentru resursele JS mai puțin importante;
utilizează metodologia Progressive Enhancements – practic, conținutul în pagină se construiește progresiv, începând cu cele mai importante elemente, urmând ca cele care necesită tehnologii JS avansate să fie încărcate ulterior – astfel, conținutul important poate fi accesat, indiferent de capabilitățile de rendering;
nu permite ca aceeași resursă să se încarce de două ori;
optimizează bugetul de crawl – folosește eficient indicatorii de index & crawl pentru Googlebot, astfel încât resursele să fie utilizate pentru conținutul important.

#2. Alegerea metodei de rendering potrivită pentru site și business

Pentru a ajuta motoarele de căutare și browserele să citească mai rapid conținutul JS, pot fi implementate metode diferite de rendering. Practic, putem ajusta volumul de muncă în procesul de rendering între browser, server și motorul de căutare.

#2.1. Prerendering

Această metodă presupune ca tot conținutul să treacă prin procesul de rendering, înainte să fie accesat de utilizator sau de motoarele de căutare. Avantajul îl constituie faptul că motorul de căutare și browserul primesc destul de rapid, fără să fie nevoie să facă ele procesul de rendering, o pagină cu conținut static HTML. Dezavantajul principal este faptul că ele primesc doar conținutul static. Practic, e posibil ca:

anumite secțiuni de conținut să nu apară în pagină;
anumite funcționalități interactive să lipsească – ceea ce, pentru user, nu ar însemna cea mai bună experiență;
să apară erori de încărcare a paginii.

#2.2. SSR: Server Side Rendering

Această metodă presupune ca întregul proces să fie realizat de server. Astfel, utilizatorii (în browser) motoarele de căutare primesc conținutul direct în format HTML. Principalul avantaj al acestei metode este faptul că permite rețelelor social media și motoarelor de căutare (chiar și celor cu probleme în procesul de rendering) să indexeze rapid și complet conținutul din pagini. De asemenea, structura de link-uri internă este rapid identificată de motoarele de căutare, iar performanța și viteza de încărcare a paginilor sunt îmbunătățite. După cum putem intui, dezavantajele pot fi date de:

resursele serverului;
complexitatea implementării;
costul implementării.

#2.3. CSR: Client Side Rendering

Spre deosebire de metoda SSR (Server Side Rendering), această metodă are ca avantaj faptul că nu solicită serverul, întregul proces fiind făcut de browser sau de motorul de căutare. Și cum știm deja care sunt limitările motoarelor de căutare și ale browserelor în a citi conținut JS, apar următoarele dezavantaje:

procesorul dispozitivului de pe care este accesat conținutul este solicitat mai mult;
timpul de încărcare a paginilor crește;
în funcție de motorul de căutare sau de browser, e posibil ca întregul conținut să nu poată fi citit.

#2.4. Dynamic rendering

După cum spune și numele, permite metode de rendering a conținutului diferite, în funcție de cine îl accesează: userul sau motorul de căutare. De exemplu, dacă un motor de căutare sau un crawler de rețea social media accesează o pagină, poate fi implementat o soluție precum Puppeteer, Prerender.io* sau Rendertron – care folosesc metoda Prerender, astfel încât, motoarele de căutare să primească conținutul complet pentru indexare. *Pe site-ul celor de la Prerender.io poți testa live cele două variante de conținut: JavaScript vs. versiunea Prerendered – diferențele dintre cele două se pot vedea în codul sursă al fiecăreia. În rest, pentru restul de user agents (inclusiv utilizatori reali), poate fi utilizată metoda CSR (Client Side Rendering). Astfel, dezavantajele acestei metode sunt:

browserul trebuie să facă procesul de rendering, timpul de încărcare fiind mare;
experiența utilizatorilor poate fi una slabă;
sunt necesare mai multe teste în development (pentru ambele metode de rendering).

Dynamic Rendering este o metodă recomandată chiar de Google (și Bing) pentru site-urile care:

se bazează foarte mult pe conținut JS;
schimbă conținutul din pagini rapid și frecvent;
utilizează funcționalități pe care Googlebot nu le suportă.

Implementarea este documentată de Google aici.

#2.5. Hybrid Rendering:

Aceasta presupune utilizarea pentru aceeași pagină a celor două metode: SSR și CSR. Conținutul de bază trece prin procesul de SSR și ajunge la utilizatori sau la motoarele de căutare care-l solicită. Ulterior, conținutul JS suplimentar (de obicei, ce ține de elemente interactive) trece prin procesul de CSR (în browser). Avantaje:

motoarele de căutare primesc rapid și complet conținutul;
structura internă de link-uri este identificată ușor de motorul de căutare;
utilizatorii, la rândul lor, primesc rapid conținutul;
permite anumite interacțiuni.

Dezavantaje:

anumite interacțiuni nu sunt disponibile din start;
poate fi dificil și costisitor de implementat;
poate cauza probleme la viteza de încărcare, având în vedere că există două secvențe de rendering.

În funcție de resursele necesare pentru implementare, specificul de business și website, alege metoda de rendering potrivită și testeaz-o. Iar dacă este nevoie ca un site cu cele mai noi tehnologii JS să fie accesat de browsere și motoare de căutare incapabile de rendering, poți folosi metoda ”graceful degradation”. Similară cu ”Progressive Enhancements”, deși diferită: conținutul se construiește pentru tehnologiile moderne, dar se poate ”degrada” pentru cele mai slabe.

#3. URL-uri SEO-friendly

Evită utilizarea caracterelor speciale (mai ales #) în URL-uri. Pe lângă o indexare corectă, URL-urile SEO-friendly vor facilita și campania de link building și obținerea naturală de backlink-uri. Mai mult, asta te va ajuta și în analiza datelor din Google Analytics.

#4. Markup SEO-friendly pentru informațiile importante

Asigură-te că cel mai importante informații despre pagină este folosit markup SEO-friendly: link-uri interne, metadata, meta robots, canonical, hreflang, atributele pentru optimizarea imaginilor. Utilizarea link-urilor interne prin tag-ul <a href> ajută motorul de căutare să descopere rapid alte pagini pentru crawl, dar sunt utile și pentru tehnologii asistive (pentru dispozitive utilizate de persoane cu dizabilități sau în vârstă).

De asemenea, folosește cu încredere markup de Schema.org oriunde e necesar, pentru a ajuta motorul de căutare să înțeleagă mai bine conținutul din pagină.

#5. Reducerea pe cât de mult posibil a dimensiunii paginilor

Optimizarea dimensiunii paginii și a resurselor poate ajuta la un timp de rendering mai mic: prioritizarea fișierelor JS importante pentru utilizatori, eliminarea segmentelor de cod inutil, eliminarea codului fără funcții (comentariile, de exemplu), etc. Există mai multe metode prin care poate fi realizată – mai multe detalii despre acestea în documentația de aici.

#6. Asigurarea unei viteze bune de încărcare a site-ului

Atât pentru motorul de căutare, cât și pentru percepția utilizatorului, viteza de încărcare este esențială. Chiar și cu JavaScript (mai multe resurse necesare pentru crawling & indexing), viteza de încărcare a site-ului poate fi îmbunătățită:

folosește sisteme de caching – foarte utile pentru userii care vizitează des site-ul și pentru metodele de rendering SSR sau Dinamic Rendering (request-urile de rendering realizate înainte de load pot încărca resursele serverului).
încarcă cele mai importante resurse prioritar, cu link rel=”preload” – poți alege ce resurse (JS, fonturi) să se încarce prioritar prin utilizarea acestui atribut.
încarcă resursele cu ajutorul browserului prin utilizarea link rel=”prefetch” – resursele uzuale (sau cu potențial mare de a fi accesate de utilizatori) pot fi selectate să fie descărcate în timpii idle ai browserelor.
implementează Script Streaming pentru procesarea script-urilor separat de main thread;
aplică metoda PRPL (Push, Render, Pre-cache, Lazy-load) pentru a ajuta la o încărcare rapidă a paginilor.
testează frecvent viteza de încărcare cu tool-urile menționate anterior și identifică zonele cu blocaje.

#Ce teste trebuie realizate în timpul procesului de optimizare?

Este esențial să testăm frecvent și să analizăm în detaliu pentru a înțelege ce conținut poate trece prin procesul de rendering cu succes și cum este văzut în formă finală, atât pentru utilizatori, cât și pentru motoarele de căutare. Iată ce poți testa:

Testarea procesului de rendering pe mai multe dispozitive: deoarece fiecare dispozitiv are capabilități diferite, e important să fie verificat rendering-ul pe cât mai multe din dispozitivele utilizate de vizitatori, în special pe cele cu procesoare mai slabe.
Testarea procesului de rendering pe mai multe browsere (și versiuni de browsere): în mod similar, pentru rendering-ul în browser, e important să fie testat pe cele mai utilizate browsere.
Compararea conținutului din HTML înainte și după procesul de rendering: este esențial ca tot conținutul important (pentru utilizatori, indexing & ranking) să existe în DOM înainte de rendering și să nu fie eliminat de JavaScript după procesul de rendering.
Verificarea indexabilității URL-urilor și a conținutului din pagini: fie cu GSC URL Inspection tool, fie prin comanda ”site:” în Google, poate fi testat dacă un URL sau conținut din pagină este indexat în Google.
Testarea vitezei de rendering: dacă procesul de rendering necesită un timp prea mare, poate împiedica motorul de căutare să indexeze conținutul, iar experiența utilizatorului va fi afectată.
Analiza capacității de rendering și crawling a motorului de căutare: pot fi analizate fișierele de server log pentru a înțelege unde are motorul de căutare probleme în a accesa pagini cu conținut JS. De asemenea, pot fi comparate cu paginile care pot fi accesate cu ușurință, pentru a înțelege unde sunt problemele.

#Ce tool-uri pot fi folosite în auditarea conținutului JS?

#Tool-uri gratuite și ce verificări pot fi făcute cu fiecare din acestea

URL Inspection Tool din Google Search Console:
1. probleme tehnice ce nu permit indexarea paginilor;
2. erori JS în procesul de rendering;
3. resurse JS blocate;
4. modul în care vede motorul de căutare o pagină prin ”Live testing” (ca screenshot și ca HTML trecut prin rendering).
Google Mobile Friendly Test – prin acest tool
1. modul în care vede (ca screenshot) motorul de căutare pagina testată;
2. codul HTML trecut prin procesul de rendering (pentru verificări detaliate a conținutului și structurii);
3. erori de încărcare a diverselor resurse (JS, de exemplu);
4. resurse JS blocate.
Google Rich Results Test:
1. în mod similar, acest tool poate fi folosit pentru a afișa codul HTML trecut prin procesul de rendering;
2. pot fi identificate erori de JavaScript și pageload, în general.
Index Coverage din Google Search Console:
1. oferă o imagine de ansamblu asupra conținutului cu erori, warnings, indexat și exclus de la indexare;
2. dacă primele trei tool-uri oferă informații detaliate despre erorile JS dintr-o pagină, în raportul Index Coverage sunt afișate erori generale, prezente la nivelul întregului site, ce nu permit o indexare corectă a paginilor.
Google PageSpeed Insights:
1. acest tool a fost dezvoltat destul de mult în ultima perioadă, tocmai pentru a afișa diverse rapoarte detaliate cu privire la JavaScript;
2. în secțiunile ”Opportunity” și ”Diagnostics” sunt afișate, în ordine prioritară, zonele ce pot fi optimizate și cât de mult afectează viteza de de încărcare a paginii.
WebPageTest:

În secțiunea ”Processing breakdown” sunt afișate două piechart-uri cu privire la pașii din procesul de rendering și event-urile pentru care se consumă cel mai mult timp (și cât), astfel încât să poată fi identificate ușor zonele în care există blocaje ce cresc timpul de încărcare a paginii.

Chrome DevTools – cu ajutorul acestui tool din Inspect (Google Chrome) pot fi identificate o multitudine de informații, printre care, cele mai importante:
1. detalii despre performanța paginii: procente pentru fiecare proces – Loading, Scripting, Rendering, Painting;
2. graficul waterfall ce conține ordinea și durata fiecărui script – pentru a înțelege unde există blocaje și ce resurse se încarcă după ce pagina a fost deja încărcată;
3. Network Conditions – cu ajutorul căruia putem dezactiva cache-ul, putem alege user agent-ul (de exemplu, așa putem vedea pagina așa cum o vede Googlebot) sau putem alege tipul de rețeaua sau o performanță custom a rețelei (pentru a testa încărcarea paginii în condiții de ”internet slab” – 3G, 2G sau GPRS);
4. Debugging in Chrome – verificări în Browser pentru erori și warnings pentru fișierele JS (bonus: poate fi făcut acest test și cu user agent Googlebot).

Mai multe detalii despre acest tool, în documentația oficială.

Extensii pentru browsere care pot dezactiva JavaScript-ul:
1. Web Developer (pentru Chrome, Firefox, Opera)
2. Quick JavaScript Switcher (pentru Chrome)
3. JavaScript Switcher (pentru Firefox)

Prin dezactivarea JavaScript-ului, putem vedea cum se încarcă o pagină în browser cu și fără rendering.

#Tool-uri premium

Diffchecker (are și o versiune trial de 30 de zile):

Cu ajutorul acestui tool pot fi comparate cele două coduri HTML: din codul sursă vs. cel trecut prin rendering, afișat prin ”inspect” în Chrome. În prima căsuță este completat codul HTML copiat din codul sursă al paginii. În cea de-a doua se va copia ”Outer HTML” din Inspect: Tool-ul va afișa:

cu roșu – textul eliminat după rendering;
cu verde – textul adăugat după rendering.

Practic, ce ne interesează este conținutul eliminat în urma procesului re rendering – este sau nu important pentru indexing? 2. DeepCrawl (cu versiune trial de 2 săptămâni) – este un tool foarte complex care are propriul sistem de rendering și permite o analiză a site-ului la o scară largă. Tool-ul permite identificarea conținutului și a link-urilor modificate prin JS ce nu pot fi trecute prin procesul de crawling și indexing:

1. resurse blocate (disallowed);
2. resurse cu erori (broken);
3. redirecționări JS, etc.

Cu acest tool e important să fie urmărite:

thin pages (e posibil ca o parte din conținut să nu poată fi citit, din acest motiv paginile să fie văzute ca fiind ”thin”):
pagini cu puține link-uri interne (e posibil ca link-urile să nu fie văzute);
fișierele de dimensiuni foarte mari (cu posibilitatea de a nu fi citite de Google);

Mai multe detalii despre funcționalitățile tool-ului, pe site-ul lor. 3. ScreamingFrog, de asemenea, are propriul sistem de rendering și permite:

1. vizualizarea paginilor (ca screenshot) după rendering;
2. conectarea tool-ului cu PageSpeed Insights, pentru afișarea datelor despre performanța paginilor (bulk);
3. indexabilitatea resurselor JavaScript (pentru a le identifica pe cele blocate);

Mai multe detalii despre utilizarea Screaming Frog în procesul de crawl a site-urilor cu JavaScript, aici.

#Concluzie

E important să ne asigurăm că, atât utilizatorii cât și motoarele de căutare ajung rapid la cele mai importante informații din pagină. E esențial ca utilizatorii să aibă parte de o experiență pozitivă, iar pentru motoarele de căutare să înțelegem unde sunt blocajele, astfel încât să putem optimiza unde este necesar pentru o indexare rapidă și completă.

Testează conținutul în mod frecvent, astfel încât să poți identifica: resurse blocate, probleme de viteză de încărcare și rendering, diferențe între conținutul de dinainte și după rendering.

Data articol: 16 ianuarie 2020

Ana Nicoara

Articole publicate