Veebilehe migratsioon: kuidas vana sait uuele üle viia (ilma SEO kaotuseta)

Miks migratsioon on hirmutav (ja miks see ei pea olema)

Vana sait elas viis aastat. Aja jooksul on Google'is kogunenud sadu sissetulevaid linke, kümneid edetabelitop-positsioone, ja kahjuks ka palju vananenud teemat, mis ei tööta enam korralikult. Aeg on uue jaoks. Aga kuidas üle minna nii, et homme ei tabaks sind 60% liikluse langus?

See on hirm, mille tõttu paljud Eesti ettevõtted jäävad oma vana saidi külge kinni. „Saame ju hakkama, las see jääb." Tegelikult on migratsioon kontrollitav projekt, kui sa lähened sellele süstemaatiliselt. Probleem pole migratsioon ise, vaid hooletu migratsioon: keegi vahetab serverit reedel, deploy'b uue saidi laupäeval ja esmaspäeval imestab, miks Google'is enam blogi-postitusi ei näe.

Selle artikli mõte on anda sulle terve raamistik. Kõik, mida me Veebimetsas teeme, kui klient kolib WordPressist meie custom-platvormile, või vahetab Voogi WooCommerce'i vastu, või lihtsalt teeb redesigni ja URL-id muutuvad. Käime läbi ka tehnilised detailid, mis tihti unustatakse: hreflang, canonical, sitemap, Search Console.

Migratsiooni tüübid: mis sa täpselt teed

Sõna „migratsioon" tähendab erinevatele inimestele erinevaid asju. Vaata enne tööd, mis tüüpi migratsiooniga sul tegu on, sest iga tüüp toob omad riskid.

• Hostingu vahetus. Sait jääb samaks, ainult koliid teisele serverile. Madalaim risk, kui DNS õigesti ümber lülitada.
• Platvormi vahetus. WordPressist Webflow'i, Voogist custom'i. Sisu ja URL-id liiguvad kaasa, aga tehnoloogia muutub. Keskmine risk.
• Disaini-update koos URL-de muutusega. Sama platvorm, aga uus struktuur. Iga vana URL vajab uue vastet ja 301-redirektit. Kõrge SEO-risk, kui linke ei kaardistata.
• Domeeni vahetus. vanafirma.ee → uusfirma.ee. Suurim SEO-risk. Iga sissetulev link viib vanale domeenile, mis tuleb täielikult uuele suunata.
• HTTP → HTTPS. Tehniliselt URL-de muutus (http:// kõik ümber tehakse https://'iks). Google näeb seda eraldi saidina, kui pole õigesti tehtud.
• Täielik rebrand. Domeen + platvorm + sisu + URL-id, kõik muutub. Kõige raskem. Vajab kahe-kolme kuu plaani.

Mida suurem ja keerukam migratsioon, seda olulisem on plaan. Hostingu vahetus saab olla pärastlõuna; rebrand vajab kahekuulist projekti.

Mida sa võid kaotada, kui valesti teed

Praktilised numbrid sellelt, mis võib kaotsi minna:

• Orgaaniline liiklus. Halb migratsioon võib teha 20–80% liikluse langust kahe nädalaga. Eesti väikese e-poe puhul, mis sai 2000 külastust kuus Google'ist, võib see tähendada 1000+ külastust ja 30+ tellimuse kaotsiminekut.
• Edetabeli positsioonid. Aastatega ehitatud rankings „kodulehe tegemine" otsingule võivad kaduda, kui Google näeb URL-i 404 või kui sisu pole identifitseeritav.
• Sissetulevad lingid. Iga ärihoone, blogi-postitus või kataloog, mis su vanale URL-ile viitab, viib pärast 404 leheküljeni. Lingi „mahl" kaob.
• Search Console ajalugu. Kui domeen muutub, alustab Search Console nullist. Andmed jäävad alles vana profiili sees, aga uue koguned mitu kuud.
• E-mail downtime. Kui MX-kirjed ei lähe sünkroonis üle, läheb uue saidi käivitumise hetkest paar tundi maile kaduma.
• SSL-vead. Kui SSL pole uuel serveril valmis, näevad külastajad „mitte turvaline" hoiatust. Selle hirm langetab konversiooni 80% võrra mõneks ajaks.

Kõike seda saab vältida. Vaatame kuidas.

Migratsiooni neli faasi

Iga korralik migratsioon, ükskõik kui suur, jaguneb neljaks faasiks: inventuur, ehitus staging'us, cutover ja jälgimine. Kestus muutub, struktuur jääb samaks.

Aja jaotus tüüpilisel projektil:

• Inventuur: 1 nädal. Saidi inventeerimine ja andmete export.
• Ehitus + sisu: 4–6 nädalat. Suurim osa ajast.
• Cutover ehk üleminek: 1 päev. Kõige stressim, aga kõige lühem.
• Jälgimine ja parandused: 6 nädalat. Vaikselt jooksvalt.

Faas 1: inventuur (mis vanal saidil päriselt on)

Esimene asi, mida me iga migratsiooni alguses teeme: anname vanale saidile täieliku röntgenipildi. Sa pead teadma kõike, mis seal on, enne kui hakkad uut ehitama. Ilma selleta avastad pärast launchi 30 lehte, mis polnud uues saidis, sest keegi unustas need.

Tehniline crawl. Tasuta tööriist Screaming Frog SEO Spider (kuni 500 URL-i tasuta) lubab kogu saidi läbi käia. Saad lehtede nimekirja, pealkirjad, meta-kirjeldused, status-koodid (200, 301, 404), pildid, lingid. Salvesta CSV-na.

Sissetulevate linkide kaardistus. Tasuta Google Search Console > Lingid. Sealt näed, kes su lehele viitab. Need on kõige tähtsamad URL-id, mille SEO-väärtus pead säilitama. Kui suunad lehe, mis sai 50 sissetulevat linki, „avalehele", võid kõik need lingid SEO mõttes ära visata.

Analytics-eksport. Google Analytics 4 > vali viimane 12 kuud > top lehed. Top 50 lehte annavad sulle 80% liiklusest. Kindlustad, et need on uuel saidil õigele kohale suunatud.

Sisu inventuur. Spreadsheet, kus iga rida on üks leht, ja veerud: vana URL, uus URL, status (alles, kustutatud, ühendatud, uus), märkused. See dokument muutub migratsiooni keskpaketiks.

Tehnilised eripärad.

• Kas saidil on kohandatud 404-leht?
• Kas robots.txt blokeerib midagi?
• Kas on hreflang-kirjed (mitmekeelne sait)?
• Kas on canonical-kirjed?
• Mis Schema.org markup on toodete/teenuste juures?
• Mis tracking-skriptid on (GA4, GTM, Meta Pixel)?

Backup. Failid + andmebaas. Tee neist kaks koopiat eri kohas. Kui midagi läheb migratsiooni ajal valesti, on see ainus võimalus tagasi pöörduda. Veebimetsas hoiame kuud kuus migratsiooni-backup'e.

Faas 2: URL-de kaardistus ja 301 redirektid

301 redirect on kõige tähtsam tehniline element migratsioonis. See ütleb Google'ile ja brauserile: „leht liikus jäädavalt. Kasuta nüüd uut URL-i, ja kanna kogu SEO-väärtus üle."

Iga vana URL, mille uuel saidil enam pole, peab saama 301-redirect uuele lähedasele lehele. Kui uut lähedast lehte pole, suunad ülemkategooriale. Mitte avalehele, see hävitab SEO-väärtuse.

Spreadsheeti struktuur, mida me Veebimetsas iga migratsiooni juures kasutame:

Vana URL	Status	Uus URL	Redirect-tüüp
/teenused/kodulehed.html	Liigutud	/veebilehed	301
/teenused/?id=12	Liigutud (URL puhastatud)	/veebilehed	301
/blogi/wp-?id=42	Liigutud + ümber-nimetatud	/blogi/kohalik-seo	301
/vana-pakett-promo	Eemaldatud, ülemkategooria sobib	/hinnad	301
/test-leht-2018	Jäädavalt eemaldatud	(puudub)	410 Gone

Kuidas redirektid päriselt seadistada?

Apache (.htaccess) puhul:

Nginx puhul:

Cloudflare või suuremate hostide puhul saab redirektid teha veebipaneeli kaudu. Cloudflare „Redirect Rules" lubab loogikat ka query-parameetrite jaoks.

Tähtsad reeglid:

• 301 (jäädav), mitte 302 (ajutine). 302 ei kanna SEO-väärtust üle.
• Üks redirect, mitte ahel. A → B → C kaotab umbes 10–15% lingijõust iga sammu juures. Ülev otse A → C.
• Sees-domeen, mitte protokoll-vahetus eraldi. Kui kolid HTTP → HTTPS samaaegselt, ühenda need üheks redirektiks (http://vana.ee/x otse https://uus.ee/y).

Faas 3: ehitus staging'us ja testimine

Uut saiti ei tohi ehitada produktsioonis. Kasuta staging-keskkonda: see võib olla staging.veebimets.ee, uus.veebimets.ee, või eraldi serveris tmp123.netlify.app. Mis iganes, peaasi et see oleks brauserile ligipääsetav, aga Google'ile blokeeritud.

Robots.txt staging'us peab olema:

Lisaks <meta name="robots" content="noindex,nofollow"> kõigi lehtede peal. Kui Google indekseerib su staging'i, oled topeltsisuga (sama mis vana sait, ehk vana ja staging konkureerivad), mis on SEO-õudusunenägu.

Kui staging on käes, vaata kõik need asjad pungalt üle:

Käivita Screaming Frog ka staging'is. Võrdle URL-de loendit, leiad kohe puudujääke. „Vana saidil oli 247 URL-i, uuel on 198, kus on need 49?"

Faas 4: migratsioonipäev (cutover)

See on stressirikkaim päev kogu projektis. Aga kui ettevalmistus on tehtud, on cutover ise umbes kaks tundi tehnilist tööd. Plaan välja näeb umbes nii:

Plaani-päev ja -kellaaeg. Ära käivita reede õhtul, vajad järgneva päeva jaoks energiat. Veebimetsas teeme migratsioone tavaliselt teisipäeva-kolmapäeva hommikul kell 9–11. Liiklus on madal, klient on tööl ja vastab telefonile, ja sul on terve nädal probleemide lahendamiseks.

Mis võib minna valesti ja kuidas reageerida:

• SSL ei tööta uuel domeenil. Let's Encrypt on automaatne, aga vahel võtab esimese seadistuse. Lülita Cloudflare „Flexible SSL" ajutiseks, kuni proper sertifikaat valmis.
• 301-id ei tööta. Käivita ühe vana URL-i kontroll: curl -I https://veebimets.ee/vana-leht. Vastus peaks olema HTTP/2 301. Kui pole, kontrolli .htaccess või nginx-konfi.
• DNS ei levinud. Mõned ISP-d hoiavad DNS-cache pikalt. Sa näed uut saiti, mõni klient näeb veel vana. See on normaalne 1–24 tundi.
• E-mail ei saabu. MX-kirje pole õigesti pandud. Iga sekund maksab, paranda esimesena.

Pärast: 6 nädalat valvet

Cutover on tehtud, sait elab. Aga töö pole läbi. Järgmised 6 nädalat on jälgimine. Selle aja jooksul Google indekseerib uue saidi täielikult ja sa näed migratsiooni tegelikku mõju.

Mida konkreetselt jälgida:

• Server-i 404 logid. Kõik vana URL-id, mis puudusid sinu redirect-tabelis, saabuvad logide kaudu. Lisa neid kohe redirektidesse.
• Search Console > Pages. Vaata, mitu lehte on indekseeritud, mitu „Crawled but not indexed", mitu „Excluded". Norm on, et numbrid liiguvad esimesel nädalal.
• Search Console > Performance. Võrdle „Average position" enne ja pärast. Kui mõni märgilise sõna positsioon on kukkunud 2-lt 12-le, oled konkreetse lehe migratsiooni viga.
• GA4 liikluse trend. Esimene 1–2 nädalat võivad numbrid olla 10–30% madalamad. Kui kukub 50%+, on midagi katki, otsi probleem üles.
• Konversioonid. Vormi-saadetised, ostud. Kui need kukuvad, kontrolli, kas vormid uuel saidil töötavad (sageli unustatakse spam-protection või email-routing).

Vead, mis võivad SEO ühe ööga maatasa lüüa

1. Robots.txt blokeerib uue saidi. Staging'us oli „Disallow: /", keegi unustas eemaldada. Google ei saa midagi indekseerida. Kontrolli kohe pärast launchi.
2. Sitemap.xml viitab vanadele URL-idele. Sitemap genereeriti enne URL-de muutusi. Lae kohe uus üles.
3. Canonical-kirjed osutavad vanale domeenile. Sageli tuleb seda kontrollida käsitsi, sest mõnel platvormil on vaikimisi „https://staging.veebimets.ee" hardcoded.
4. 301 ahelad asemel 302. Vaikimisi mõned WordPress-pluginad teevad 302. Google ei usalda 302-e ja ei kanna SEO üle.
5. Trailing slash inkonsistents. Vana sait oli /teenus/, uus on /teenus. Iga vana link saab 301, mis on OK, aga sisemised lingid uuel peaksid olema otse õiged.
6. Pildid kadunud. Pildi-URL-id muutusid, blogi-postitustes osutavad vanad lingid kuhugi. Käivita pildi-puudumise crawl.
7. Hreflang puudub mitmekeelsel saidil. Google ei tea, mis on EE versioon ja mis EN. Iga keel jääb omavahel konkureerima.
8. Search Console verifitseerimine pole tehtud. Ei saa esitada sitemap'i, ei näe probleeme. Tee see esimese asjana.
9. Vana hosting tapeti enne aega. Vana sait kustutati, aga DNS-cache mõnel kasutajal viitas veel vanale. Need kasutajad saavad „connection refused". Hoia vana 4 nädalat aktiivsena.
10. Suuremad failid (PDF, DOC) puuduvad uuelt saidilt. Inimesed otsivad „Veebimets hinnakiri 2024 PDF" Google'is, klikivad, saavad 404. Kui PDF kunagi indekseeritud sai, lisa selle 301-redirect uuele PDF-ile.

Kokkuvõte: täielik checklist

Lühike kontroll-loend, mille saad kopeerida ja oma migratsioonis kasutada.

Migratsioon on üks neid asju, kus 80% õnnestumisest tuleb õigest planeerimisest enne, mitte tehnikast hetkel. Kui kogu spreadsheeti-töö on tehtud, on tegelik üleminek lihtne. Kui inventuur jäi tegemata, kannad seda kuid edasi parandustega.

Tahad migratsiooni teha rahulikuna ja teadlikuna? Võta meiega ühendust ja paneme paika täpselt sinu projekti plaani. Vaatame vana saidi üle, koostame URL-de mappingu ja teeme cutover'i sinu eest. Pärast jälgime numbreid 6 nädalat, et oleme kindel, et kõik on korras.

Vaata ka tehnilisi taustaartikleid: kuidas veebileht päriselt töötab ja domeen ja hosting Eesti ettevõttele.