Avate Google Search Console, et kontrollida indekseerimist, navigeerite saidikaardi aruandesse ja näete staatust „Couldn't fetch". Tuttav olukord?

See viga võib tekitada paanikat: tundub, et Google ei näe teie saiti üldse ja kõik lehed hakkavad indeksist kaduma. Tegelikkuses laheneb olukord peaaegu alati 10-15 minutiga ning pooltel juhtudel pole probleem isegi teie poolel.

Allpool on tõestatud algoritm: diagnoosist kuni täieliku lahenduseni. Ilma udujututa, konkreetsete sammude ja Search Console'i liidese tõeliste ekraanipiltidega.

💡 Kiire ülevaade:

• Kontrollige, kas viga on tõeline: sageli on see Google'i tõrge ja peate lihtsalt ootama või taotlema uut läbivaatust
• Testige saidikaardi ligipääsetavust URL-i kontrolli ja reaalajas testi abil: see võtab minuti ja näitab kohe, kas Google näeb teie faili
• Kui viga on tõeline, minge läbi kontrollnimekiri: XML-i valideerimine, robots.txt, pluginad, serveri vastus
• Keerukamatel juhtudel kasutage kolmandate osapoolte diagnostikavahendeid ja esitage saidikaart uuesti Search Console'i liidese kaudu

Miks Google ei saa saidikaarti kätte

Probleemi juur tuleks jagada kaheks: viga Google'i poolel ja viga teie poolel. Erinevus on põhimõtteline, sest esimesel juhul ei pea te üldse midagi tegema.

Search Console'i tõrge. Alates Search Console'i liidese suurest uuendusest on sagenenud olukorrad, kus staatus „Couldn't fetch" on vale. Google üritab saidikaarti laadida, süsteemis endas läheb midagi valesti ja aruanne näitab viga, kuigi fail serveris on täiesti korras. Google'i insenerid on sellest probleemist teadlikud ja ametlik dokumentatsioon ütleb otse: kui toomine ebaõnnestub, proovib süsteem mõne päeva jooksul uuesti ja alles pärast mitut ebaõnnestumist lõpetab kontrollimise.

Tegelik kättesaamatus. Saidikaarti füüsiliselt ei serveerita: katkine XML, vale Content-Type, blokeering robots.txt-s, turvaplugin, mis lükkab Googleboti päringud tagasi, valesti seadistatud CDN või tulemüür. See hõlmab ka domeeni aegunud SSL-sertifikaate, mis takistavad Google'il turvalise ühenduse loomist.

Kaudsed põhjused. Mõned WordPressi pluginad (eriti turva- ja vahemällu salvestamise pluginad) võivad kogemata blokeerida Googleboti User-Agenti. Mõnikord pole süüdlane see plugin, mida esimesena kahtlustaksite; probleem avaldub ahelreaktsioonina: vahemälu plugin loob saidikaardi lehest staatilise koopia, samal ajal kui turvaplugin blokeerib päringud sellele koopiale.

Kuidas kontrollida, kas saidikaart on ligipääsetav

Kiireim viis Google'i vea eristamiseks tõelisest probleemist on URL-i kontrollimise tööriist otse Search Console'is. See näitab, mida Googlebot failile juurdepääsul näeb.

1. samm. Avage Search Console, kleepige saidikaardi täielik URL liidese ülaosas olevale kontrolliribale ja vajutage Enter.

2. samm. Kui URL ei ole indekseeritud (see on saidikaartide puhul normaalne, kuna neil on tavaliselt noindex), klõpsake nuppu „Testi reaalajas URL-i". Search Console teostab reaalajas testi, pääseb failile reaalajas juurde ja näitab tulemust.

3. samm. Kerige reaalajas testi lehel alla jaotiseni „Lehe toomine". Kui seal on kirjas „Õnnestus", näeb Google faili ja viga „Couldn't fetch" saidikaartide aruandes on Search Console'i poolne viga. Ärge tehke midagi: olek uueneb järgmise kontrollitsükli ajal või esitage saidikaart uuesti saidikaartide aruande nupu kaudu.

Kui lehe toomine näitab viga, jätkake järgmise jaotisega.

Samm-sammuline lahendus: viiepunktiline kontrollnimekiri

Kui reaalajas test kinnitab, et Google tõesti ei saa saidikaarti kätte, minge punkte järjekorras läbi. Iga järgmine samm kehtib ainult siis, kui eelmine probleemi ei lahendanud.

1. Kontrollige XML-i kehtivust

Avage saidikaardi URL oma brauseris. Kui näete puhast XML-i siltidega <urlset> ja <url>, on struktuur korras. Kui leht on tühi, annab PHP vea või näitab valget HTML-lehte, on saidikaart katki.

Põhjalikumaks kontrolliks kasutage XML Sitemap Validatorit, tasuta veebitööriista, mis näitab vormindusvigu, katkisi URL-e saidikaardis ja mittevastavust Sitemap Protocoli standardile. See ütleb teile ka, kas 50 000 URL-i piirang faili kohta on ületatud (sel juhul vajate saidikaardi indeksit).

2. Kontrollige robots.txt-d ja serveri päiseid

Googlebotil peab olema juurdepääs saidikaardi failile. Avage yoursite.com/robots.txt ja veenduge, et seal pole sellist rida:

1
Disallow: /sitemap.xml
2

Samuti kontrollige, et Googleboti User-Agent ise poleks blokeeritud reaga nagu User-agent: Googlebot, millele järgneb Disallow: /.

Serveri vastuse Content-Type päis peaks olema application/xml või text/xml. Kui server serveerib saidikaarti kui text/html, ei pruugi Google faili ära tunda. Päiseid saate kontrollida TechnicalSEO Fetch & Renderi kaudu, mis näitab lehte Googleboti silmade läbi koos kõigi HTTP-päistega.

3. Kontrollige WordPressi pluginaid

Turvapluginad (Wordfence, Solid Security, Sucuri) ja vahemällu salvestamise pluginad (WP Rocket, W3 Total Cache, LiteSpeed Cache) on peamised kahtlusalused. Algoritm:

• Vahemälu pluginad. Tühjendage vahemälu, välistage ajutiselt sitemap.xml vahemällu salvestamisest. WP Rocketis on väli „Never cache URLs"; LiteSpeed Cache'is vahekaart „Excludes". Pärast välistamist tühjendage vahemälu uuesti.

• Turvapluginad. Kontrollige plugina logisid blokeeritud päringute osas failile sitemap.xml User-Agentilt Googlebot. Wordfence näitab selliseid blokeeringuid reaalajas jaotises „Tools → Live Traffic".

• SEO pluginad. Mõnikord peitub probleem saidikaardi generaatoris endas. Yoast SEO, Rank Math, All in One SEO, igaühel on oma töötleja. Proovige saidikaart uuesti genereerida: Yoast SEO-s tehakse seda jaotises „Settings → Site features → XML sitemaps" (lülitage välja ja sisse); Rank Mathis jaotises „Sitemap Settings → Save changes".

4. Välistage hostingu ja CDN-i blokeering

Mõned hostiteenuse pakkujad ja tulemüürid (Cloudflare, Sucuri WAF) võivad blokeerida Googleboti päringuid IP või User-Agenti alusel. Kontrollige:

• Cloudflare. Jaotises „Security → Events" otsige blokeeritud päringuid failile sitemap.xml. Kui leiate, looge WAF-i reegel, mis lubab User-Agenti Googlebot URL-idele, mis sisaldavad sitemap.

• Hosting tulemüür. Mõnel juhtpaneelil (cPanel, ISPmanager) on sisseehitatud ModSecurity reeglid, mis käivituvad valepositiivselt XML-failide puhul. Kontrollige Apache/NGINX-i logisid 403 vigade osas failile sitemap.xml juurdepääsul.

5. Esitage saidikaart uuesti

Pärast põhjuse kõrvaldamist minge tagasi Search Console → Saidikaardid → kleepige saidikaardi URL väljale „Lisa uus saidikaart" → Esita. Süsteem üritab faili kohe laadida. Kui olek muutub „Õnnestus", on probleem lahendatud.

Oluline märkus: isegi pärast saidikaardi edukat laadimist ei garanteeri Google kõigi selles loetletud URL-ide indekseerimist. Indekseerimise kiirus ja täielikkus sõltuvad saidi suurusest, autoriteetsusest ja sisu uuendamise sagedusest.

Diagnostikavahendid

Lisaks Search Console'i sisseehitatud tööriistadele hoidke käepärast kolme välist tööriista; need katavad praktiliselt kõik diagnostilised stsenaariumid:

• XML-Sitemapsi veebivalidaator, struktuuri validaator. Kontrollib süntaksit, URL-ide arvu, pesastatud saidikaardi indekseid ja vastavust Sitemaps.org standardile. Tasuta, registreerimine pole vajalik.

• Fetch & Render, Googleboti emulaator. Näitab, kuidas Google lehte näeb: HTTP-päised, olekukood, renderdatud HTML. Kasulik, kui peate mõistma, kas server asendab sisu erinevate User-Agentide jaoks.

• PageSpeed Insights, kaudne, kuid oluline tööriist. Kui server vastab aeglaselt (TTFB üle 1-2 sekundi staatilise XML-faili puhul), võib Google suure saidikaardi laadimisel ühenduse katkestada.

⁉️🤔 Korduma kippuvad küsimused

Miks viga „Couldn't fetch" ilmub ja kaob ilma minupoolse tegevuseta?

See on klassikaline käitumine Google'i poole vea puhul. Süsteem kontrollib saidikaarti perioodiliselt oma ajakava järgi uuesti ja teatud hetkedel põhjustab sisemine tõrge valepositiivse vea. Järgmine automaatne kontroll sageli õnnestub, mistõttu staatus vilgub. Kui saidikaart on füüsiliselt ligipääsetav (kontrollitud reaalajas testiga), ignoreerige vilkumist; see ei mõjuta indekseerimist.

Kui sageli kontrollib Google saidikaarti pärast edukat laadimist?

Korduskontrolli ajakava ei ole seotud tavalise saidi läbivaatusega. Google ei avalikusta täpset sagedust, kuid praktikas jääb see aktiivsete saitide puhul vahemikku mitu korda nädalas kuni kord paari päeva jooksul. Kui olete saidikaardis suuri muudatusi teinud ja soovite töötlemist kiirendada, esitage see uuesti saidikaartide aruande nupu „Esita" kaudu.

Kas viga võib olla seotud saidikaardi suurusega?

Jah. Piirang on 50 000 URL-i ja 50 MB faili kohta. Kui saidikaart ületab kumbagi piiri, ei pruugi Google seda töödelda. Lahendus on saidikaardi indeks: üks ülem-XML, mis viitab mitmele alamfailile, millest igaüks jääb piiridesse. Enamik WordPressi SEO pluginaid teeb seda automaatselt, kui lävi on ületatud.

Kas ma peaksin saidikaardi lisama robots.txt-sse?

Tungivalt soovitatav. Lisage robots.txt-sse direktiiv Sitemap: https://yoursite.com/sitemap.xml; see annab Google'ile teise võimaluse faili avastamiseks. Isegi kui Search Console'i liidese kaudu esitamine ebaõnnestub, võib Google saidikaardi leida robots.txt läbivaatamisel.

Kas saidikaardi toomise viga mõjutab asetust?

Otseselt mitte. Google ei määra karistusi saidikaardi kättesaamatuse eest. Kaudne mõju on võimalik: ilma saidikaardita võivad uued või harva uuendatavad lehed indekseerimist kauem oodata, eriti suurtel ja keeruka struktuuriga saitidel. Väikeste, hea sisemise linkimisega saitide puhul on saidikaardi puudumine praktiliselt märkamatu.

Saidikaart pole saadaval: mida kohe teha

Algoritm taandub kolmele sammule, mis katavad valdava enamuse juhtudest:

• Reaalajas test. Kleepige saidikaardi URL Search Console'i kontrolliribale → klõpsake Reaalajas test. „Lehe toomine: Õnnestus" → viga on vale, ärge tehke midagi. „Ebaõnnestus" → jätkake edasi.

• Serveripoolne diagnoos. Avage sitemap.xml oma brauseris; kas näete puhast XML-i? Kontrollige robots.txt-st Disallow? Tühjendage vahemälu ja kontrollige turvaplugina logisid? Käivitage fail läbi XML Sitemap Validatori?

• Uuesti esitamine. Kõrvaldage põhjus → minge tagasi Saidikaardid → Esita. Olek muutus „Õnnestus"? Valmis. Kui mitte, minge tagasi punkti 2 juurde ja kontrollige serveri päiseid Fetch & Renderi kaudu.

Kui lähenete diagnoosimisele süstemaatiliselt ega jäta samme vahele, laheneb probleem ühe kontrollitsükli jooksul. Ja valed Search Console'i vead, mis moodustavad hea poole selleteemalistest pöördumistest, ei vaja üldse sekkumist.