Din punct de vedere istoric, dezvoltatorii web au folosit HTML pentru simplu conținut, CSS pentru stil și JavaScript pentru elemente de interactivitate. Este JS care face posibilă adăugarea de casete de dialog pop-up și conținut extensibil pe paginile web. Acum, peste 97% din toate site-urile folosesc JavaScript , deoarece oferă oportunități de modificare a conținutului web ca răspuns la acțiunile utilizatorului.

O tendință relativ nouă de încorporare a JS în site-uri web este aplicațiile cu o singură pagină. În timp ce site-urile web tradiționale își încarcă toate resursele (HTML, CSS, JS) solicitând fiecare de la server de fiecare dată când este nevoie, SPA-urile necesită o singură încărcare inițială și nu deranjează serverul după aceea, lăsând toată procesarea în sarcina browserului. Acest lucru are ca rezultat site-uri web mai rapide, dar ar putea fi un dezastru pentru SEO.

În această postare, vom discuta despre cum sunt făcute SPA-urile, de ce sunt atât de greu de optimizat și cum să ne asigurăm că motoarele de căutare le pot înțelege și le pot clasifica bine.

Ce este un SPA

Aplicația cu o singură pagină, sau SPA, este o tehnologie specifică bazată pe JavaScript pentru dezvoltarea site-ului web, care nu necesită încărcare de pagini după încărcarea primei pagini de vizualizare. React, Angular și Vue sunt cele mai populare cadre JavaScript utilizate pentru construirea SPA. Ele diferă în mare parte în bibliotecile și API-urile acceptate, dar folosesc aceeași logică de servire a randării rapide pe partea clientului. Multe site-uri web de profil (Twitter, Pinterest, Airbnb) sunt construite cu o arhitectură de aplicație cu o singură pagină.

Un SPA elimină solicitările dintre server și browser, făcând site-ul mult mai rapid. Dar motoarele de căutare nu sunt atât de încântați de acest truc JavaScript. Ceea ce se întâmplă este că motoarele de căutare nu primesc suficient conținut: nu fac clic ca utilizatorii reali și nu înțeleg că conținutul este adăugat dinamic. Ceea ce le-a rămas este o pagină goală încă de completat.

Tehnologia din spatele SPA-urilor este favorabilă utilizatorilor finali: aceștia pot naviga cu ușurință prin paginile web fără niciun disconfort cauzat de încărcările suplimentare ale paginilor și schimbările de aspect. Având în vedere că site-urile de aplicații cu o singură pagină memorează în cache toate resursele într-o stocare locală (după ce acestea sunt încărcate la cererea inițială), utilizatorii pot continua să le răsfoiască chiar și într-o conexiune instabilă. Datorită acestor beneficii, tehnologia este aici pentru totdeauna, chiar dacă necesită un efort suplimentar de SEO.

De ce este greu să optimizați SPA-urile

Înainte ca JS să înceapă să domine dezvoltarea web, motoarele de căutare accesau cu crawlere doar conținutul bazat pe text din HTML. Pe măsură ce JS devenea din ce în ce mai popular, Google a început să se gândească la adăugarea funcționalității pentru interpretarea resurselor JS și înțelegerea paginilor cu acestea. Au adus îmbunătățiri semnificative de-a lungul anilor, dar există încă o mulțime de probleme cu modul în care crawlerele de căutare văd și accesează conținutul din aplicațiile cu o singură pagină.

Există puține informații despre modul în care alte motoare de căutare percep aplicațiile cu o singură pagină, dar este sigur să spunem că nu toți sunt nebuni după site-urile care se bazează pe JavaScript. Dacă vizați platforme de căutare dincolo de Google, vă aflați într-o problemă. Experimentul Moz din 2017 a arătat că numai Google și, în mod surprinzător, Ask, au putut să acceseze cu crawlere conținutul JavaScript, în timp ce toate celelalte motoare de căutare au rămas total nevăzute față de JS. Începând de astăzi, niciun motor de căutare nu a făcut anunțuri inovatoare, cu excepția Google, despre eforturile depuse pentru înțelegerea site-urilor JS și a aplicațiilor cu o singură pagină. Cel puțin, există câteva recomandări oficiale: de exemplu, Bing face aceleași sugestii ca Google - încurajează pre-rendarea pe partea de server, o tehnologie care permite bingbot (și altor crawler-uri) să primească HTML static ca versiunea cea mai completă și mai inteligibilă. .

Probleme de crawling

HTML, care este ușor de accesat cu crawlere de motoarele de căutare, nu conține multe informații despre un SPA. Include un fișier JavaScript extern cu ajutorul <script> src atributului . Browserul rulează scriptul din acest fișier și conținutul este încărcat dinamic, dar crawler-ul ar putea să nu efectueze aceeași operațiune și, în acest caz, ceea ce vede pare a fi o pagină goală.

În 2014, Google a anunțat că îmbunătățește funcționalitatea de a înțelege paginile JS, admitând în același timp că există o mulțime de blocanți care îi împiedică să indexeze site-uri web bogate în JS. În seria Google I/O '18 , analiștii Google vorbesc despre două valuri de indexare pentru site-uri bazate pe JavaScript, ceea ce înseamnă că Googlebot redă din nou conținutul atunci când are resurse. Deoarece o mulțime de JavaScript necesită mult mai multă putere de procesare și memorie de la Googlebot, ciclul de accesare cu crawlere, redare și indexare nu este instantaneu. Din fericire, în 2019, Google a spus că avea nevoie de un timp mediu de 5 secunde pentru ca paginile web bazate pe JS să treacă de la crawler la redare. Tocmai când ne obișnuiam cu cele două valuri de schema de indexare, în 2020, Martin Splitt de la Google a spus că nu mai există așa ceva. Sau, mai degrabă, că este „mai complicat”.

Cel mai important lucru de înțeles aici este că există o întârziere în modul în care Google procesează JavaScript pe paginile web și este posibil ca tot conținutul JS care este încărcat pe partea clientului să nu fie considerat complet și indexat corespunzător. Motoarele de căutare pot descoperi pagina, dar nu vor putea înțelege dacă copia de pe pagina respectivă este de înaltă calitate și corespunde intenției de căutare.

Probleme cu eroarea 404

Cu un SPA, pierzi, de asemenea, logica tradițională din spatele paginii de eroare 404 și multe alte coduri de stare ale serverului non-200. Deoarece totul este redat de browser, serverul web returnează un cod de stare HTTP de 200 la fiecare solicitare, iar motoarele de căutare nu pot spune dacă unele pagini nu sunt valide pentru indexare.

Probleme de urmărire

O altă problemă care vine cu un SPA este urmărirea Google Analytics. Pentru site-urile web tradiționale, codul de analiză este rulat de fiecare dată când un utilizator încarcă sau reîncarcă o pagină, numărând fiecare vizualizare. Dar atunci când utilizatorii navighează prin diferite pagini dintr-o aplicație cu o singură pagină, codul este rulat o singură dată, fără a declanșa fiecare vizualizare de pagină individuală. Natura încărcării dinamice a conținutului împiedică GA să obțină un răspuns de server pentru fiecare afișare de pagină. Din fericire, există metode de urmărire a activității utilizatorilor pe un site web de aplicație cu o singură pagină (le vom trata mai târziu), dar necesită eforturi suplimentare.

Cum să optimizați SPA-urile

Deocamdată, să vedem ce acțiuni puteți lua pentru a face site-ul dvs. de aplicație cu o singură pagină pe deplin vizibil pentru crawlere. Printre lucruri utile, veți găsi elemente de bază SEO, cum ar fi un sitemap curat și lustruit și câteva tehnici specifice legate de randare.

Harta site-ului

Înainte de a vă ocupa de problemele de crawling și indexare specifice SPA-urilor, asigurați-vă că faceți elementele de bază: creați un fișier sitemap formatat corespunzător și trimiteți-l la Google. Nu te va ajuta cu resursele JS, dar cel puțin, motoarele de căutare vor ști că paginile tale sunt acolo și ce structură are site-ul tău.

-ului SE Ranking Auditul site verifică harta site-ului web pentru o serie de probleme:

RELAȚI UN AUDIT SITE WEB

Redare pe partea serverului

Randarea pe server (SSR) redă un site web pe server și apoi îl trimite către browser. Această tehnică permite roboților de căutare să acceseze cu crawlere tot conținutul bazat pe JavaScript. Deși acesta este o salvare de viață în ceea ce privește accesarea cu crawlere și indexare, ar putea încetini sarcina. Problema cu SSR este că SPA-urile folosesc o abordare opusă prin natura lor: este randarea la nivelul clientului care le face atât de rapide și interactive pentru utilizatori și, de asemenea, mai simple în implementare.

JS izomorf

O posibilă soluție de randare pentru o aplicație cu o singură pagină este JavaScript izomorf sau „universal”. Isomorphic JS face pagini web generate pe server și scutește un crawler de căutare de a fi nevoit să execute și să redeze fișiere JS.

„Magia” aplicațiilor JavaScript izomorfe constă în capacitatea lor de a rula atât pe partea de server, cât și pe partea clientului. Cum funcționează: utilizatorii interacționează cu un astfel de site web ca și cum conținutul acestuia ar fi redat de browser, când, de fapt, folosesc fișierul HTML generat pe partea serverului. Există cadre care facilitează dezvoltarea de aplicații izomorfe pentru fiecare framework SPA popular: de exemplu, Next.js și Gatsby pentru React. Primul generează HTML pentru fiecare solicitare, în timp ce al doilea generează un site web static și stochează HTML în cloud. În mod similar, Nuxt.js pentru Vue redă JS în HTML pe server și trimite datele către browser.

Pre-randare

O altă soluție pentru aplicațiile cu o singură pagină este pre-rendarea. Înseamnă să încărcați toate elementele HTML și să le păstrați în cache pe server pentru a servi apoi la căutarea crawlerelor. Există servicii precum Prerender și BromBone care interceptează solicitările făcute către un site web și afișează diferite versiuni de pagină pentru a căuta roboți și utilizatori reali: HTML memorat în cache pentru primul și conținut „normal” bogat în JS pentru cel din urmă. Site-urile web cu mai puțin de 250 de pagini pot folosi Prerender gratuit, în timp ce cele mai mari trebuie să plătească o taxă lunară care începe de la 200 USD. Este o soluție simplă: încărcați fișierul sitemap și ea face restul. BromBone nici măcar nu necesită încărcare manuală a sitemapului și costă 129 USD pe lună.

Există și alte metode care consumă mai mult timp pentru a difuza un HTML static către crawlere. De exemplu, puteți utiliza Headless Chrome și biblioteca Puppeteer , care va converti rutele în pagini în arborele ierarhic al fișierelor HTML. Apoi, va trebui să eliminați codul de bootstrap și apoi să editați fișierul de configurare a serverului pentru a localiza HTML-ul static destinat roboților de căutare.

Îmbunătățire progresivă cu detectarea caracteristicilor

Detectarea caracteristicilor este printre recomandările majore ale Google pentru SPA-uri. Această tehnică implică îmbunătățirea progresivă a experienței cu diferite resurse de cod. Cum funcționează: o pagină HTML simplă servește ca bază care este accesibilă crawlerelor și utilizatorilor, în timp ce funcțiile pe deasupra (resurse CSS și JS) și activează și dezactivează în funcție de compatibilitatea browserului.

Pentru a implementa detectarea caracteristicilor, va trebui să scrieți bucăți separate de cod pentru a verifica dacă fiecare dintre API-urile de caracteristici de care aveți nevoie este compatibilă cu fiecare browser. Din fericire, există biblioteci specifice, cum ar fi Modernizr , care ajută la economisirea timpului.

Vizualizări ca URL-uri

Când utilizatorii parcurg un SPA, trec secțiuni separate ale site-ului web. Din punct de vedere tehnic, un SPA conține o singură pagină (un singur fișier index.html), dar vizitatorii simt că navighează în mai multe pagini. Când utilizatorii se deplasează prin diferite părți ale unui site web de aplicație cu o singură pagină, adresa URL se modifică numai în partea sa hash (de exemplu, http://website.com/#/about, http://website.com/#/contact) . Fișierul JS indică browserelor să încarce un anumit conținut pe baza identificatorilor de fragmente (modificări hash).

Pentru a ajuta motoarele de căutare să perceapă diferitele secțiuni ale unui site web ca pagini diferite, trebuie să utilizați adrese URL distincte cu ajutorul API-ului History . Aceasta din urmă este o metodă standardizată HTML5 de manipulare a istoricului browserului. Google Codelabs sugerează utilizarea acestui API în loc de rutarea bazată pe hash, astfel încât motoarele de căutare să poată vedea diferite fragmente de conținut declanșate de modificările hash ca pagini separate. API-ul History vă permite să schimbați linkurile de navigare și să utilizați căi în loc de hash-uri.

Analistul Google Martin Splitt oferă același sfat : să tratați vizualizările ca adrese URL utilizând API-ul istoric. El sugerează, de asemenea, adăugarea de marcare a linkurilor cu atribute href , creând etichete unice de titlu și descriere pentru fiecare vizualizare (cu „puțin JavaScript în plus”). Rețineți că marcajul este valid pentru orice link de pe site-ul dvs.: afișați-le cu o <a> etichetă href cu un atribut în loc să utilizați acțiunea onclick . JavaScript onclick nu poate fi accesat cu crawlere și este aproape invizibil pentru Google.

Vizualizări pentru paginile de eroare

Cu site-urile web cu o singură pagină, serverul nu are nimic de-a face cu gestionarea erorilor și va returna întotdeauna codul de stare 200 spunând că totul este în regulă. Dar utilizatorii pot folosi adresa URL greșită pentru a accesa un SPA și ar trebui să existe o modalitate de a face față răspunsurilor la erori. Google recomandă crearea de vizualizări separate pentru fiecare cod de eroare (404, 500 etc.) și modificarea fișierului JS, astfel încât să direcționeze browserele către vizualizarea respectivă.

Cotări sociale și date structurate

Optimizarea partajării sociale este adesea trecută cu vederea de site-uri web: am aflat că cardurile Twitter lipsă sunt în fruntea listei cu cele mai frecvente probleme identificate de de audit al site instrumentul -urilor SE Ranking. Indiferent cât de nesemnificativ ar părea, implementarea Twitter Cards și a Open Graph de la Facebook va permite partajarea bogată pe canalele populare de social media, ceea ce este bun pentru vizibilitatea căutării site-ului web. Dacă nu utilizați aceste protocoale, partajarea linkului dvs. va declanșa un obiect vizual aleatoriu, nu neapărat relevant, care va fi afișat ca previzualizare.

Utilizarea datelor structurate este, de asemenea, importantă pentru ca diferitele tipuri de conținut de site să fie citite de crawler-uri. Schema.org oferă opțiuni pentru a eticheta tipuri de date, cum ar fi videoclipuri, rețete, produse și așa mai departe. Puteți efectua un test Google pentru rezultate îmbogățite pentru a afla dacă tipurile de date sunt atribuite în prezent și pentru a activa rezultate bogate de căutare pentru paginile dvs. web.

Testarea unui SPA

Anterior, Google Webmaster Tools includea funcționalitatea Fetch as Google , care permitea vizualizarea răspunsului HTTP descărcat și a paginii HTML pe măsură ce era preluată și redată de motorul de căutare. Dar în 2019, Google a eliminat instrumentul, iar acum puteți accesa doar câteva informații de accesare cu crawlere și indexare în secțiunea Inspecție URL a Search Console. Nu oferă o previzualizare informativă a ceea ce vede Google, dar vă oferă informații de bază despre problemele de crawling și indexare.

Testul Google Mobile-Friendly este, de asemenea, util, deoarece vă arată HTML-ul redat și identifică resursele paginii care nu pot fi încărcate și procesate de motoarele de căutare. În plus, Headless Chrome este o modalitate excelentă de a-ți testa SPA-ul pentru a vedea cum va fi executat JS. Un browser fără cap nu are o interfață de utilizare completă, dar oferă același mediu pe care îl vor avea utilizatorii reali. În cele din urmă, testați-vă SPA-ul în diferite browsere folosind instrumente precum BrowserStack .

Rezolvarea problemelor de urmărire

Deoarece codul de urmărire tradițional din Google Analytics nu funcționează cu site-uri web cu o singură pagină, va trebui să utilizați instrumente suplimentare. Trucul aici este să înregistrați și să monitorizați interacțiunea utilizatorului real în loc de afișările de pagină.

GA însuși sugerează urmărirea afișărilor de pagină virtuale prin setarea comenzii set și a valorii noii pagini. De asemenea, puteți implementa pluginuri precum Angulartics care urmăresc afișările de pagină pe baza navigării utilizatorului pe site. Sau puteți seta declanșatoare de modificare a istoricului în Google Tag Manager, care urmărește și interacțiunile utilizatorilor. Există și alte instrumente care vă pot ajuta cu urmărirea SPA prin colectarea datelor RUM (monitorizarea utilizatorului real).

Nu există nicio cale de a evita SEO de bază

Pe lângă natura specifică a SPA-urilor, majoritatea sfaturilor generale de optimizare se potrivesc acestui tip de site web. Eforturile de bază SEO implică:

• Securitate . Dacă nu ați făcut-o deja, protejați-vă site-ul web cu HTTPS. În caz contrar, s-ar putea să fii dat deoparte de motoarele de căutare și să compromiți datele utilizatorilor dacă site-ul folosește vreunul. Securitatea site-ului web nu este ceva pe care îl eliminați din lista de sarcini, ci un aspect valoros care necesită monitorizare continuă. Verificați în mod regulat certificatul SSL/TLS pentru erori critice pentru a vă asigura că site-ul dvs. poate fi accesat în siguranță:
• Content optimization. We’ve talked about the SPA-specific measures like writing unique title tags and description meta tags for each view (like you would for each page on a multi-page website). Before you do that, you need to have optimized content: tailored to the right user intents, well-organized, visually appealing, and rich in helpful information. If you haven’t collected a keyword list for the site, it will be hard to provide visitors with the content they need. You can check out our guide on keyword research to find some new insights.

• Construirea de legături . Backlink-urile semnalează Google despre nivelul de încredere pe care alte resurse îl plasează pe site-ul dvs., astfel încât construirea unui profil de backlink este o parte vitală a SEO. Nu există backlink-uri la fel: fiecare link care indică site-ul dvs. are o valoare diferită și, în timp ce unele vă pot spori în mod semnificativ clasamentul, cele spam vă pot afecta prezența în căutare. Aflați mai multe despre calitatea backlink -ului și construiți-vă profilul link-ului conform celor mai bune practici.
• Monitorizarea concurenților . Probabil că v-ați cercetat concurenții în primele etape ale dezvoltării site-ului web. La fel ca în cazul majorității sarcinilor de SEO și marketing, trebuie să țineți evidența nișei dvs. tot timpul. Datorită instrumentelor bogate în date, puteți monitoriza cu ușurință strategiile rivalilor în căutarea organică și plătită , evaluând situația de pe piață, observând fluctuațiile între concurenții majori și inspirându-vă din anumite cuvinte cheie sau campanii care funcționează deja pentru site-uri similare.

Site-uri web de aplicații cu o singură pagină făcute corect

Pentru ca SPA-ul dvs. să strălucească în ochii motoarelor de căutare, trebuie să faceți conținutul său ușor accesibil crawlerelor. Oferind vizitatorilor încărcare dinamică de conținut, viteză de explozie și navigare perfectă, nu uitați să oferiți o versiune statică motoarelor de căutare. În plus, asigurați-vă că aveți un sitemap corect, utilizați adrese URL distincte în loc de identificatori de fragmente și etichetați diferite tipuri de conținut cu date structurate.

Experiența cu o singură pagină adusă utilizatorilor grație JavaScript răspunde cerințelor utilizatorilor moderni care doresc să interacționeze cu conținutul web cât mai curând posibil. Pentru a păstra beneficiile SPA centrate pe UX și, de asemenea, să se claseze bine în căutare, dezvoltatorii trec la ceea ce inginerul Airbnb Spike Brehm numește „modul greu” – echilibrarea între client și server.

Aveți vreo experiență cu site-urile de aplicații cu o singură pagină? Te-ai chinuit să-ți împingi SPA-ul în vârful SERP-urilor?

Sursa: SeRanking