Sisällysluettelo
Sivustomigraatioiden piilotettu riski
Verkkosivuston migraatio on hyvin usein aliarvioitu riski nimenomaan hakukoneoptimoinnin, löydettävyyden ja liikenteen näkökulmasta.
Koko projekti vaikuttaa puhtaasti tekniseltä kokonaisuudelta – sivusto siiretään uudelle alustalle, koodi modernisoidaan, rakenteet päivitetään , kuvapalvelin vaihdetaan. Mutta hakukoneiden näkökulmasta kyseessä on erittäin merkittävä liiketoimintahanke, joka voi tuhota vuosien rakennetun näkyvyyden muutamassa viikossa.
Tämä tapahtuu usein suurilla verkkokaupoilla tai korkean volyymin sivustoilla. Sivusto migroidaan Server-Side Renderingistä(SSR) Client-Side Renderingiin(CSR) modernimman ja nopeamman lopputuloksen vuoksi. Useampi verkkosivusto tai verkkokauppa yhdistetään yhdeksi sivustoksi ja vanhoja sivustoja ajetaan alas ilman kontrollia. Tai sivusto uudistetaan useampaan otteeseen lyhyen aikavälin sisällä jolloin tekninen velka kasvaa huomattavasti. Vain muutama asia mainitakseni:
- rikkinäiset uudelleenohjaukset ja uudelleenohjausketjut
- väärin asetetut kielitagit (HREFLang)
- muuttuneet osoitepolut
- rikkinäiset linkit
Näistä tilanteista puhutaan harvemmin avoimesti. Kun sivuston näkyvyys putoaa parissa viikossa 50% ja kävijämäärät siinä samalla niin ei niistä haluta kirjoittaa julkisesti. Ymmärrettäväähän se on, mutta kymmeniä ellei satoja näitä nähneenä, ongelmat ovat hyvin yhdenmukaisia ja lähes poikkeuksetta ehkäistävissä. Yhtenäinen nimittäjä näissä on se, että projektista uupuu lähes joka kerta pätevä SEO-osaaminen.
Tässä artikkelissa haluan nostaa migraatiota keskiöön eri kulmista. Mitä niissä menee pieleen? Mitä vaikutuksia sillä on lyhyellä ja pitkällä aikavälillä, miten nämä ongelmat voidaan välttää ja miten epäonnistuneista tilanteista voidaan selvitä eli ns. migration recovery.
Mikä on verkkosivustomigraatio?
Yksinkertaisimmillaan sivustomigraatiolla tarkoitetaan mitä tahansa merkittävää muutosta sivuston alustassa, rakenteessa, osoitteistossa(URL) tai visuaalisessa toteutuksessa, joka vaikuttaa siihen miten hakukoneet ja käyttäjät löytävät sekä kokevat sivuston.
Pinnallisesti ajataltuna sitä voidaan katsoa siis ”teknisenä päivityksenä”.
Hakukoneiden näkökulmasta migraatio on kuitenkin sivuston identiteetin ja osoitekirjan muutos. Se on prosessi, jossa sivuston rakenne, tekninen toteutus, osoitteisto tai sijainti muuttuu niin, että hakukoneen täytyy opetella ja oppia tuntemaan sivusto ja sen yksittäiset sivut uudelleen.
Sivusto ei ”vain” muutu, vaan jokainen tekninen/rakenteellinen muutos pakottaa hakukoneen arvioimaan sivun URL-osoitetta, koodia ja saavutettavuutta uudelleen. Tämä vaikuttaa luonnollisesti siihen miten sivusto pärjää hakutuloksissa.
Ymmärryksen puute siitä miten ja mihin kaikkeen migraatio vaikuttaa on se yleisin asia, joka aiheuttaa liiketoiminnallisia menetyksiä.
Mitä eri migraatiotilanteita on olemassa?
Yleisesti tunnistetut ja suuren mittaakaavan migraatiot voidaan karkeasti kuvata viidellä pääkategorialla mittakaavan ja teknisen luonteensa mukaan. Jokainen näistä on merkittävä muutos jota yleensä edeltää useamman kuukauden tai vuosien suunnittelu.
Selkeä ja ilmeiset migraation kohteet
- Suuren luokan strategiset migraatiot
- Domain- ja brändimigraatio: Siirtyminen kokonaan uuteen osoitteeseen esim. fi –> com
- Yrityskaupat ja sivustojen yhdistäminen: Kahden tai useamman eri organisaation verkkosivustot sulautetaan yhdeksi kokonaisuudeksi
- Alusta ja CMS:n(Content Management System) vaihto: Siirtyminen järjestelmästä toiseen esim. Joomla –> WordPress, Webflow –> Headless CMS
- Rakenne- ja arkkitehtuurimigraatiot
- URL-struktuurin ja kategorioiden uudistus: Kategoriarakenteen tiivistäminen/laajenaminen, URL-polkujen siistiminen /kategoria/tuote/ —> /tuote/
- Sisällön massapäivitykset tai karsinta (Content Pruning): Satojen tai tuhansien sivujen poistaminen/yhdistäminen
- Blogi- tai aliosion siirto alidomainilta päädomainille tai toisinpäin: esim. blogi.yritys.fi –> yritys.fi/blogi/
- Visuaaliset ja tekniset käyttöliittymäuudistukset
- Visuaalinen uudistus samalla alustalla: URL:t pysyvät samoina, mutta sivupohja tai visuaalinen kokonaisuus muuttuu jolloin koodin rakenne ja hierarkia myös muuttuvat
- Sovellusarkkitehtuurin muutos: Esim. SSR –> CSR, HTML-sivuston muuttaminen Single Page App-rakenteeksi (React, Vue jne.)
- Kansainvälistyminen ja paikallistaminen
- Monikielisyyden ja aluekohtaisten sivujen pystytys: Siirtyminen yksikielisyydestä kansainväliseksi (domainrakenteet)
- HREFLang-toteutuksen ja geo-kohdistamisen rakentaminen. kieli- ja aluemerkinnät
- Infrastruktuuri- ja protokollamuutokset
- Palvelin- ja CDN-migraatio: Siirto uudelle palvelimelle tai CDN-verkon taakse, palvelinvasteet, -kuormitus, välimuistirakenteet ja nimipalvelinmuutokset
- Protokollamuutokset ja turvallisuuspäivitykset: http –> https, HTTP/1.1 –> HTTP/2
”Näkymättömät migraatiot” eli hiljaiset liikenteen tappajat
Näitä ei nähdä migraatioina, koska ”sivusto on edelleen täysin sama” tai ”tämä on vain yksi pieni kehitystiketti”. Lopputulema voi olla merkittävä orgaanisen liikenteen romahdus ja kallis korjausprojekti.
Tämänkaltaiset migraatiot ovat muutosprosesseja, joita kehitystiimi, suunnittelijat tai vaikka liiketoimintajohto eivät pidä välttämättä kovin merkittävinä panostuksen kannalta. SEO-riskiä ei osata ennakoida, , koska pinnalta katsottuna mikään merkittävä ei muutu sivuston sisällä.
Hakukonebotit näkevät tilanteen rakennemuutoksena, joka vaikuttaa siis siihen miten sivuja arvotetaan. Tämän ymmärtäminen vaatii laajempaa ymmärrystä myös teknisestä SEOsta.
- Osoiterakenteet ja reititykset
- Kirjainkoot URL-osoitteissa (Case Sensitivity): Palvelin- tai teknologiavaihto muuttaa osoitteet muodosta /Tuotteet muotoon /tuotteet.
- Ääkköselliset osoitteet: Vaikka selaimet pystyvät tulkitsemaan ASCII-koodattuja osoitteita, niistä muodostuu aina ongelmia ristiriitaisten signaalien muodossa.
- Viivat osoitteissa: Välilyöntirakenteiden muutokset eli – ja _-merkin käyttöjen ristiriitaisuus
- Sivutustavan muutokset (Pagination): Kategoriasivujen sivutus siirretään muodosta ?page=2 muotoon /sivu-2/ tai toteutetaan Infinite Scroll -ratkaisulla ilman toimivaa sivulatausta.
- Kuvien ja kuva-CDN:n siirto: Kuvien tallennuspaikan siirtäminen (esim. uuden CDN-palvelun taakse) muuttaa kuvien URL-osoitteet.
- Frontend- ja renderöintitason muutokset
- Teeman vaihto ja ylimääräinen koodi: Vaikka osoitteet säilyvät, uusi frontend-koodi saattaa poistaa HTML-koodista H1-H6-otsikkohierarkian, rikkoa strukturoidun datan (Schema.org) tai romahduttaa sivuston performoinnin (Core Web Vitals).
- Canonical-tägien rikkoutuminen: Koodipäivityksen myötä sivun <link rel=”canonical”> -osoitteet alkavat osoittaa vääriin osoitteisiin tai muodostavat canonical-silmukoita (canonical loops).
- Infrastruktuuri ja suojaus
- Protokollan pirstoutuminen: HTTPS-siirtymässä unohdetaan säätää pakotettu 301-ohjaus HTTP-versiosta HTTPS-versioon. Hakukoneelle syntyy kaksi toisiaan syövää rinnakkaissivustoa.
- Liian tiukka palomuuri tai CDN-suojaus: Esim. Cloudflare-asetukset säädetään niin tiukalle, että hakukonebotit joutuvat reitillä CAPTCHA-tarkistukseen (”Bot Challenge”). Hakukone luovuttaa sivuston lukemisen ja poistaa sivut indeksistä.
- Evästebannerin tai maksumuurin koodivirhe: Uusi Cookie Consent -ikkuna tai maksumuuri blokkaa koko sivun HTML-sisällön latautumisen ennen käyttäjän klikkausta, jolloin hakukone tulkitsee sivun sisällön kadonneen.
- Massapoistot ilman ohjausta (E-commerce): Sesongin vaihtuessa tuotanto poistaa tuhansia loppuneita tuotesivuja antaen niille suoraan 404 Not Found -koodin sijaan, että ne ohjattaisiin vastaavaan korvaavaan tuotteeseen tai yläkategoriaan.
Esimerkki kenoviivallisista osoitteista:
Samat osoitteet (juurisivusto)
https://example.com=https://example.com/https://www.yritys.fi=https://www.yritys.fi/
Eri osoitteet (alasivut ja polut)
https://example.com/palvelut≠https://example.com/palvelut/https://yritys.fi/blogi/seo-opas≠https://yritys.fi/blogi/seo-opas/https://kauppa.fi/kengat/tennarit≠https://kauppa.fi/kengat/tennarit/
Tiedostot (vinoviiva on aina virhe)
example.com/hinnasto.pdf→ oikea.example.com/hinnasto.pdf/→ 404-virheexample.com/kuva.jpg→ oikea.example.com/kuva.jpg/→ ei indeksoiduexample.com/index.html→ oikea.example.com/index.html/→ rikkoo reitityksen
Suhteelliset linkit
- Sivulla
/blogi/seo(ilman /): linkkiopas.htmlvie osoitteeseen/blogi/opas.html - Sivulla
/blogi/seo/(vinoviivalla): linkkiopas.htmlvie osoitteeseen/blogi/seo/opas.html
Esimerkki URL-muoto + uudelleenohjausketju
Suurimmat SEO-riskit: liikenteen romahdus vs. hallittu siirtymä
Hakukoneet, kuten Google, arvioivat sivuston luotettavuutta ja hyödyllisyyttä vuosien kuluessa kertyneen datan perusteella. Tämä data koostuu sivujen URL-osoitteista, sisäisistä ja ulkoisista linkeistä (backlinks), käyttäjien käyttäytymisestä sekä sisällön relevanssista.
Kun sivustoa muutetaan ilman järjestelmällistä SEO-strategiaa, tämä hakukoneiden rakentama muistijälki pyyhkiytyy pois.
Pahimmassa skenaariossa huonosti toteutettu migraatio katkaisee sivuston historiallisen linkkiarvon, jättää jälkeensä tuhansia toimimattomia sivuja (404-virheet) ja estää hakukonebotteja indeksoimasta uutta
sisältöä. Tämän seurauksena orgaaninen näkyvyys ja hakukoneliikenne voivat romahtaa 50–90 % hyvin nopeasti ja liikenteen palauttaminen entiselle tasolleen voi viedä kuukausia.
Hallitussa siirtymässä SEO-asiantuntija toimii tulkkina ja sillanrakentajana vanhan ja uuden sivuston välillä. Kun jokaiselle vanhalle sivulle määritetään täsmällinen 301-uudelleenohjaus, tekniset esteet minimoidaan ja uusi rakenne optimoidaan vastaamaan nykyistä hakukysyntää, liikenteen menetys jää väliaikaiseksi tai parhaassa tapauksessa migraatiosta muodostuu nopeakin kasvusykäys. Uuden julkaisun yhteydessä on myös elintärkeää hyödyntää muiden kanavien nopeutta verkkosivuston näkyvyyden tukena. Migraatiovalmis sivusto tarvitsee boostia myös mainonnalla.
Milloin SEO-asiantuntija pitää ottaa mukaan hankkeeseen?
Vastaus tähän on yksiselitteinen: ensimmäisessä ideointipalaverissa.
Tavallisin virhe organisaatioissa on kutsua SEO-asiantuntija paikalle viikkoa ennen uuden sivuston julkaisua pyytämään “SEO-tarkistusta”. Tässä vaiheessa kriittisimmät arkkitehtuuripäätökset, URL-rakenteet, tekniset alustavalinnat (kuten JavaScript-framework) ja kategoriarakenteet on jo lukittu koodiin. Pienten korjausten tekeminen myöhäisessä vaiheessa on kallista, monimutkaista ja usein riittämätöntä.
SEO-osaajan rooli hankkeen eri vaiheissa:
- Konseptointivaiheessa: varmistaa, että valittu alusta ja teknologia tukevat indeksoitavuutta ja suorituskykyä.
- Suunnitteluvaiheessa: määrittelee sivustoarkkitehtuurin, kategoriapuut ja URL-mallit vastaamaan todellista avainsana- ja hakukäyttäytymistä.
- Kehitysvaiheessa: auditoi staging-ympäristön ja laatii 301-uudelleenohjauskartan.
- Lanseerauksessa ja sen jälkeen: johtaa teknistä siirtopäivää ja monitoroi indeksoinnin palautumista.
Miten migraatioprojekti etenee
Lähtötilanteen kartoitus. (Baseline)
Ennen kuin muutokset aloitetaan, nykytilasta on luotava vertailupohja (baseline). Ilman mittareita migraation onnistumista tai mahdollisten virheiden syitä on mahdotonta analysoida.
Tärkeimmät kerättävät tiedot:
Ranking- ja avainsanadata:
- Tallenna vähintään 3–6 kuukauden historia.
- Vie Google Search Consolesta (GSC) kaikki indeksoidut URL-osoitteet ja niiden sijainnit.
- Vie SEO-työkalusta (esim. Semrush tai Ahrefs) lista tärkeimmistä avainsanoista (300+) ja niiden sijoituksista.
Liikenne ja konversiot:
- Aja Google Analyticsista orgaanisen liikenteen (organic traffic) raportti 6 kuukaudelta sivukohtaisesti ja kategorioittain.
- Dokumentoi orgaanisesta hakuliikenteestä syntyvät konversiot (ostot, liidilomakkeet).
Tekniset mittarit:
- Crawlability & Indeksointi: Dokumentoi nykyiset robots.txt-säännöt, XML-sivustokartta (sitemap.xml) sekä noindex-tägit.
- Rendering: Tarkista GSC:n URL Inspection -työkalulla, miten hakukoneet näkevät JavaScript-sisällön.
SEO-migraatioprosessi vaihe vaiheelta
Onnistunut migraatio noudattaa nelivaiheista prosessia suunnittelusta aina siirron jälkeiseen seurantaan.
Vaihe 1: suunnittelu ja nykytilan kartoitus (pre-migration)
- Nykyisen sivuston SEO-auditointi ja kaikkien URL-osoitteiden indeksointi (crawling).
- Tärkeimpien sivujen ja avainsanojen arvottaminen (GA4, Search Console, Ahrefs/Semrush).
- Auktoriteettilinkkien (backlinks) kartoitus ja säilytyssuunnitelma.
- 301-uudelleenohjauskartan (redirect map) rakentaminen.
Vaihe 2: kehitys- ja testiympäristö (staging)
- Testiympäristön hakukonesuojaus (noindex vs. IP-pääsynrajoitus).
- Uuden sivuston tekninen auditointi ja Core Web Vitals -latausnopeustestaus.
- Structured data -merkintöjen, meta-tietojen ja robots.txt-tiedoston varmistus.
Vaihe 3: H-hetki eli siirtopäivä (launch day)
- Siirron ajoitus ja tekninen muistilista siirtopäivälle.
- Uudelleenohjausten (301) ja SSL-sertifikaattien live-testaus.
- Google Search Consolen asetukset
Vaihe 4: seuranta ja optimointi (post-migration)
- Ensimmäisten 48 tunnin hälytyslistat ja crawl-virheiden korjaus (404, 500).
- Hakukonebotti-sivustovierailujen (crawl budget) seuranta palvelinlokeista ja GSC:stä.
- Sijoitusten ja orgaanisen liikenteen palautumisen seuranta (1–3 kuukautta).
H-hetki: siirtopäivän kriittinen muistilista
Siirtopäivän perussääntö on yksinkertainen: mitään ei siirretä tuotantoon perjantaina tai ennen viikonloppua. Optimaalinen ajankohta on alkuviikosta (tiistai–keskiviikko) varhain aamulla tai hiljaisen liikenteen aikana.
Ennen siirtoa: valmistelu ja lukitus
Suoritetaan 1–2 tuntia ennen siirron aloitusta.
- Jäädytä sisältö (content freeze): varmista, ettei vanhaan CMS-järjestelmään tehdä enää uusia artikkeleita, tuotemuutoksia tai sivupäivityksiä.
- Ota varmuuskopio (backup): aja täydellinen varmuuskopio vanhan sivuston tietokannasta, koodipohjasta ja .htaccess- tai Nginx-konfiguraatioista.
- Pudota DNS TTL -arvoa: laske DNS-tietueiden TTL-arvo (time to live) esimerkiksi 300 sekuntiin (5 min) vähintään 24–48 tuntia ennen siirtoa, jotta uusi IP-osoite päivittyy maailmanlaajuisesti nopeasti.
Siirto: tekniset estot pois ja ohjaukset päälle
Kriittisin 15-minuuttinen.
- Poista testisivuston estot: poista koodipohjasta noindex-tägit, HTTP Basic Authentication -salasanasuojaus ja robots.txt-tiedoston Disallow: / -kiellot, jotka kuuluivat kehitysympäristöön.
- Aktivoi 301-uudelleenohjaukset: aja 301-uudelleenohjauskartta (redirect map) tuotantopalvelimelle tai CDN-tasolle (esim. Cloudflare).
- Päivitä DNS-tietueet: osoita domain osoittamaan uuden palvelimen IP-osoitteeseen.
Välitön auditointi siirron jälkeen
Suoritetaan välittömästi, kun DNS-muutos on voimassa.
- Testaa robots.txt ja SSL: varmista selaimella, että domain.fi/robots.txt ei estä hakukonebotteja ja että HTTPS-sertifikaatti toimii ilman turvallisuusvaroituksia.
- Aja otostestaus 301-ohjauksille: testaa tärkeimmät vanhat URL-osoitteet (top 20 suosituinta sivua ja eniten backlinkkejä saaneet sivut). Varmista, että ne ohjaavat 301-koodilla suoraan uuteen vastaavaan osoitteeseen – ei 302-ohjauksia eikä ohjausketjuja (redirect chains).
- Tarkista canonical-tägit: varmista lähdekoodista, että <link rel=”canonical”> osoittaa uuden sivuston täydellisiin HTTPS-osoitteisiin, ei staging-domainille.
- Tee crawl livesivustolle: käynnistä käyttämäsi crawler (esim. Screaming Frog) ja aja uusi sivusto läpi. Etsi koodista 404-virheitä, rikkoutuneita sisäisiä linkkejä tai vahingossa jääneitä noindex-merkintöjä.
Hakukoneiden tiedotus ja indeksointipyynnöt
Suoritetaan heti, kun tekninen toimivuus on varmistettu.
- Lähetä uudet XML-sivustokartat (sitemaps): lähetä uuden sivuston XML-sivustokartta Google Search Consoleen (GSC) ja Bing Webmaster Toolsiin.
- Pyydä uudelleenindeksointia (Request Indexing): syötä vanhan ja uuden sivuston etusivut sekä 5–10 kriittisintä kategoria- tai tuotesivua Search Consolen URL Inspection -työkaluun ja pyydä niille indeksointia.
Seuranta ja analytiikka
Siirtopäivän iltapäivä ja ensimmäiset tunnit.
- Varmista seurantakoodit: tarkista reaaliaikaisesta analytiikasta (GA4), että sivustoliikenne tallentuu ja että Tag Manager -skriptit suorittavat tapahtumat oikein.
- Tarkista konversioputket: tee koetilaus tai lähetä testilomake varmistaaksesi, että liiketoiminnallisesti kriittiset toiminnot toimivat.
- Seuraa palvelinlokeja (server logs): seuraa, alkavatko hakukonebotit käydä uudella sivustolla ja lukevatko ne 301-ohjauksia toivotulla tavalla.
3. Seitsemän tyypillistä verkkosivumigraation sudenkuoppaa
Nämä ovat ongelmia, joita nähdään sivustouudistuksissa ja migraatioissa kerta toisensa jälkeen. Jokainen niistä voi aiheuttaa merkittävän hakukonenäkyvyyden ja liikenteen romahduksen, jos niiden toimintamekanismia ei ymmärretä.
Domain-vaihto ilman 301-uudelleenohjauksia
Mitä on tapahtunut?
Yritys päättää vaihtaa domain-osoitettaan (esim. vanha-verkkokauppa.fi → uusi-verkkokauppa.fi). Migraatio toteutetaan ja uusi sivusto avataan. Tavoitteena oli tehdä 301-uudelleenohjaukset vanhoista osoitteista uusiin, mutta ne unohtuivat – tai ne päätettiin "kiireen vuoksi tehdä myöhemmin".
Tämä on yksi vaarallisimmista migraatiovirheistä. Vanha domain jätetään tyhjän päälle: se näyttää 404-virhesivuja tai on kokonaan poissa käytöstä. Uudelle sivustolle ei ohjaudu liikennettä mistään ulkopuolisista linkeistä, joita vanhaan domainiin oli vuosien varrella kertynyt.
Syy: Puutteellinen suunnittelu
Domain-vaihtoa pidetään usein helpompana kuin se todellisuudessa on. Suunnittelu saattaa olla todella vajaavaista, minkä jälkeen kehittäjä toteuttaa siirron ajattelematta SEO-vaiktuuksia. Prosessista puuttuu SEO-osaaminen, eikä kukaan ymmärrä ohjausten kriittisyyttä.
Lisäksi osoitteenmuutos tehdään harvoin yksinään. Samalla muutetaan usein sivuston rakennetta, luokitteluja ja koodipohjaa. Näiden muiden muutosten tiimellyksessä uudelleenohjausten suunnittelu unohtuu helposti.
Miten tämä olisi voitu välttää?
Domain-vaihto vaatii aina kaksiportaisen uudelleenohjaussuunnitelman:
-
Domain-tason ohjaus (Domain-level redirect): Kaikki vanhan domainin osoitteet ohjataan uuteen osoitteeseen 301-määritteellä (pysyvä ohjaus) DNS- tai palvelintasolla ennen kuin vanha domain suljetaan:
http://vanha-domain.fi -> https://uusi-domain.fi https://vanha-domain.fi -> https://uusi-domain.fi -
Sivutason ohjaus (Page-level redirect): Jos sivurakenne muuttuu, jokaiselle vanhalle sivulle määritetään vastaava uusi osoite (esim.
/tuotteet/kengat.html→/tuotteet/nilkkakengat/nike/).
Lisäksi Google Search Consolessa tulee luoda uudelle domainille oma omaisuus (property) ja lähettää sen sivustokartta (sitemap).
Redirect-ketjujen syntyminen
Mitä on tapahtunut?
Migraation jälkeen huomataan, etteivät tietyt ohjaukset toimi oikein. Esimerkiksi vanhan kategorian /kengat/ pitäisi ohjata osoitteeseen /tuotteet/nilkkakengat/.
Prosessin korjaamiseksi tehdään hätäratkaisuja: kehittäjä lisää väliaikaisen ohjauksen. Myöhemmin toinen kehittäjä tekee toisen korjauksen. Muutaman viikon kuluttua sivustolle on rakentunut monivaiheinen ketju:
Syy: Improvisointi ja puutteellinen testaus
Ketjuja syntyy, kun uudelleenohjauksia ei ole suunniteltu etukäteen ja virheitä korjataan sitä mukaa ad hoc -tyylillä. Taustalla on myös puutteellinen testaus testausympäristössä (staging). Jos ohjaukset olisi testattu ennen julkaisua, ketjut olisi havaittu ajoissa.
Miten tämä olisi voitu välttää?
- Suora mäppäys: Jokainen vanha URL ohjataan suunnitteluvaiheessa suoraan lopulliseen uuteen osoitteeseen ilman väliasemia.
- Automaattinen testaus: Testataan ohjaukset staging-ympäristössä
curl-komennolla:
Jos vastauksessa näkyy useampiacurl -I https://vanha-osoite.fi/kengat/ -L301-tilakoodeja peräkkäin, ketju on korjattava. - Aktiivinen seuranta: Julkaisun jälkeen Search Consolen Coverage-raportteja tulee seurata tiiviisti ensimmäisten viikkojen aikana.
Canonical-tagien virheet
Mitä on tapahtunut?
Kanoninen tagi (rel="canonical") kertoo hakukoneelle, mikä sivu on sisällön ensisijainen "pääversio". Normaalisti minimissään jokaisen sivun canonical-tagin tulisi osoittaa sivuun itseensä (self-referencing canonical).
Migraatiossa tämä tagi saattaa kuitenkin jäädä kokonaan pois tai osoittaa vääriin osoitteisiin:
- Uuden sivuston canonical-tagit osoittavat edelleen vanhaan domainiin.
- Kaikkien sivujen canonical-tagit osoittavat virheellisesti sivuston etusivulle.
- Sivujen canonical-tagit osoittavat virheellisesti staging-sivustoon.
- Canonical-tagit puuttuvat kokonaan, jolloin Google saattaa valita väärän sivun hakutuloksiin tuplasisällön vuoksi.
Syy: Koodin kopiointi ja väärinymmärrykset
Virheet johtuvat usein siitä, että koodipohjat kopioitiin vanhalta sivustolta sellaisenaan ilman domain-osoitteiden päivitystä. Canonical-tageja ei myöskään usein tarkisteta manuaalisesti, koska ne näkyvät vain sivun lähdekoodissa.
Miten tämä olisi voitu välttää?
Varmistetaan, että jokainen sivu osoittaa omaan, lopulliseen osoitteeseensa:
<link rel="canonical" href="https://uusi-domain.fi/tuotteet/kengat/">Aja sivusto läpi hakukonebotteja simuloivalla työkalulla (kuten Screaming Frog) ennen julkaisua. Kieliversioissa varmistetaan oikea hreflang- ja canonical-yhdistelmä.
Robots.txt-tiedosto estää migratoituja sivuja
Mitä on tapahtunut?
robots.txt on tiedosto, joka antaa hakukoneboteille ohjeet siitä, mitä osia sivustosta ne saavat käydä läpi. Migraatiossa tämä tiedosto unohdetaan usein päivittää, tai siihen jätetään vanhoja tai kehitysympäristön (staging) estoja.
# Pahin skenaario: Koko sivusto estetty
User-agent: *
Disallow: /
Hienovaraisempi virhe tapahtuu, kun vanhan sivuston Disallow: /kassa -sääntö estää uudella sivustolla vahingossa myös tärkeän tuotekategorian /kassa-ja-laukut/.
Syy: Huolimattomuus ja testauksen puute
Kehitysvaiheessa hakukoneet estetään kokonaan. Kun sivusto julkaistaan, tämä Disallow: / -sääntö unohdetaan valitettavan usein poistaa. Toinen syy on vanhan tiedoston suora kopiointi ilman suhteuttamista uuteen rakenteeseen.
Miten tämä olisi voitu välttää?
Luo robots.txt uudelta pohjalta ja testaa se tarkasti:
User-agent: *
Disallow: /admin/
Disallow: /checkout/
Allow: /
Sitemap: https://domain.fi/sitemap.xmlSivustokartta (Sitemap) sisältää vanhoja tai rikkinäisiä osoitteita
Mitä on tapahtunut?
XML-sivustokartta (Sitemap) on hakukoneille suunnattu hakemisto sivuston tärkeimmistä sivuista. Migraation jälkeen sitemap saattaa sisältää sekaisin vanhoja ja uusia osoitteita, poistettuja sivuja (404) tai uudelleenohjattavia osoitteita (301).
Syy: Automaation sokea luottamus
Sivustokartta luodaan usein automaattisesti tietokannasta. Migraatiossa se saattaa kuitenkin jäädä päivittämättä tai se ottaa mukaan vanhoja poistettuja tuotteita. Tiedostoa ei myöskään tarkisteta manuaalisesti ennen sen lähettämistä hakukoneelle.
Miten tämä olisi voitu välttää?
Validoi sitemap testausympäristössä ja varmista että se täyttää seuraavat ehdot:
- Sisältää vain sivut, jotka halutaan hakutuloksiin (200 OK -tilakoodi).
- Ei sisällä 404-virhesivuja, 301-ohjauksia tai
noindex-tagilla merkittyjä sivuja. - Sisältää ajantasaiset
<lastmod>-päivämäärätiedot.
Hreflang-virheet kieliversioissa
Mitä on tapahtunut?
hreflang-tagit kertovat hakukoneelle sivuston eri kieliversioista, jotta Google osaa näyttää käyttäjälle oikeankielisen sivun. Migraatiossa nämä merkinnät menevät usein ristiin tai rikki:
- Sama osoite määritelty virheellisesti eri kielille.
- Yksisuuntaiset viittaukset (paluuviite toisesta kieliversiosta puuttuu).
- Puuttuva oletuskieli (
hreflang="x-default").
Syy: Teknisesti monimutkainen kokonaisuus
hreflang-logiikka on poikkeuksellisen herkkä inhimillisille virheille. Kehittäjät toteuttavat koodin usein ilman SEO-asiantuntijan katselmointia, eikä kieliversioiden keskinäisiä viittauksia muisteta testata kattavasti.
Miten tämä olisi voitu välttää?
Jokaiselta erikieliseltä sivulta on oltava täydellinen lista kaikkien kieliversioiden osoitteista – mukaan lukien viittaus sivuun itseensä:
<!-- Suomenkielinen sivu -->
<link rel="alternate" hreflang="fi" href="https://domain.fi/tuotteet/kengat/">
<link rel="alternate" hreflang="en" href="https://domain.fi/en/products/shoes/">
<link rel="alternate" hreflang="x-default" href="https://domain.fi/">Jäsennellyn datan (Schema markup) rikkoutuminen
Mitä on tapahtunut?
Jäsennelty data (Schema markup) auttaa Googlea ymmärtämään sivun tyypin ja sisällön. Verkkokaupassa se kertoo hakukoneelle suoraan tuotteen hinnan, saatavuuden, arvostelutähdet ja tuotekuvat.
Migraatiossa tämä koodi usein särkyy, esimerkiksi kuva- tai tuoteosoitteet jäävät osoittamaan vanhaan domainiin tai JSON-LD-koodissa on syntaksivirhe:
{
"@type": "Product",
"name": "Nike Air Max",
"image": "https://vanha-domain.fi/images/nike.jpg",
"offers": {
"price": "129.99"
}
}Syy: Koodin unohdus ja puutteellinen validointi
Schema-tietoja pidetään usein toissijaisena asiana, eikä niitä muisteta päivittää, kun sivuston koodipohjaa ja URL-rakenteita uudistetaan. Pienet syntaksivirheet jäävät helposto huomaamatta ilman erillistä koodin validointia.
Miten tämä olisi voitu välttää?
- Päivitä osoitteet: Varmista, että Schema-koodissa olevat kuva-, tuote- ja organisaatio-osoitteet viittaavat uuteen domainiin.
- Käytä testaustyökaluja: Testaa jokainen sivutyyppi Googlen Rich Results Test -työkalulla ja Schema Validatorilla ennen sivuston julkaisua.
Miksi SEO-ymmärrys on tärkeää
Tekninen migraatio on kehittäjä-tehtävä. Mutta SEO-migraatio on jotain muuta. Se vaatii ymmärrystä siitä, miten hakukoneet näkevät sivuston ja miten muutokset vaikuttavat hakukoneiden käyttäytymiseen.
Kehittäjä ja SEO-asiantuntija näkevät migraation täysin eri tavalla. Kehittäjä miettii: sivusto on nopea, koodi on puhdas, arkkitehtuuri on moderni. SEO-asiantuntija miettii: mitä tapahtuu ranking-signaaleille, mitä tapahtuu backlink-profiilille, mitä tapahtuu indeksoinnille.
Monet yritykset tekevät migraatioita ilman SEO-osaamista. Ja lähes kaikissa näistä tapauksista näkyvyys putoaa merkittävästi.
SSR → CSR muutos: Tekniikka vs. haku
Esimerkki:
Yritys toteuttaa migraation server-side renderingistä (SSR) client-side renderingiin (CSR). Käyttökokemuksen näkökulmasta tämä on oikea päätös. CSR-sovellus on interaktiivinen ja nopea käyttäjälle.
Mutta Googlelle CSR on ongelma kuten Javascript-pohjaiset ratkaisut yleensäkin. Googlebot joutuu lataamaan JavaScriptin erillisen prosessin kautta, suorittamaan sen, ja odottamaan että sisältö renderöityy. Tämä on hitaampaa kuin SSR jossa sisältö on jo valmiina HTML:ssä.
Jos yritys ei ole valinnut CSR:ää tietoisesti (eli tietäen SEO-haitat), vaan koska yleinen uskomus on se, että Google ja muut hakukoneet ymmärtävät JS:ää, migraatio vaurioittaa SEO:ta.
Parempi vaihtoehto olisi SSG (Static Site Generation) tai ISR (Incremental Static Regeneration). Nämä ovat nopeita kuten CSR, mutta SEO-ystävällisempiä kuten SSR. Vaikka esim. Google pystyykin ymmärtämään Javascriptiä nykyään jopa suhteellisen hyvin, on se hidasta. Jos verkkosivuston toimivuus hakukoneille on bisneskriittistä, Googlelle ei kannata jättää mitään tulkinnanvaraisuuksia.
Migraation johtaminen ilman SEO-osaamista
Migraatioita johtaa usein projektipäällikkö tai tekninen johtaja, jolla ei ole SEO-osaamista. Hän näkee migraation aikataulun, budjetin, tekniset vaatimukset ja lopputuloksen, mutta hän ei näe SEO-riskejä.
Projekti nähdään suoraviivaisena ja nopeana toimenpiteenä ilman sen tarkempaa kontrollia ja taas SEO:n aikataulutus nähdään liian pitkänä joten siitä leikataan pois. Post-launch seuranta vähenee 1 viikkoon. Staging-testaus vähenee kahdesta päivästä yhteen. Suunnittelu vähenee viikosta 3 päivään.
Mutta migraatio ei ole lineaarinen. Jos jätät suunnittelun lyhyemmäksi, riskit kasvavat eksponentiaalisesti. Redirect-mäppäys voi olla 70-80 prosenttia suunnittelusta. Jos suunnittelu kestää vain 3 päivää, redirect-mäppäys on puutteellinen.
Kun migraatio menee vikaan: Epäonnistuneen migraation Recovery-projekti
Sivustomigraation epäonnistuminen ja sitä seuraava hakukonenäkyvyyden sekä liikenteen romahtaminen on jokaisen liiketoimintapäällikön painajainen. Kun asiat menevät vikaan, korjausprojekti (Recovery-projekti) on huomattavasti pidempi, monimutkaisempi ja kalliimpi prosessi kuin huolellisesti suunniteltu alkuperäinen migraatio.
Miksi Recovery-projekti kestää 8–12 viikkoa?
Recovery-projekti ei ole vain nopea ”ohjelmistopäivitys”, vaan siinä joudutaan purkamaan ja rakentamaan uudelleen virheellisesti tehtyjä rakenteita samalla, kun taistellaan hakukoneiden luottamuksen palauttamisesta.
Recovery-projekti jakautuu kuuteen kriittiseen vaiheeseen:
Diagnoosi (Mitä meni pieleen?): Perusteellinen SEO- ja tekninen auditointi. Selvitetään, ovatko taustalla kadonneet 301-ohjaukset, rikkinäinen Canonical-rakenne, muuttuneet URL-osoitteet, indeksointiestot, sisällön poistaminen vai kooditason tekniset virheet.
Priorisoinnin (Mikä korjataan ensin ja mitä suunniteltuja kehitystoimenpiteitä keskekytetään): Ongelmien luokittelu niiden liiketoiminnallisen vaikuttavuuden mukaan. Ensin korjataan kriittiset esteet (kuten indeksointiongelmat ja ohjausketjut), jotta hakukoneet pääsevät taas käsiksi oikeaan sisältöön.
Korjaus (Tekninen ja sisällöllinen toteutus): Kaikkien tunnistettujen virheiden korjaaminen sivuston taustajärjestelmässä, rakenteessa ja sisällöissä.
Validointi (Staging-testaus): Korjausten huolellinen testaus staging-ympäristössä ennen julkaisua. Tällä varmistetaan, ettei korjaus aiheuta uusia sivuoireita.
Uudelleenjulkaisu (Launch): Korjattujen rakenteiden ja ohjausten ajaminen tuotantoon hallitusti.
Pidennetty seuranta (8 viikkoa): Epäonnistuneen migraation jälkeen normaali 4 viikon seuranta ei riitä. Hakukoneet tarvitsevat aikaa re-indeksoida sivusto ja arvioida muutokset uudelleen. 8 viikon tiivis seuranta takaa, että hakukoneet reagoivat korjauksiin halutulla tavalla.
Recovery-projektin karut tosiasiat: Hinta ja epävarmuus
Recovery-projektin realistinen läpimenoaika on 8–12 viikkoa, ja sen suorat kustannukset ovat usein suuremmat kuin alkuperäisen migraation. Tämä johtuu siitä, että virheiden etsiminen ja solmujen avaaminen jälkikäteen vaatii huomattavasti enemmän asiantuntijatyötä kuin oikeaoppisen rakenteen luominen alusta alkaen.
Kustannusten lisäksi suurin riski on aikajänne ja epävarmuus:
Tulosten viive: Vaikka itse Recovery-projekti saadaan valmiiksi 8–12 viikossa, hakukonenäkyvyyden ja orgaanisen liikenteen palautuminen voi kestää 3–4 kuukautta korjausten julkaisusta.
Ei 100 % takuuta: Hakukoneiden algoritmit eivät aina palauta näkyvyyttä ennalleen välittömästi, vaikka kaikki virheet olisi korjattu. Menetetty luottamus vaatii aikaa.
Vertailu: oikein tehty migraatio vs. recovery-projekti
MIGRAATIO ON LIIKETOIMINTAHANKE
Migraatio näyttää puhtaasti tekniseltä projektilta. Mutta se on liiketoiminnan kannalta kriittinen hanke, joka voi vaurioittaa tai parantaa yrityksen näkyvyyttä ja liikennettä merkittävästi.
Menestyneet migraatiot noudattavat kolmea periaatetta:
Ensimmäinen on SEO-osaaminen mukaan alusta lähtien.
Ei jälkikäteen ”oikaista” vaan etukäteen ”suunnitella oikein”. SEO-asiantuntija on osana migraatiosuunnittelua, valitsee rendering-tekniikan, valvoo redirect-mäppäystä, testaa staging-ympäristöä.
Toinen on perusteellinen staging-testaus.
Kaikki kriittiset asiat (redirectit, canonical, robots.txt, sitemap, hreflang, schema) testataan ennen launchta. Jos staging-testaus osoittaa ongelmia, ne korjataan. Launch tehdään vasta kun staging osoittaa että kaikki on kunnossa.
Kolmas on aktiivinen post-launch seuranta.
Ensimmäisen viikon aikana seurataan aktiivisesti liikennettä, indeksointia, ranking-muutoksia. Jos ongelma ilmenee, se korjataan heti. Viikon jälkeen seuranta jatkuu, mutta vähemmän intensiivisesti.
Näitä kolmea periaatetta noudattamalla migraatioiden onnistumisprosentti on merkittävästi korkeampi. Migraatioiden yhteydessä tapahtuu lähes poikkeuksetta alkuun pudotuksia sijoituksissa sekä liikenteen määrässä. Hyvin suunnitellulla migraatiolla, jossa SEO on alusta asti mukana, pystytään lyhentämään sitä aikaväliä, jonka sivusto on näkyvyydeltään heikentyneessä tilanteessa ja nostamaan sivusto uuteen nousukiitoon.
Migraatiot, joissa näitä periaatteita ei noudateta, vaurioittavat lähes aina näkyvyyttä huomattavasti pidemmällä aikavälillä. Näkyvyyden palautuminen kestää kuukausia, on epävarmaa ja tarkoittaa kasvavia kustannuksia, joita voisi käyttää esim. mainontaan.
Olen Niko Anttila, SEO-konsultti ja Abonomadin perustaja. Autan B2B-yrityksiä, verkkokauppoja ja mediatoimistoja kasvattamaan myyntiä ja liidejä orgaanisen haun kautta – ilman turhaa jargonia.
Syväosaamiseni on vaativassa teknisessä SEO:ssa, SEO-strategioissa ja liiketoimintaymmärryksessä. Erityisesti JavaScript-sivustot (React, Next.js, Vue), suuret verkkokaupat ja mutkikkaat sivustomigraatiot ovat kenttä, jossa olen parhaillani. En keskity pelkkiin kävijämääriin tai hienoihin graafeihin, vaan siihen mikä ratkaisee:
Orgaaninen näkyvyys tuo yrityksellesi aitoa kaupallista arvoa ja viivan alle jäävää tulosta.
Abonomad on yhden hengen asiantuntijatoimisto. Kun teet yhteistyötä kanssani, saat aina suoran yhteyden senior-tason tekijään – ilman välikäsiä, projektipäälliköitä tai junior-konsultteja. Varmistan, että sivustosi koodi, rakenne ja kaupalliset tavoitteet kohtaavat saumattomasti alusta alkaen.
Kirjoitan SEO- ja digitaalisen liiketoiminnan aiheista sivustolleni sekä jaan ajatuksiani LinkedInissä. Laita rohkeasti verkostoitumispyyntöä.
Kaipaatko kokenutta SEO-kumppania?
Ota yhteyttä →