Lecții SEO din corectarea propriului nostru site

Am petrecut câteva zile citindu-ne site-ul așa cum îl citește un motor de căutare și am găsit șase lucruri care merită reparate. Fiecare pagină declara două blocuri FAQ, Google folosea ca miniatură o strălucire decorativă din fundal, un set de pagini de șablon se clasa pentru căutări la care nu răspundeau, iar o secțiune nouă a site-ului era blocată de propriul nostru edge din staging. Nimic dramatic. Toate ne costau discret vizibilitate.

Site-ul într-un paragraf

mythex.ai este o aplicație single-page pe care o prerandăm la build: un script parcurge fiecare rută, scrie un fișier HTML static pentru ea și injectează titlul, descrierea și datele structurate ale paginii (blocul JSON-LD care spune motoarelor de căutare ce este o pagină — vezi ce sunt datele structurate). Cea mai mare parte din ce urmează trăiește în pasul de prerendering, pentru că acesta este HTML-ul pe care îl citește de fapt un crawler.

1. Fiecare pagină se declara pagina FAQ

Simptom. Șablonul nostru HTML avea un bloc FAQPage la nivel de site în datele structurate, cu URL-ul indicând spre /faq. Prerendering-ul adăuga apoi propriul FAQPage al fiecărei pagini. Așadar, fiecare pagină de pe site livra două — iar politica noastră de confidențialitate îi spunea lui Google că este pagina FAQ.

De ce contează. Google se așteaptă la cel mult un FAQPage per pagină. Unul în plus, care indică spre altundeva, este genul de lucru care duce la reducerea markup-ului paginii, nu doar la ignorarea lui.

Reparația. Blocul global a dispărut. Markup-ul FAQ al fiecărei pagini vine acum dintr-un singur loc, inclusiv /faq în sine, care îl construiește din lista completă de întrebări. Paginile fără FAQ-uri nu mai declară niciunul, ceea ce este răspunsul onest. Iar prerendering-ul eșuează build-ul dacă vreo pagină mai conține mai mult de un FAQPage. O regulă care trăiește doar în memoria cuiva se încalcă; o regulă pe care o impune build-ul nu.

2. Google folosea pentru noi o altă imagine

Simptom. În rezultatele căutării, miniatura Mythex era strălucirea pulsatilă din spatele hero-ului de pe pagina principală — o imagine decorativă de fundal — în loc de cardul nostru de partajare.

De ce s-a întâmplat. Nu îi spuseserăm lui Google ce imagine reprezintă o pagină, așa că a ales una pe care a găsit-o.

Reparația. Două fețe ale aceleiași probleme:

• Spune care imagine este a paginii. Pagina principală are acum un nod WebPage cu primaryImageOfPage care indică spre cardul de partajare, iar datele structurate ale fiecărei pagini prerandate au propria imagine (imaginea de partajare a paginii sau cea implicită).
• Ascunde decorul. Imaginile de fundal sunt acum interzise în robots.txt și servite cu un header noindex, noimageindex, deci rămân în afara căutării de imagini și a miniaturilor.

3. Motoarele de căutare cunoșteau doar logo-ul nostru

Markup-ul nostru Organization avea un nume, un logo și câteva linkuri către rețele sociale — doar branding, nimic altceva. Motoarele de căutare construiesc panoul de cunoștințe al unei companii din fapte de tip registru, așa că am adăugat cele din licența noastră comercială: denumirea legală, data înființării, fondatorul și adresa înregistrată. Am lăsat intenționat afară numărul de telefon.

4. Paginile de șablon răspundeau la altă întrebare

Simptom. Search Console arăta trei pagini de șablon care adunau impresii și niciun click. Una se clasa pentru "content strategist portfolio" și variantele lui, alta pentru "best italian restaurant website design", a treia pentru un grup în jurul lui "agile board" — jumătate din aceste căutări includeau cuvântul "free". Pozițiile variau de la mijlocul anilor 20 până în anii 50.

De ce. Fiecare pagină răspundea la o altă întrebare decât cea pusă. Cineva care voia să vadă cum arată un design bun pentru un restaurant italian ajungea pe o pagină care îi vindea un builder.

Reparația. Fiecare dintre cele trei are acum o secțiune scrisă pentru căutare, nu pentru produs, un titlu și o descriere cu cuvintele pe care le tastează oamenii, plus întrebări frecvente care merită markup-ul pe care îl emiteau deja.

Același commit a reparat o problemă mai discretă. Blocul "related templates" lua primele patru șabloane dintr-o categorie, așa că fiecare șablon de portofoliu indica spre aceleași patru portofolii, iar restul categoriei nu avea deloc linkuri interne. L-am înlocuit cu un inel ordonat după subcategorie: fiecare pagină de șablon primește acum exact patru linkuri de intrare și patru de ieșire. HTML-ul prerandat afișează acum și aceste linkuri — înainte existau doar după ce rula JavaScript, ceea ce un crawler poate să nu facă niciodată.

5. Anunțăm Bing despre paginile noi chiar în momentul deploy-ului

Google ignoră IndexNow, un protocol prin care se trimit ping-uri motoarelor de căutare când se schimbă un URL. Bing, Yandex și Seznam îl folosesc — iar indexul Bing este cel pe care îl citește căutarea ChatGPT. Un builder de aplicații AI pe care asistenții AI nu îl pot găsi este un fel special de eșec.

Abordarea evidentă, trimiterea întregului sitemap la fiecare deploy, este modul în care o cheie ajunge limitată, iar majoritatea deploy-urilor nu schimbă nimic ce îi pasă unui motor de căutare. Așa că un script compară sitemap-ul pe care îl servește site-ul acum cu cel tocmai construit și trimite doar diferența.

Două detalii au făcut-o să funcționeze:

• Fă un instantaneu înainte de deploy. Baza de comparație trebuie capturată înainte ca noul build să fie live. După aceea, sitemap-ul "live" este deja cel nou și fiecare diferență iese goală.
• Doar pagini noi, deocamdată. Sitemap-ul nostru nu are date lastmod, deci scriptul anunță paginile noi, dar nu rescrierile. Dacă am marca fiecare URL cu data build-ului, întregul site ar apărea ca schimbat la fiecare deploy — exact spam-ul pe care voiam să îl evităm.

Rulează doar la deploy-urile de producție și nu eșuează niciodată build-ul: până când rulează, site-ul este deja live, iar un ping către un motor de căutare nu merită un deploy roșu.

6. Propriul nostru edge spunea "not found"

Când am lansat paginile /ai (mai multe despre ele în o pagină de start pentru fiecare tip de business), staging-ul arăta "Not found" pentru toate, deși host-ul static le servea corect.

Serviciul din fața gazdelor noastre de marketing trimite mai departe doar o listă permisă de căi; orice altceva primește un 404 tare. /ai era nou și nu era pe listă. Am adăugat /ai și /ai/*, cu un test care verifică că trec. O eroare mică, dar exact genul care face o secțiune nouă invizibilă pentru crawlere fără ca cineva să observe.

Ce am învățat

• Citește HTML-ul pe care îl citește un crawler. Majoritatea acestor probleme erau invizibile într-un browser și evidente în fișierul prerandat.
• Transformă regulile SEO în verificări de build. "Un FAQPage per pagină" este acum impus, nu ținut minte.
• Spune motoarelor de căutare ce vrei să spui. Dacă nu spui ce imagine sau ce fapte te reprezintă, vor ghici.
• Search Console îți arată ce întrebare și-au pus oamenii. Impresiile fără click înseamnă de obicei că pagina a răspuns la alta.
• Trimite diferențele, nu totul. Un ping doar pentru ce s-a schimbat te ține în limitele de rate.

Dacă faci același lucru pentru un site pe care l-ai construit, ghidurile noastre despre SEO pentru site-urile construite cu AI și configurarea Google Search Console acoperă bazele.