f ig tt X

AcasăGhid SEO › Cum arată un site pe care Google îl poate citi

Cum arată un site pe care Google îl poate citi

Cum arată un site pe care Google îl poate citi

Ideea centrală a acestui capitol încape într-o frază: ce vedeți dumneavoastră pe site nu e neapărat ce primește Google. Iar când cele două diferă, diferența nu apare nicăieri. Site-ul arată bine, nimeni nu se plânge, iar paginile nu se poziționează.

De ce pot să difere

Browserul dumneavoastră face mult mai mult decât să afișeze un fișier. Execută cod, cere date suplimentare, construiește bucăți de pagină după ce ați ajuns pe ea. Un robot de căutare primește întâi textul brut și abia apoi, poate, execută codul.

În plus, multe site-uri servesc deliberat răspunsuri diferite: o versiune pentru vizitatorii logați, alta pentru cei anonimi, alta din memoria intermediară, alta pentru roboți. Fiecare dintre aceste variante poate fi stricată separat, fără ca celelalte să dea vreun semn.

Cazul întâi: un site întreg fără legături interne

Pe două site-uri de asigurări, construite pe aceeași platformă, am descoperit că fiecare legătură internă din versiunea servită roboților trimitea către pagina de start.

Cardul unui articol arăta așa în codul pe care îl primea Googlebot:

<h2 class="titlu"><a href="/">Cum alegeți polița RCA potrivită</a></h2>

Titlul corect, adresa greșită. Unul dintre site-uri avea 18 articole publicate și niciunul accesibil urmând o legătură. Pagina de start avea în total patru adrese interne distincte, dintre care trei către pagini juridice.

Cauza: site-ul construiește adresele cu o funcție care are nevoie de lista rutelor. Lista aceea era disponibilă doar în browser. La randarea pe server, cineva pusese un înlocuitor care întorcea pagina de start pentru orice adresă cerută, ca randarea să nu se oprească cu eroare. Nu s-a oprit. A produs în tăcere un site fără structură.

Vizitatorii nu vedeau nimic anormal. Codul se executa în browser, legăturile se corectau instantaneu, toată lumea naviga normal.

Doar Google și asistenții AI care nu execută cod primeau varianta ruptă. Adică exact cei pentru care contează legăturile interne.

După reparație, pagina de start a trecut de la 4 la 22 de adrese interne, iar articolele au devenit accesibile. Un efect secundar util: pagina de contact s-a legat singură, fiindcă meniul folosea aceeași funcție defectă.

Cazul al doilea: o bifă care golește legăturile

Pe patru site-uri, caseta cu numele autorului de sub articole conținea o legătură fără destinație:

<a href="" rel="author">Numele autorului</a>

Cauza era o singură opțiune bifată într-un modul foarte răspândit, care dezactivează paginile de autor. Modulul a dezactivat paginile, dar șablonul a continuat să genereze legătura către ele. Rezultatul: o legătură goală pe fiecare articol.

Un vizitator care apasă pe ea rămâne pe loc și crede că i s-a blocat pagina. Un robot vede o semnătură care nu duce nicăieri, deci un autor pe care nu îl poate verifica.

Al doilea caz din aceeași familie, și mai instructiv fiindcă e greșeala noastră. Pe două site-uri scrisesem o regulă de securitate care bloca accesul la un anumit tip de adresă, pentru a limita o metodă de culegere automată a numelor de utilizatori. Regula era corectă ca intenție și prea largă ca formulare: bloca și paginile de autor legitime, care ajungeau redirecționate la pagina de start.

Deci aveam simultan o casetă de autor care trimitea undeva și o regulă proprie care făcea ca acel undeva să nu existe. Ambele scrise cu bună intenție, ambele invizibile fără verificare.

Ce înseamnă „citibil" în practică

ElementulLa ce folosește
Legăturile interne Sunt drumurile prin care se ajunge la paginile dumneavoastră. O pagină la care nu duce nicio legătură e o pagină care aproape nu există
Titlul paginii și descrierea Sunt ce se citește în rezultate, înainte de a intra. Fiecare pagină are nevoie de ale ei, diferite
Un singur titlu principal Spune despre ce e pagina. Subtitlurile organizează restul, în ordine
Datele structurate Traduc în limbaj de mașină ce e pagina: articol, produs, firmă, autor. Nu urcă poziția singure, dar fac informația de necontestat
Textul din imagini Descrierea alternativă. Un robot nu vede fotografia, iar un om care folosește cititor de ecran nici atât

Cum verificați singur, fără unelte

Trei metode, în ordinea efortului.

Căutarea pe propriul site

Scrieți în Google site:domeniul-dumneavoastra.ro. Primiți lista aproximativă a paginilor cunoscute. Dacă numărul e mult mai mic decât ce aveți în realitate, aveți o problemă de acces, nu de conținut.

Vizualizarea codului sursă

Pe orice pagină, apăsați clic dreapta și alegeți afișarea sursei paginii. Se deschide textul brut, adică aproximativ ce primește un robot înainte să execute cod. Căutați în el, cu funcția de căutare a browserului, un fragment din textul principal al paginii. Dacă nu îl găsiți acolo, conținutul e construit ulterior, iar asta merită discutat.

Instrumentul de inspecție din Search Console

Cel mai bun dintre cele trei, fiindcă vă arată chiar ce a văzut Google. Lipiți adresa unei pagini în bara de sus și veți afla dacă e indexată, când a fost vizitată ultima dată și ce probleme a întâlnit.

Regula care rezumă tot capitolul: niciuna dintre problemele de mai sus nu se vede navigând normal pe site.

Un site poate arăta perfect și poate fi, în același timp, ilizibil pentru motorul care ar trebui să vă aducă clienți. De asta verificarea nu e opțională, iar „arată bine la mine în browser" nu e un argument.

De verificat

  • Căutați site:domeniul-dumneavoastra.ro și comparați numărul de rezultate cu numărul real de pagini.
  • Deschideți sursa paginii principale și căutați în ea o frază din textul vizibil.
  • Apăsați, pe un articol, pe numele autorului și pe una din legăturile din meniu. Chiar duc undeva?
  • Deschideți Search Console și citiți raportul de indexare: câte pagini sunt indexate și câte nu, cu motivul.
  • Dacă site-ul e construit pe o platformă care randează în browser, cereți explicit să vi se arate ce primește un robot. E o verificare de zece minute.