Veebilehe kolimine: kontrollnimekiri, et liiklust mitte kaotada

Lühike vastus

Migratsioon kaotab liiklust neljas kohas: katmata 301-ümbersuunamised, ülekandmisel kaduma läinud title'd, kirjeldused ja tekstid, produktsiooni ununenud noindex või Disallow: / ning katkenud hreflang mitmekeelsel saidil. Kõik ülejäänu on teisejärguline.

Seepärast taandub kogu kontrollnimekiri ühele dokumendile: vastavuskaardile „vana URL → uus URL“, kus on kaetud iga aadress, mis viimase 12 kuu jooksul tõi näitamisi või klikke. Kaart tehakse enne arendust. Kui see sünnib lülitamise päeval, on migratsioon juba ebaõnnestunud, lihtsalt sa saad sellest teada kolme nädala pärast.

Liiklus ei lange kolimisest, vaid neljast asjast

Kolimine ise on Google'i jaoks neutraalne: Search Central kirjeldab saidi ülekolimist tavapärase protseduurina ja märgib, et lehepõhiste 301-de puhul kanduvad signaalid uutele aadressidele üle. Sama kehtib serverivahetuse kohta, mida käsitlesin artiklis kas majutus mõjutab positsioone. Langus tekib seal, kus kolimine midagi teel kaotab.

Viimane rida on Eesti projektide eripära. Kolme keelega sait saab pärast kolimist sageli hreflangi, mis viitab eesti- ja venekeelse versiooni endistele aadressidele, ja Google lõpetab versioonide sidumise. Selle märgistuse tüüpvead võtsin eraldi ette materjalis hreflangi seadistamise kohta.

Aadresside vastavuskaart otsustab tulemuse

Kaart on kahe veeruga tabel ja üks reegel: igal vanal aadressil on täpselt üks uus aadress sama tähendusega. Mitte „sarnane sektsioon“, vaid leht, mille pärast inimene lingile klõpsas. Täielikkust mõõdetakse Search Console'i 12 kuu näitamiste järgi, mitte vana sitemap.xml ridade arvu järgi.

Kaart koostatakse neljast allikast ja ükski neist ei kata kõike: crawl näeb ainult seda, millele viidatakse, Search Console ainult seda, mida otsingus näidati, logid ainult viimast kuud.

1. Vana saidi crawl (Screaming Frog, Sitebulb) annab aadressid, mis on siselinkide kaudu leitavad.
2. Aruande „Toimivus“ eksport 12 kuu kohta lehtede kaupa annab aadressid, mis tegelikult liiklust toovad, sealhulgas need, millele saidi sees enam keegi ei viita. Need on orblehed, ja crawl neid ei näita.
3. Serverilogid kuu kohta näitavad, milliseid aadresse Googlebot endiselt külastab ja kuhu tulevad inimesed välislinkidelt.
4. Vana sitemap.xml annab selle, mis oli mõeldud indekseeritavaks.

Seejärel tehakse iga aadressi kohta üks kolmest otsusest: 301 vastele; 404 või 410, kui vastet pole ega tule; või leht säilitab endise aadressi muutmata kujul. Kolmas variant on kõige alahinnatum: kui URL-i struktuur on juba korras, pole seda uuele CMS-ile kolides üldse vaja muuta. Erinevust 301, 404 ja 410 vahel selgitasin artiklis mida kustutatud leht peaks vastama.

Mida vanalt saidilt enne lülitamist maha võtta

Enne väljalaset tehakse vanast saidist tõmmis: mitte failide varukoopia, vaid 4 andmekogumit, mille järgi 30 päeva pärast kaotust otsitakse. Kõik 4 võetakse ühel ja samal päeval, sealhulgas Search Console'i 12 kuu väljavõte, et kuupäevad kattuksid.

• Crawli eksport veergudega URL, title, kirjeldus, H1, sõnade arv, vastuskood. Fail läheb projekti repositooriumi, mitte kirjavahetusse.
• „Toimivuse“ eksport 12 kuu kohta eraldi lehtede kaupa ja seoses „päring → leht“. Search Console hoiab 16 kuu andmeid, kuid pärast kolimist ei taasta ta vanade ja uute URL-ide sidet.
• Väliste linkide nimekiri konkreetsete URL-ide, mitte domeenide tasemel: just neid aadresse ei tohi mitte mingil juhul kaotada.
• Positsioonide hetkeseis põhituuma järgi — lähtepunkt, et kuu pärast vaielda numbrite, mitte tunnete üle.

Lavastuskeskkonnas kontrollitakse täpselt nelja asja: kas see on indekseerimisest suletud (basic-auth on kindlam kui robots.txt), kas title'd ja tekstid vastavad kaardile, kas uued aadressid vastavad 200-ga ilma vahepealsete suunamisteta, kas uus sitemap.xml on kokku pandud. Kuidas see koos robots.txt-ga käib, kirjutasin artiklis sitemap.xml ja robots.txt.

Lülituspäev: toimingute järjekord

1. Võta lavastuskeskkonnalt basic-auth maha ja ava uus sait.
2. Eemalda noindex ja kontrolli produktsiooni robots.txt käsitsi, avades brauseris /robots.txt. See on ebaõnnestumiste arvult toiming number üks: Disallow: / rändab lavastuskeskkonnast produktsiooni regulaarselt.
3. Lülita sisse 301-ümbersuunamised kaardi järgi. Mitte maskiga „kõik vana avalehele“, vaid lehepõhiselt.
4. Saada uus sitemap.xml Search Console'i ja jäta vana kättesaadavaks: see aitab robotil ümbersuunamised kiiremini üles leida.
5. Domeenivahetuse korral esita taotlus tööriistaga „Aadressi muutus“.
6. Kontrolli loendureid: GA4 ja Tag Manager kukuvad malli vahetamisel maha sagedamini kui ümbersuunamised.
7. Lase crawleriga läbi kaardil olevad vanad URL-id ja veendu, et iga vastab 301-ga ühe sammuga.

Seitsmes punkt ongi vastuvõtt: 100 % kaardil olevatest aadressidest vastab 301-ga ühe hüppega, kahe ja enama suunamise ahelaid on null. Kuni crawler pole seda kinnitanud, pole väljalase suletud, isegi kui sait visuaalselt töötab.

Mida kontrollida esimesel kahel nädalal

Iga päev vaadatakse Search Console'i aruannet „Lehtede indekseerimine“. Huvitavad on kolm kategooriat: „Ei leitud (404)“, „Leht ümbersuunamisega“ ja „Leht on duplikaat, Google valis teise kanoonilise URL-i“. Esimene näitab auke kaardis, teine suunamisahelaid, kolmas seda, et uued aadressid konkureerivad omavahel ehk saidile tekkis duplikaatsisu.

Eraldi kontrollitakse kiirust: uus teema toob sageli kaasa fondid, slaiderid ja skriptid, mida varem polnud. Core Web Vitalsi väliandmed Search Console'is arvutatakse 28 päeva libiseva akna järgi, seega tuleb esimene hinnang anda PageSpeed Insightsi laborimõõtmiste järgi ja võrrelda neid väljalaske-eelse seisuga.

Kui kaua langus kestab ja millal on põhjust muretseda

Minu tähelepanekute järgi võtab väikeste teenusesaitide kolimisel stabiliseerumine kaks kuni kolm nädalat. Mitme tuhande lehega kataloogides käib arvestus kuudes: Google ei käi aadresse korraga läbi ja osa vanu URL-e ripub indeksis, kuni robot nendeni jõuab. See pole rike, vaid roomamiseelarve.

Ohumärk pole langus ise, vaid selle kuju.

• Järkjärguline langus, mis kahe kuni kolme nädalaga taastub, on tavaline üleminekuprotsess.
• Järsk kukkumine esimese kolme ööpäeva jooksul üle kogu saidi tähendab noindex-it või suletud robots.txt-i.
• Langus ühes sektsioonis tähendab kaardist puuduvat tükki.
• Ühtlane plats tuntavalt madalamal tasemel poolteise kuu pärast tähendab kadunud sisu: tekstid lõigati malli ülekandmisel ära, ja liiklus ei tule tagasi enne, kui tekst tuleb tagasi.

Mis läheb Eesti projektides kõige sagedamini katki

Kolm asja korduvad projektist projekti. Esimene: arendaja kolib eestikeelse versiooni, vene- ja ingliskeelse jätab „hiljemaks“, ja sait elab kuu aega katkiste keeleseostega. Teine: eestikeelsed aadressid kaotavad täpitähed uut moodi, vana URL sisaldas õ-d protsendikodeeringus, uus translitereerib selle o-ks, ja aadressid ei klapi seal, kus keegi seda ei oodanud. Kolmas: vanal saidil elas venekeelne versioon alamdomeenil, uuel elab kaustas, ja alamdomeeni ümbersuunamiste kaarti lihtsalt ei koostata, sest crawl käis mööda põhidomeeni.

Kõik kolm püütakse ühe tegevusega kinni: vana saidi crawl käivitatakse Screaming Frogis iga keelesektsiooni kohta eraldi ja vastavuskaart koostatakse eraldi eesti-, vene- ja ingliskeelse versiooni jaoks.