Vue.js și SEO: Cum să optimizați site-urile web reactive pentru motoarele de căutare și roboți

Cadrele JavaScript reactive (cum ar fi React, Vue.js și Angular) fac furori în ultima vreme și nu este de mirare că sunt folosite în tot mai multe site-uri web și aplicații datorită flexibilității, modularității și ușurinței testării automate.

Aceste cadre permit obținerea de lucruri noi, anterior de neconceput pe un site web sau pe o aplicație, dar cum funcționează în ceea ce privește SEO? Paginile care au fost create cu aceste cadre sunt indexate de Google? Întrucât cu aceste cadre, toată – sau cea mai mare parte – redarea paginii se face în JavaScript (iar HTML-ul care este descărcat de roboți este în mare parte gol), se pare că acestea sunt interzise dacă doriți ca site-urile dvs. web să fie indexate în motoarele de căutare sau chiar analizate de roboți în general.

În acest articol, voi vorbi mai ales despre Vue.js, deoarece este framework-ul pe care l-am folosit cel mai mult și cu care am experiențe directe în ceea ce privește indexarea de către motoarele de căutare pe proiecte majore, dar pot presupune că majoritatea ceea ce voi acoperi este valabil și pentru alte cadre.

Câteva fundal asupra problemei

Cum funcționează indexarea

Pentru ca site-ul dvs. web să fie indexat de Google, acesta trebuie să fie accesat cu crawlere de Googlebot (un software de indexare automată care vă vizitează site-ul web și salvează conținutul paginilor în indexul acestuia) urmând link-urile din fiecare pagină. De asemenea, Googlebot caută fișiere XML Sitemap speciale în site-uri web pentru a găsi pagini care ar putea să nu fie conectate corect de la site-ul dvs. public și pentru a primi informații suplimentare despre cât de des se schimbă paginile de pe site și când s-au schimbat ultima dată.

Un pic de istorie

Până acum câțiva ani (înainte de 2009), Google obișnuia să indexeze conținutul HTML al unui site web - excluzând tot conținutul creat de JavaScript. Se cunoaște obișnuit SEO că linkurile și conținutul importante nu ar trebui să fie scrise de JavaScript, deoarece nu vor fi indexate de Google și ar putea cauza o penalizare pentru site-ul web , deoarece Google ar putea considera că este „conținut fals” ca și cum proprietarul site-ului ar încerca. pentru a arăta utilizatorilor ceva diferit de ceea ce a fost arătat motoarele de căutare și pentru a încerca să-i păcălească pe cei din urmă.

Era o practică foarte obișnuită de către escroci să pună o mulțime de conținut prietenos cu SEO în HTML și să-l ascundă în JavaScript, de exemplu. Google a avertizat întotdeauna împotriva acestei practici:

„Difuzarea de conținut Googlebot diferit decât ar vedea un utilizator obișnuit este considerată descuiat și ar fi împotriva Regulilor noastre pentru webmasteri.”

Ai putea fi penalizat pentru asta. În unele cazuri, ați putea fi penalizat pentru difuzarea de conținut diferit către diferiți agenți de utilizator din partea serverului, dar și pentru comutarea conținutului prin JavaScript după ce pagina s-a încărcat. Cred că acest lucru ne arată că Google a indexat de mult timp site-uri web care execută JavaScript - cel puțin de dragul de a compara HTML-ul final al site-ului web (după execuția JavaScript) și HTML brut pe care îl analiza pentru indecșii săi. Dar Googlebot nu a executat JavaScript tot timpul, iar Google nu folosea conținutul generat de JavaScript în scopuri de indexare.

Apoi, având în vedere utilizarea crescută a AJAX pentru a furniza conținut dinamic pe site-uri web, Google a propus o „schemă de accesare cu crawlere AJAX” pentru a ajuta utilizatorii să indexeze site-urile web bazate pe AJAX. A fost foarte complicat; practic, a cerut ca site-ul web să producă o redare a paginilor cu conținut AJAX inclus. La cererea Google, serverul va furniza o versiune a paginii cu tot (sau majoritatea) conținutului care ar fi fost generat dinamic de JavaScript inclus în pagina HTML - pre-rendat ca un instantaneu HTML al conținutului. Acest proces de a avea o soluție pe partea serverului să livreze conținut care a fost (pentru toate celelalte scopuri) menit să fie generat de partea clientului, a implicat că cei care doreau să aibă un site care se baza în mare măsură pe JavaScript indexat în Google au trebuit să treacă prin multe necazuri tehnice.

De exemplu, dacă conținutul citit de AJAX provenea de la un serviciu web extern, era necesar să se dubleze aceleași apeluri de servicii web pe partea serverului și să se producă, pe partea serverului, același HTML care ar fi fost produs de către client. JavaScript - sau cel puțin unul foarte asemănător. Acest lucru a fost foarte complicat deoarece, înainte de apariția lui Node.js, era necesar să se dubleze cel puțin parțial aceeași logică de randare în două limbaje de programare diferite: JavaScript pentru frontend și PHP, Java, Python, Ruby și așa mai departe, backend-ul. Aceasta se numește „ redare pe server ”, și ar putea duce la iad de întreținere: dacă ați făcut modificări importante în modul în care redați conținutul în frontend, trebuia să duplicați acele modificări pe backend.

Singura alternativă pentru a evita duplicarea logicii a fost să analizați propriul site cu un browser care execută JavaScript și să salvați rezultatele finale pe server și să le difuzați pentru Googlebot. Acest lucru este oarecum similar cu ceea ce se numește acum „ pre-rendare ”.

Google (cu schema sa de crawling AJAX) a garantat, de asemenea, că veți evita penalizările datorită faptului că, în acest caz, difuzați conținut diferit Googlebot și utilizatorului. Cu toate acestea, din 2015, Google a renunțat la această practică printr-o postare oficială pe blog care le-a spus managerilor de site-uri următoarele:

„Astăzi, atâta timp cât nu blocați Googlebot să acceseze cu crawlere fișierele JavaScript sau CSS, în general suntem capabili să redăm și să înțelegem paginile dvs. web ca browserele moderne.”

Ceea ce ne-a spus acest lucru nu a fost că Googlebot a dobândit brusc capacitatea de a executa JavaScript la indexarea paginilor web, deoarece știm că a făcut acest lucru de foarte mult timp (cel puțin pentru a verifica conținutul fals și escrocherii). În schimb, ne-a spus că rezultatul execuției JavaScript va fi indexat și utilizat în SERP-uri.

Acest lucru pare să implice că nu trebuie să ne mai facem griji cu privire la furnizarea Google HTML redat pe partea de server. Cu toate acestea, vedem tot felul de instrumente pentru randarea pe server și pre-rendarea puse la dispoziție pentru cadrele JavaScript, se pare că nu este cazul. De asemenea, atunci când ai de-a face cu agenții de SEO pe proiecte mari, pre-rendarea pare să fie considerată obligatorie. Cum se face?

Cum indexează de fapt Google paginile create cu cadre front-end?

Experimentul

Pentru a vedea ce indexează Google de fapt în site-urile web care au fost create cu un cadru front-end, am construit un mic experiment. Nu acoperă toate cazurile de utilizare, dar este cel puțin un mijloc de a afla mai multe despre comportamentul Google. Am construit un site web mic cu Vue.js și am avut diferite părți de text redate diferit.

Conținutul site-ului este preluat din descrierea cărții Infinite Jest de David Foster Wallace din Infinite Jest Wiki ( mulțumesc băieți! ). Există câteva texte introductive pentru întreaga carte și o listă de personaje cu biografia lor individuală:

• Un text în HTML static, în afara containerului principal Vue.js;
• Un text este redat imediat de Vue.js deoarece este conținut în variabile care sunt deja prezente în codul aplicației: sunt definite în obiectul de data al componentei;
• #Un text este redat de Vue.js din obiectul de data , dar cu o întârziere de 300 ms;
• Biografia personajelor provine dintr-un set de API-uri rest, pe care le-am construit intenționat folosind Sandbox. Deoarece presupunem că Google va executa codul site-ului web și se va opri după ceva timp pentru a face un instantaneu al stării curente a paginii, am setat fiecare serviciu web să răspundă cu o întârziere incrementală, primul cu 0 ms, al doilea cu 300 ms, al treilea cu 600ms și așa mai departe până la 2700ms.

Fiecare biografie a caracterului este scurtată și conține un link către o subpagină, care este disponibilă numai prin Vue.js (URL-urile sunt generate de Vue.js folosind API-ul istoric), dar nu pe partea serverului (dacă apelați adresa URL a pagina direct, nu primiți niciun răspuns de la server), pentru a verifica dacă și acestea au fost indexate. Am presupus că acestea nu vor fi indexate, deoarece nu sunt link-uri adecvate care redau partea serverului și nu există nicio modalitate ca Google să poată direcționa utilizatorii către acele linkuri direct. Dar am vrut doar să verific.

Am publicat acest mic site de testare pe paginile mele Github și am cerut indexarea - aruncați o privire.

Rezultatele

Rezultatele experimentului (privind pagina principală) sunt următoarele:

• Conținutul care se află deja în conținutul HTML static este indexat de Google (ceea ce este destul de evident);
• Conținutul care este generat de Vue în timp real este întotdeauna indexat de Google;
• Conținutul care este generat de Vue, dar redat după 300 ms este indexat, de asemenea;
• Conținutul care provine din serviciul web, cu o oarecare întârziere, poate fi indexat, dar nu întotdeauna. Am verificat indexarea paginii de către Google în momente diferite, iar conținutul care a fost inserat ultima dată (după câteva secunde) a fost uneori indexat, alteori nu. Conținutul care este redat destul de repede este indexat de cele mai multe ori, chiar dacă provine dintr-un apel asincron către un serviciu web extern. Acest lucru depinde de faptul că Google are un buget de randare pentru fiecare pagină și site, care depinde de algoritmii săi interni și poate varia foarte mult în funcție de clasarea site-ului dvs. și de starea actuală a cozii de randare a Googlebot. Deci nu vă puteți baza pe conținutul care vine de la servicii web externe pentru a fi indexat;
• Subpaginile (deoarece nu sunt accesibile ca link direct) nu sunt indexate conform așteptărilor.

Ce ne spune acest experiment? Practic, acel Google indexează conținutul generat dinamic, chiar dacă provine de la un serviciu web extern, dar nu este garantat că conținutul va fi indexat dacă „ajunge prea târziu”. Am avut experiențe similare cu alte site-uri web reale, de producție, în afară de acest experiment.

SEO competitiv

Bine, deci conținutul este indexat , dar ceea ce acest experiment nu ne spune este: conținutul va fi clasat competitiv? Va prefera Google un site web cu conținut static unui site web generat dinamic? Nu este o întrebare ușor de răspuns.

Din experiența mea, pot spune că conținutul generat dinamic se poate clasa în primele poziții ale SERPS. Am lucrat pe site-ul web pentru un nou model al unei mari companii de automobile, lansând un nou site web cu un nou domeniu de nivel al treilea. Site-ul a fost generat complet cu Vue.js — cu foarte puțin conținut în HTML static, pe lângă etichetele <title> și meta descrierile.

Site-ul a început să se claseze pentru căutări minore în primele zile de la publicare, iar fragmentele de text din SERP-uri au raportat cuvinte care provin direct din conținutul dinamic.

În decurs de trei luni, s-a clasat pe primul loc pentru majoritatea căutărilor legate de acel model de mașină – ceea ce a fost relativ ușor, deoarece a fost găzduit pe un domeniu oficial aparținând producătorului mașinii, iar domeniul a fost puternic legat de site-uri web de renume.

Dar dat fiind faptul că a trebuit să ne confruntăm cu o opoziție puternică din partea companiei SEO care se ocupa de proiect, cred că rezultatul a fost încă remarcabil.

Din cauza termenelor strânse și a lipsei de timp acordate proiectului, urma să publicăm site-ul fără pre-rendare.

Text animat

Ceea ce Google nu indexează este text puternic animat. Site-ul uneia dintre companiile cu care lucrez, Rabbit Hole Consulting, conține o mulțime de animații de text, care sunt efectuate în timp ce utilizatorul derulează și necesită ca textul să fie împărțit în mai multe bucăți în diferite etichete.

Principalele texte din pagina de start a site-ului web nu sunt destinate indexării motoarelor de căutare, deoarece nu sunt optimizate pentru SEO. Nu sunt făcute din tech-speak și nu folosesc cuvinte cheie: sunt menite doar să însoțească utilizatorul într-o călătorie conceptuală despre companie. Textul este inserat dinamic atunci când utilizatorul intră în diferitele secțiuni ale paginii de pornire.

Niciunul dintre textele din aceste secțiuni ale site-ului web nu este indexat de Google. Pentru a face ca Google să arate ceva semnificativ în SERP-uri, am adăugat un text static în subsolul de sub formularul de contact, iar acest conținut apare ca parte a conținutului paginii în SERP-uri.

Textul din subsol este indexat și afișat în SERP-uri, deși nu este imediat vizibil pentru utilizatori decât dacă aceștia derulează în partea de jos a paginii și dau clic pe butonul „Întrebări” pentru a deschide formularul de contact. Acest lucru confirmă părerea mea că conținutul este indexat chiar dacă nu este afișat imediat utilizatorului, atâta timp cât este redat în curând în HTML - spre deosebire de a fi redat la cerere sau după o întârziere lungă.

Dar pre-rendarea?

Așadar, de ce toată agitația legată de pre-randare - fie că este făcută pe partea serverului sau la momentul compilarii proiectului? Este chiar necesar? Deși unele cadre, precum Nuxt, îl fac mult mai ușor de executat, tot nu este un picnic, așa că alegerea dacă să-l configurați sau nu nu este una ușoară.

Cred ca nu este obligatoriu . Este cu siguranță o cerință dacă o mare parte din conținutul pe care doriți să îl indexați de Google provine de la un serviciu web extern și nu este disponibil imediat la momentul redării și ar putea - în unele cazuri nefericite - să nu fie disponibil deloc din cauza, de exemplu, , timp de nefuncționare a serviciului web. Dacă în timpul vizitelor Googlebot o parte din conținutul dvs. ajunge prea lent, atunci este posibil să nu fie indexat . Dacă Googlebot vă indexează pagina exact într-un moment în care efectuați întreținerea serviciilor dvs. web, este posibil să nu indexeze deloc niciun conținut dinamic.

În plus, nu am nicio dovadă a diferențelor de clasare între conținutul static și conținutul generat dinamic. Asta ar putea necesita un alt experiment. Cred că este foarte probabil ca, dacă conținutul provine de la un serviciu web extern și nu se încarcă imediat, acesta ar putea avea un impact asupra percepției Google asupra performanței site-ului dvs., care este un factor foarte important pentru clasament.

Lectură recomandată : Cum afectează designul web mobil căutarea locală (și ce să faceți în legătură cu aceasta)

Alte considerații

Compatibilitate

Până de curând, Googlebot folosea o versiune destul de veche a Chromium (proiectul open-source pe care se bazează Google Chrome), și anume versiunea 41. Aceasta însemna că unele caracteristici JavaScript sau CSS recente nu puteau fi redate corect de Google (de exemplu, IntersectionObserver, sintaxa ES6 și așa mai departe).

Google a anunțat recent că rulează acum cea mai recentă versiune de Chromium (74, la momentul scrierii) în Googlebot și că versiunea va fi actualizată în mod regulat. Faptul că Google rula Chromium 41 ar fi putut avea implicații mari pentru site-urile care au decis să ignore compatibilitatea cu IE11 și alte browsere vechi.

Puteți vedea o comparație între compatibilitatea Chromium 41 și Chromium 74 pentru funcții aici, cu toate acestea, dacă site-ul dvs. a completat deja funcțiile lipsă pentru a rămâne compatibil cu browserele mai vechi, nu ar fi trebuit să existe nicio problemă.

Utilizați întotdeauna polyfills , deoarece nu știți niciodată ce browser nu acceptă funcțiile pe care le considerați obișnuite. De exemplu, Safari nu a acceptat o nouă caracteristică majoră și foarte utilă precum IntersectionObserver până la versiunea 12.1, care a apărut în martie 2019.

Erori JavaScript

Dacă te bazezi pe Googlebot care execută JavaScript pentru a reda conținut vital, atunci erorile JavaScript majore care ar putea împiedica redarea conținutului trebuie evitate cu orice preț. În timp ce boții ar putea analiza și indexa HTML care nu este perfect valid (deși este întotdeauna de preferat să aveți HTML valid pe orice site!), dacă există o eroare JavaScript care împiedică încărcarea unui anumit conținut , atunci Google nu va indexa în niciun fel acel conținut.

În orice caz, dacă te bazezi pe JavaScript pentru a reda conținut vital pentru utilizatorii tăi finali, atunci este probabil să ai deja teste unitare extinse pentru a verifica erorile de blocare de orice fel. Rețineți, totuși, că erorile Javascript pot apărea din scenarii imprevizibile, de exemplu, în cazul gestionării necorespunzătoare a erorilor în răspunsurile API.

Este mai bine să aveți la dispoziție un software de verificare a erorilor în timp real (cum ar fi Sentry sau LogRocket) care vă va avertiza cu privire la erorile marginale pe care este posibil să nu le alegeți în timpul testării unitare sau manuale. Acest lucru se adaugă la complexitatea bazei pe JavaScript pentru conținutul SEO.

Alte motoare de căutare

Celelalte motoare de căutare nu funcționează la fel de bine ca Google cu conținut dinamic. Bing nu pare să indexeze deloc conținutul dinamic, nici DuckDuckGo sau Baidu. Probabil că acelor motoare de căutare le lipsesc resursele și puterea de calcul pe care Google le are în pică.

Analizarea unei pagini cu un browser fără cap și executarea JavaScript timp de câteva secunde pentru a analiza conținutul redat este cu siguranță mai grea de resurse decât doar citirea HTML simplu. Sau poate că aceste motoare de căutare au ales să nu scaneze conținut dinamic din alte motive. Oricare ar fi cauza, dacă proiectul dvs. trebuie să sprijine oricare dintre acele motoare de căutare, trebuie să configurați pre-rendarea.

Notă : Pentru a obține mai multe informații despre capabilitățile de randare ale altor motoare de căutare, puteți consulta acest articol de Bartosz Goralewicz. Este un pic vechi, dar din experiența mea este încă valabil.

Alți roboți

Amintiți-vă că site-ul dvs. va fi vizitat și de alți roboți. Cele mai importante exemple sunt Twitter, Facebook și alți roboți de rețele sociale care trebuie să preia metainformații despre paginile dvs. pentru a afișa o previzualizare a paginii dvs. atunci când aceasta este conectată de utilizatorii lor. Acești roboți nu vor indexa conținutul dinamic și vor afișa doar meta informațiile pe care le găsesc în HTML static. Acest lucru ne conduce la următoarea considerație.

Subpagini

Dacă site-ul dvs. este un așa-numit „site web cu o singură pagină”, iar tot conținutul relevant este localizat într-un singur HTML principal, nu veți avea nicio problemă ca acel conținut să fie indexat de Google. Cu toate acestea, dacă aveți nevoie de Google să indexeze și să afișeze orice pagină secundară de pe site, va trebui totuși să creați HTML static pentru fiecare dintre acestea - chiar dacă vă bazați pe cadru JavaScript pentru a verifica adresa URL curentă și pentru a furniza conținutul relevant pentru a pune în pagina respectivă. Sfatul meu, în acest caz, este să creați pagini pe partea serverului (sau statice) care să ofere cel puțin eticheta de title și meta descrierea/informațiile corecte.

Concluzii

Concluziile la care am ajuns în timpul cercetării acestui articol sunt următoarele:

1. Dacă vizați doar Google, nu este obligatoriu să utilizați pre-rendarea pentru ca site-ul dvs. să fie indexat complet, totuși:
2. Nu ar trebui să vă bazați pe servicii web terțe pentru conținutul care trebuie indexat, mai ales dacă nu răspund rapid.
3. Conținutul pe care îl inserați în HTML imediat prin redarea Vue.js este indexat, dar nu ar trebui să utilizați text animat sau text care este inserat în DOM după acțiuni ale utilizatorului, cum ar fi derularea etc.
4. Asigurați-vă că testați erorile JavaScript, deoarece acestea ar putea avea ca rezultat ca paginile/secțiunile întregi să nu fie indexate sau ca site-ul dvs. să nu fie indexat deloc.
5. Dacă site-ul dvs. are mai multe pagini , trebuie să aveți în continuare o anumită logică pentru a crea pagini care, deși se bazează pe același sistem de randare front-end ca pagina de pornire, pot fi indexate de Google ca adrese URL individuale.
6. Dacă trebuie să aveți imagini diferite de descriere și previzualizare pentru rețelele sociale între diferite pagini, va trebui să rezolvați și acest lucru, fie pe partea de server, fie prin compilarea paginilor statice pentru fiecare adresă URL.
7. Dacă aveți nevoie ca site-ul dvs. să funcționeze pe alte motoare de căutare decât Google , cu siguranță veți avea nevoie de un fel de pre-randare.