John Mueller de la Google a răspuns recent la o întrebare postată pe Bluesky despre erori de tip noindex raportate în Google Search Console pentru anumite pagini, o situaţie legată de originile regulilor pentru crawlere, precum robots.txt din anii ’90, dar şi de provocările moderne ale CDN-urilor şi cache-urilor server-side. Problema e că un site poate solicita indexare printr-un sitemap, iar în acelaşi timp Google raportează că aceeaşi pagină are noindex, deci nu poate fi indexată, o contradicţie care-i determină pe administratori să caute ceva invizibil în cod.
Meta-directiva noindex rămâne unul dintre puţinele mijloace prin care proprietarul unui site poate cere explicit unui indexer să nu includă o pagină, dar apare confuzia când Search Console semnalează Submitted URL marked noindex iar tu, ca publisher, nu găseşti niciun noindex în HTML sau în robots.txt. Persoana care a întrebat a spus că eroarea persistă de patru luni şi că nu observă nicio etichetă noindex vizibilă pe site; Mueller a spus că, în cazurile pe care le-a văzut, exista totuşi un noindex vizibil doar pentru Google, ceea ce e greu de diagnosticat, şi a oferit să verifice URL-uri.
Există explicaţii tehnice plauzibile: o pagină care anterior avea noindex ar fi putut rămâne în cache-ul unui plugin de caching sau al unui CDN, precum Cloudflare, iar acel cache ar putea servi vechile antete HTTP către Googlebot, în timp ce proprietarul vede o versiune actualizată. Verificarea antetelor HTTP e simplă şi utilă; instrumente cum sunt cele de la KeyCDN sau SecurityHeaders îţi arată ce antete returnează serverul. Un cod de răspuns 520 e specific Cloudflare şi apare când acesta blochează un user agent, iar discrepanţele între verificatori de antete indică faptul că CDN-ul sau regulile de securitate pot trata cererile diferit în funcţie de IP sau user agent.
Cea mai sigură metodă de a vedea exact ce primeşte Google este să laşi Google să verifice pagina pentru tine, folosind Rich Results Test, care trimite un crawler de la adrese IP Google şi arată atât răspunsul HTTP, cât şi o captură a paginii aşa cum o vede serverul. Instrumentul foloseşte user agent-ul Google-InspectionTool/1.0 şi face verificări reverse DNS, deci dacă serverul sau CDN-ul blochează după IP sau aplică reguli speciale pentru anumite user agent-uri, această metodă prinde problema. Dacă pagina e blocată, testul va raporta mesaje de tipul Page not eligible sau Crawl failed şi, în secţiunea de detalii, va indica detectarea unui robots meta tag cu noindex.
Dacă bănui că noindex-ul e aplicat doar pentru Google, poţi încerca să mimezi Googlebot cu extensia User Agent Switcher pentru Chrome sau cu Screaming Frog configurat să se identifice ca Googlebot; astfel vezi ce răspuns primeşte un user agent care pare Googlebot. Verifică şi setările CDN-ului, regulile de firewall, pluginurile de securitate din WordPress şi log-urile serverului, pentru că problema apare adesea din combinaţia dintre cache, reguli de securitate şi comportamentul crawlerelor.
Rich Results Test oferă o imagine clară a ceea ce vede Google şi poate scoate la iveală un noindex ascuns într-un antet sau în HTML. Pornind de la acest instrument, diagnosticul devine concret şi nu doar o impresie. Ce paşi practici vei încerca mai întâi pentru a depista un noindex invizibil pe site-ul tău?
Fii primul care comentează