WordPress Multisite -siirto: täydellinen käsikirja 2026

Olette luultavasti juuri nyt toisessa kahdesta tilanteesta. Joko multisite-verkosto on kasvanut ulos palvelimesta, hallintamallista tai URL-rakenteesta, joilla se aloitettiin, tai joku liiketoiminnan puolelta on päättänyt, että yhdestä alisivustosta pitää tulla oma alustansa rikkomatta näkyvyyttä hakukoneissa, toimituksen työnkulkuja tai liikevaihtoa.

Juuri tässä WordPress Multisite -siirto lakkaa olemasta rutiininomainen hosting-tehtävä ja muuttuu kehitysprojektiksi. Tekninen siirto on tärkeä, mutta suuremmat riskit ovat yleensä muualla: lisäosan lisenssi, joka ei enää validoidu irrotuksen jälkeen, monikielinen kokoonpano, joka menettää canonical-tagit, mediakirjasto, joka näyttää kunnossa olevalta, kunnes toimitus löytää rikkinäisiä tiedostoja kolme päivää myöhemmin, tai palautussuunnitelma, joka on olemassa vain epämääräisenä lupauksena.

Siisteimmät näkemäni siirrot noudattavat kaikki samaa kaavaa. Niissä tietokannan siirtoa käsitellään yhtenä osana laajempaa, hallittua muutosta. Laajuus lukitaan aikaisin, testataan kuin tutkijat ja oletetaan, että jokin pettää, ellei sitä ole varmistettu. Tämä ajattelutapa estää multisite-siirtoa muuttumasta myöhäisillan häiriötilanteeksi.

Siirtoa edeltävä strategia ja riskiarviointi

Perjantai, klo 20.40. DNS on vaihtumassa, tietokannan tuonti on valmis, ja joku kysyy, säilyivätkö ranskankielisen alisivuston hreflang-tagit ja mitkä maksullisten lisäosien lisenssit selviävät siirrosta. Jos tämä kysymys nousee esiin siirtoyönä, suunnittelu on epäonnistunut.

WordPress Multisite -siirto alkaa laajuuden hallinnasta ja vikojen ennakoinnista. Tietokanta ja tiedostot ovat tärkeitä, mutta korkean riskin projektit kaatuvat yleensä liiketoiminnan jatkuvuuteen liittyviin asioihin: vanhaan verkkotunnukseen tai asennustyyppiin sidottuihin lisäosien lisensseihin, monikielisen SEO:n sääntöihin, jotka katoavat irrotuksen jälkeen, ja palautussuunnitelmiin, jotka kuulostavat hyviltä, kunnes jonkun on paineen alla päätettävä, palautetaanko DNS.

Käsitelkää suunnitelmaa kuin häiriötilanteiden runbookia. Ennen kuin kukaan koskee tuotantoon, sen pitää vastata neljään asiaan:

1. Mitä tarkalleen siirretään
2. Minkä täytyy pysyä saatavilla
3. Mikä käynnistää palautuksen
4. Kenellä on valtuudet hyväksyä julkaisu tai perua se

Määrittäkää siirron laajuus ennen kuin valitsette työkalut

”Siirretään multisite” ei ole käyttökelpoinen laajuus. Käytännössä pyyntö on usein sotkuisempi: yksi liikevaihtoa tuottava alisivusto irrotetaan omaksi WordPressikseen, kaksi vanhaa alisivustoa jätetään pois, yhdistetyt verkkotunnukset säilytetään, toimitus pystyy työskentelemään maanantaiaamuna, eikä hakusijoituksia menetetä kolmella kielellä.

Kirjatkaa ensin inventaario.

• Jokainen alisivusto: nykyinen URL, yhdistetty verkkotunnus, liiketoiminnan vastuuhenkilö ja käyttökatkon sietokyky
• Aktivointimalli: verkostotasolla aktivoidut lisäosat verrattuna sivustotason lisäosiin
• Oma koodi: mu-plugins, drop-init, omat taulut, cron-ajot, webhookit ja teeman ohitukset
• Jaetut riippuvuudet: viittaukset mediaan, API-integraatiot, SSO, lomakkeet, haku ja analytiikkaskriptit

Jos kukaan ei pysty sanomaan, mitkä alisivustot saavat olla poissa käytöstä ja kuinka kauan, siirto ei ole valmis.

Tässä vaiheessa tiimit myös päättävät, tehdäänkö työ talon sisällä vai otetaanko mukaan WordPress-siirtopalveluihin erikoistunut asiantuntija. Vaihtokauppa on suoraviivainen. Sisäiset tiimit tuntevat teknologiapinon. Ulkoiset toimijat tuovat usein mukanaan siistimmän runbookin, paremman palautuskurin ja vähemmän oletuksia.

Auditoikaa vikakohdat, jotka satuttavat julkaisun jälkeen

Tietokannan vienti ja tuonti ovat helppo osa. Kalliit viat tulevat esiin myöhemmin, kun sivusto näyttää ”pääosin kunnossa olevalta”.

Lisäosien lisensointi on yleinen esimerkki. Maksulliset lisäosat voivat validoida lisenssin ensisijaisen verkkotunnuksen, verkostokontekstin, sivustojen määrän tai ympäristön perusteella. Multisitestä irrotettu alisivusto voi käynnistyä oikein ja silti menettää pääsyn päivityksiin, kenttien renderöintiin, käännösominaisuuksiin tai kassaintegraatioihin, koska lisenssi ei enää vastaa uutta asennusta. Tarkistakaa toimittajien ehdot ennen siirtoa, ei sen jälkeen.

Monikielinen SEO ansaitsee saman huomion. Jos verkosto käyttää WPML:ää, Polylangia, omaa hreflang-tulostusta, markkinakohtaisia canonical-tageja tai käännettyjä slugeja, dokumentoikaa nykyinen toiminta. Siihen kuuluvat title-tagit, canonical-tagit, hreflang-tagit, XML-sivukartat, uudelleenohjaussäännöt ja kieliversioihin perustuvat sivupohjat. Sivusto voi läpäistä visuaalisen laadunvarmistuksen ja silti menettää hakuarvoa, koska metatietokerros muuttui huomaamatta.

Media on toinen ansa. Multisitessä toimittajat liittävät usein tiedostojen URL-osoitteita alisivustolta toiselle, käyttävät mukautettuja kenttiä, jotka viittaavat vanhoihin latauspolkuihin, tai luottavat lisäosiin, jotka kirjoittavat median käsittelyn uudelleen. Rikkinäiset pikkukuvat ovat ärsyttäviä. Rikkinäiset dokumentit, kampanjamateriaalit ja lokalisoidut PDF-tiedostot synnyttävät tukipyyntöjä nopeasti.

Laatikaa riskiloki, jota voi oikeasti käyttää

Pitäkää se niin lyhyenä, että siirron vetäjä lukee sen käyttöönoton aikana.

Asettakaa objektiiviset palautuksen laukaisimet

Palautus ei saa riippua varmuuden tunteesta, mielialasta tai siitä, kuka puhuu puhelussa kovimmin. Asettakaa mitattavat laukaisimet ennen julkaisua.

Esimerkkejä:

• Pääsivustojen omistajien ylläpitäjäkirjautuminen ei toimi
• Kassa, liidilomakkeet tai kirjautumisprosessit epäonnistuvat
• Verkkotunnusten yhdistäminen ohjaa liikennettä väärälle alisivustolle
• Tuotantosivuilta puuttuu kriittisiä monikielisiä metatietoja
• Lisäosien lisensointi poistaa käytöstä tarvittavia toimintoja
• Virhemäärät kasvavat jyrkästi eikä niitä saada korjattua huoltoikkunan aikana

Kirjatkaa raja-arvo ylös ja hankkikaa sille hyväksyntä siirron vetäjältä, tuoteomistajalta ja DNS:ää hallitsevalta henkilöltä. Suosittelen myös kirjaamaan palautuksen tarkat komennot ja toimenpiteet, ei pelkkää päätössääntöä. Todellisissa häiriötilanteissa selkeys voittaa optimismin.

Jos palautukseen kuuluu esimerkiksi vanhan tietokannan palauttaminen ja DNS:n pakottaminen takaisin, kirjatkaa järjestys ylös:

# Example rollback checks
wp site list
wp plugin list --network
wp search-replace 'https://new.example.com' 'https://old.example.com' --network --dry-run

Käyttäkää suunnitteluvaiheessa koeajoja (dry run) varmistaaksenne, että tiimillä on ne käyttöoikeudet, jotka se uskoo olevan. Siirtoyönä puuttuvat WP-CLI-oikeudet tai väärä SSH-avain vievät juuri sen ajan, jota olisitte tarvinneet palautukseen.

Hyvät multisite-siirrot ovat hallittuja muutoksia. Tiimit, jotka selviävät niistä siististi, päättävät laajuudesta aikaisin, dokumentoivat piilossa olevat riippuvuudet, testaavat lisenssien ja SEO:n toiminnan ennen käyttöönottoa ja määrittelevät palautuksen ikään kuin aikoisivat käyttää sitä.

Ympäristöjen ja DNS:n valmistelu

Useimmat epäonnistuneet siirrot alkavat vanhan ja uuden ympäristön välisestä epäsuhdasta. Ei dramaattisesta epäsuhdasta. Hiljaisesta. Kohteesta puuttuva PHP-lisäosa, tiedostojärjestelmän käyttöoikeusongelma hakemistossa uploads, aukko uudelleenkirjoitussäännöissä tai DNS-muutokset, jotka jätetään viimeiselle tunnille.

Uuden ympäristön pitää olla tylsä. Se on tavoite. Jos kohde käyttäytyy lähteestä poikkeavalla tavalla, jota ette ole ottaneet huomioon, siirto tuo nämä erot esiin katkenneina istuntoina, mediaongelmina tai lisäosien vikoina.

Rakentakaa kohde vastaamaan lähdettä

Aloittakaa puhtaalla WordPress-asennuksella kohteessa ja valmistelkaa se multisitea varten ennen kuin tuotte mitään. Jos siirrytte uuteen verkostoon, luokaa sama rakennemalli, jota jo käytätte. Älkää vaihtako alihakemistoista aliverkkotunnuksiin saman siirron aikana, ellei siihen ole painavaa syytä ja erillistä testauspolkua.

Varmistakaa tässä vaiheessa:

• PHP-yhteensopivuus: Käyttäkää tuettuja versioita, joita nykyinen teema ja lisäosakokonaisuus edellyttävät.
• Tietokantayhteys: Testatkaa CLI-pääsy, tuontioikeudet ja taulujen luonnin toiminta.
• Tiedostojärjestelmän omistajuus: Varmistakaa, että WordPress pystyy kirjoittamaan oikeisiin hakemistoihin ilman käyttöoikeuskikkoja.
• Shell-pääsy: Varmistakaa SSH- ja WP-CLI-pääsy ennen siirtopäivää.
• Sähköposti ja ulkoiset palvelut: Valmistelkaa kaikki, mitä verkosto tarvitsee lomakkeisiin, transaktioprosesseihin tai webhookeihin.

Tiimeille, jotka siirtävät infrastruktuuria palveluntarjoajan vaihdon yhteydessä, tässä kohdassa tulee ajankohtaiseksi käytännön opas WordPress-sivuston siirtämiseen uudelle palveluntarjoajalle, koska palveluntarjoajan vaihto ja multisite-siirto menevät usein operatiivisesti päällekkäin, vaikka tietojen reitti olisi eri.

Valmistelkaa DNS sekä julkaisua että perääntymistä varten

DNS-suunnittelu saa useimmissa siirto-oppaissa liian vähän huomiota. Sen pitäisi saada enemmän. Haluatte lopullisen käyttöönoton olevan nopea, mutta haluatte myös perääntymisen olevan nopea, jos tuotannon validointi epäonnistuu.

Tärkein tapa on laskea TTL-arvoja hyvissä ajoin ennen siirtoikkunaa. Se antaa siistimmän käyttöönoton ja realistisen palautusvaihtoehdon. Jos jätätte DNS-valmistelut liian myöhäiseksi, voitte silti siirtää, mutta palautusikkunaa on vaikeampi hallita.

Käyttäkää tätä käyttöönottoa edeltävää tarkistuslistaa:

• Laskekaa TTL-arvot aikaisin: Tehkää se hyvissä ajoin ennen julkaisua, ei sen aikana.
• Dokumentoikaa yhdistetyt verkkotunnukset: Erityisesti multisite-verkostoissa, joissa on brändi-, kieli- tai asiakaskohtaisia verkkotunnuksia.
• Varmistakaa SSL-kattavuus: Aliverkkotunnusten ja yhdistettyjen verkkotunnusten täytyy ratketa siististi käyttöönoton jälkeen.
• Valmistelkaa tarkistushostit etukäteen: Käyttäkää ei-julkisia validointitapoja reitityksen testaamiseen ennen tuotantoliikenteen vaihtamista.

Älkää ohittako puhdasta asennusta

Monet tiimit haluavat ensin kopioida koko vanhan asennuksen ja ”siivota sen myöhemmin”. Se yleensä raahaa vanhat oletukset mukaan uuteen ympäristöön. Tuore asennus kohteessa antaa tunnetun lähtötason ja helpottaa vikojen eristämistä.

Jos siirtoon kuuluu itsenäisen sivuston muuttaminen alisivustoksi tai verkoston luominen ensin kohteeseen, ympäristön valmistelun täytyy ottaa huomioon myös multisiten vakiot ja sivustorakenne, joita tuotavat tiedot odottavat. Tässä kohdassa siirtoprojektit joko pysyvät hallinnassa tai alkavat kerätä kertaluonteisia korjauksia.

Täydellinen varmuuskopio ja tietokannan siirto

Tässä vaiheessa yksi väärä komento voi kaataa verkoston jokaisen sivuston. Multisitessä käyttäjät, roolit, sivustojen taulut, verkostoasetukset ja suuri osa lisäosien tiedoista ovat sidoksissa toisiinsa. Huolimaton tuonti ei epäonnistu siististi. Se aiheuttaa osittaisia rikkoutumisia, jotka toimitus löytää päiviä myöhemmin.

Toimivia polkuja on kaksi. Käyttäkää multisitea varten tehtyä siirtolisäosaa tai tehkää siirto WP-CLI:llä ja ottakaa vastuu jokaisesta vaiheesta itse. Käytän molempia. Oikea valinta riippuu verkoston koosta, muutosikkunasta ja siitä, kuinka paljon operatiivista kuria tiimi pystyy ylläpitämään kello 2 yöllä.

Valitkaa siirtotapa riskin, ei mieltymyksen perusteella

Lisäosa on usein turvallisempi, kun projektilla on lyhyt huoltoikkuna, kokemattomampi luovutustiimi tai verkosto, jossa on paljon alisivustoja ja yhdistettyjä verkkotunnuksia. All-in-One WP Migration on edelleen yleinen valinta, koska se paketoi verkoston tavalla, joka vähentää taulutason virheitä, ja tekee tuonnin aikana WordPressin huomioivan haun ja korvauksen. Tämä suoja on multisitessä tärkeä, koska serialisoituja arvoja on asetuksissa, widgeteissä, sivunrakentajien tiedoissa ja lisäosien asetuksissa koko verkostossa.

WP-CLI sopii paremmin, kun tarvitsette skriptattavaa toistettavuutta, valikoivia korvauksia, ympäristökohtaista hallintaa tai siirtolokia, jonka voitte palautuksen aikana antaa toiselle kehittäjälle. Se on myös parempi vaihtoehto, kun yritystason vaatimukset ulottuvat pelkkää tiedonsiirtoa pidemmälle. Lisäosien lisensointi voi rikkoutua verkkotunnuksen tai palvelimen vaihdon jälkeen. Monikieliset lisäosat tallentavat SEO-metatiedot usein omiin tauluihin tai serialisoituihin asetusjoukkoihin. Jos näitä arvoja ei siirretä siististi, hakusijoitukset ja lisenssien aktivoinnit voivat pudota samaan aikaan.

Jos kohde rakennetaan alusta asti, aloittakaa puhtaasta verkostosta, joka vastaa tuotavien tietojen odottamaa rakennetta. Tämä on vielä tärkeämpää, jos muutatte itsenäisen asennuksen verkostoksi tai vaihdatte aliverkkotunnus- ja alihakemistotilan välillä. Käyttäkää dokumentoitua WordPress Multisiten asennus- ja määritysprosessia ennen tuontia, jotta tietokanta päätyy verkostoon, jossa on oikeat vakiot ja tauluoletukset.

WP-CLI-työnkulku tiimeille, jotka tarvitsevat hallintaa

Aloittakaa täydellisellä viennillä. Ei osittaisella vedoksella. Ei ”vain aktiivisen sivuston tauluilla”. Koko verkostolla.

wp db export network-backup.sql --all-tables

Ennen URL-osoitteiden muuttamista tehkää koeajo ja tarkistakaa tuloste:

wp search-replace 'old-domain.com' 'new-domain.com' --network --precise --recurse-objects --all-tables --dry-run

Jos laajuus näyttää oikealta, ajakaa varsinainen korvaus:

wp search-replace 'old-domain.com' 'new-domain.com' --network --precise --recurse-objects --all-tables

Nämä liput tekevät oikeaa työtä. --network estää sivustokohtaisen eriytymisen. --precise vaihtaa nopeuden tarkkuuteen, mikä on siirron aikana yleensä oikea vaihtokauppa. --recurse-objects suojaa serialisoidut rakenteet. --all-tables kattaa lisäosien ja omat taulut, jotka tiimit unohtavat, kunnes jokin liiketoiminnalle kriittinen pettää.

Serialisoidut tiedot ovat maamiina. Jos työkalu ei ymmärrä WordPressin serialisointia, pitäkää se kaukana tietokannasta.

Tärkeimmät WP-CLI:n search-replace-komennot multisitelle

Varmuuskopioikaa verkosto kuin odottaisitte joutuvanne palauttamaan sen

Käyttökelpoinen varmuuskopiokokonaisuus on enemmän kuin jaetussa kansiossa lojuva SQL-vienti. Verkostoissa, joissa panokset ovat suuret, haluan neljä asiaa ennen kuin kukaan koskee tuotantoon:

• Täydellinen tietokantavedos: Mukaan verkostotaulut, käyttäjätaulut, lisäosien taulut ja kaikki omat taulut.
• wp-content-tilannevedos: Teemat, lisäosat, mu-plugins, lataukset, kielitiedostot ja omien integraatioiden koodi.
• Kopiot määrityksistä: wp-config.php, objektivälimuistin asetukset, palvelimen vhost-säännöt sekä kaikki verkostoon sidotut cron- tai worker-määritykset.
• Palautusmuistiinpanot: Palautuksen tarkka sijainti, kuka sen varmisti, mikä versio tallennettiin ja kuinka kauan palautuksen odotetaan kestävän.

Tässä vaiheessa kannattaa myös viedä kaikki, mikä ei välttämättä selviä siististi tavallisesta tiedostojen ja tietokannan siirrosta. Maksullisten lisäosien lisenssiavaimet ovat yleinen esimerkki. Jotkin toimittajat sitovat aktivoinnit verkkotunnuksiin, IP-osoitteisiin tai laitteiden sormenjälkiin. Poistakaa aktivoinnit tarvittaessa, dokumentoikaa nykyiset aktivoinnit ja varmistakaa uudelleenmyöntämisen ehdot ennen käyttöönottoa. Jos verkostossa on käytössä monikielisen SEO:n lisäosia, tarkistakaa, mihin hreflang-tiedot, käännetyt slugit, uudelleenohjaussäännöt ja SEO-metatiedot tallennetaan. Näiden tietojen menetys ei aina näy PHP-virheenä. Se näkyy liikenteen menetyksenä viikkoa myöhemmin.

Toistuvat tietokantavirheet multisite-projekteissa

Samat virheet toistuvat kerta toisensa jälkeen:

• Raa’an SQL-korvauksen ajaminen serialisoituun sisältöön
• Vain näkyvien sivustotaulujen vienti ja verkosto- tai lisäosataulujen unohtaminen
• Tuonti kohteeseen, jossa on väärä multisite-tila tai vääriä oletuksia taulujen etuliitteestä
• Lisäosien lisenssien uudelleenaktivoinnin unohtaminen, kunnes kriittiset toiminnot lakkaavat toimimasta
• Ensisijaisten verkkotunnusten päivittäminen tarkistamatta monikielisen SEO:n kenttiä, canonical-tageja tai hreflang-viittauksia

Korjaus ei ole monimutkainen, mutta se vaatii kurinalaisuutta. Viekää koko verkosto. Kirjatkaa jokainen komento. Testatkaa korvaukset lipulla --dry-run. Pitäkää koskematon kopio siirtoa edeltävästä tietokannasta. Yritystason siirroissa komentohistoria, SQL-artefaktit ja lisenssiluettelot ovat osa liiketoiminnan jatkuvuutta, eivät ylimääräistä paperityötä.

Tiedostojen siirto ja verkoston määritys

Perjantai-illan käyttöönotot epäonnistuvat tässä useammin kuin missään muualla. Tietokanta tuodaan siististi, etusivu renderöityy, kaikki rentoutuvat, ja sitten toimitus huomaa puuttuvia mediatiedostoja, lisensoidut lisäosat siirtyvät rajoitettuun tilaan tai yhdistetty alueellinen sivusto alkaa tarjoilla vääriä tiedostoja. Multisite-siirrossa tiedostojärjestelmä ja verkoston määritys ratkaisevat, onko julkaisu vakaa vai näyttääkö se vakaalta vain ensimmäiset kymmenen minuuttia.

Riskialttein hakemisto on yleensä wp-content/uploads. Se on suuri, sotkuinen ja täynnä liiketoiminnalle kriittisiä tiedostoja, joita kukaan ei huomaa, ennen kuin kampanjan laskeutumissivu, käännetty PDF tai tuotekuva katoaa.

Siirtäkää tiedostot: ensin eheys, sitten nopeus

Suurissa verkostoissa rsync on oletusvalinta, koska se säilyttää rakenteen, voi jatkaa siististi keskeytyksen jälkeen ja antaa siirtotavan, jonka voi ajaa useammin kuin kerran ennen käyttöönottoa. Sillä on merkitystä. Yksittäinen suuri kertakopio on hitaampi validoida ja vaikeampi luottaa.

Vakiomalli näyttää tältä:

rsync -avz --progress /path/to/source/wp-content/ /path/to/destination/wp-content/

Yritysverkostoissa jaan siirron vaiheisiin. Ensin kopioidaan teemat, lisäosat ja mu-plugins. Lataukset kopioidaan erikseen. Sitten lähellä käyttöönottoa ajetaan viimeinen synkronointi, joka poimii vain muuttuneet tiedostot:

rsync -avz --delete /path/to/source/wp-content/uploads/ /path/to/destination/wp-content/uploads/

Lippu --delete on hyödyllinen, mutta vain kun olette varmoja, että kohde on kertakäyttöinen tai jo varmistettu. Huolimattomasti käytettynä se voi poistaa tiedostoja, jotka on valmisteltu kohteeseen käsin.

Välttäkää tässä työssä pitkiä FTP-istuntoja. Ne ovat hitaita, ne piilottavat osittaiset epäonnistumiset ja jättävät sekavan kirjausjäljen, kun joku kysyy, mitkä tiedostot siirtyivät perille. Suurten lataushakemistojen kohdalla vaiheittainen kopiointi rsync-työkalulla on käytännöllinen tapa säilyttää tiedostojen eheys ja pitää siirto toistettavana.

Käyttöoikeudet ansaitsevat oman tarkistuksensa. Jos omistajuus tai tiedostojen tilat muuttuvat siirron aikana, kuvien luonti, välimuistiin kirjoittaminen ja lisäosien päivitykset voivat epäonnistua julkaisun jälkeen. Validoikaa ne erikseen:

find /path/to/destination/wp-content -type d -exec chmod 755 {} ;
find /path/to/destination/wp-content -type f -exec chmod 644 {} ;
chown -R www-data:www-data /path/to/destination/wp-content

Määrittäkää multisite oikein tiedostossa wp-config.php

Kohteen täytyy vastata siirrettävää verkostomallia. Pieni kirjoitusvirhe tiedostossa wp-config.php voi näkyä kirjautumissilmukoina, rikkinäisinä evästeinä tai alisivustoina, jotka ohjautuvat pääsivustolle.

Jos multisite otetaan käyttöön kohteessa, lisätkää:

define('WP_ALLOW_MULTISITE', true);

Tämä vakio kuuluu välittömästi rivin /* That's all, stop editing! Happy publishing. */ eteen. Kun verkoston määritys on valmis, WordPress luo loput multisiten vakiot ja uudelleenkirjoitussäännöt aliverkkotunnus- tai alihakemistotilan perusteella. Pitäkää nämä luodut arvot täsmälleen sellaisinaan. Niiden muokkaaminen käsin ilman syytä on tapa, jolla toimivista verkostoista tulee epäjohdonmukaisia.

Jos tarvitsette viitteen asennuspuolesta arkkitehtuurivalintoja validoidessanne, tämä opas WordPress Multisiten asentamiseen on hyödyllinen ennen kuin lukitsette kohteen määritykset.

Kaksi asetusta ansaitsee siirron aikana erityistä tarkkuutta: verkkotunnusrakenne ja polkuja koskevat oletukset. Jos lähdeverkosto käytti alihakemistoja ja kohde rakennetaan uudelleen aliverkkotunnuksilla, lisäosien asetukset, uudelleenohjauslogiikka ja monikielisen SEO:n polut eivät välttämättä enää vastaa tallennettuja odotuksia. Etusivu voi edelleen latautua, vaikka hreflang-viittaukset, canonical-tagit ja kielikohtaiset median URL-osoitteet rikkoutuvat.

Updraftin opas WordPressin muuttamisesta multisiteksi muistuttaa myös, että WP_ALLOW_MULTISITE on vain lähtökohta. Projekteissa, joissa yksittäisestä sivustosta tulee alisivusto, lisäosien tila ja palautuksen oikea kohde ovat tärkeitä. Palautus väärään sivustokontekstiin voi korvata väärät taulut tai jättää alisivuston määritetyksi kuin itsenäisen asennuksen.

Valitkaa rakenne toiminnan, ei mieltymyksen perusteella

Aliverkkotunnukset ja alihakemistot ovat molemmat päteviä. Oikea valinta riippuu siitä, miten liiketoiminta toimii.

• Aliverkkotunnukset sopivat paremmin, kun jokaista sivustoa käsitellään erillisenä brändinä, maana tai oikeushenkilönä, jolla on oma DNS, SSL ja omat markkinoinnin työnkulut.
• Alihakemistot sopivat paremmin, kun verkosto toimii yhtenä julkaisualustana, jolla on jaettu auktoriteetti ja tiiviisti toisiinsa liittyvä sisältö.
• Yhdistetyt verkkotunnukset lisäävät operatiivista riskiä, koska jokainen yhdistetty kohde tuo lisää SSL:ään, DNS:ään, uudelleenohjauksiin, välimuistiin ja palautukseen liittyviä huomioita.

Tässä tulevat esiin myös lisäosien lisensointiin liittyvät ristiriidat. Joitakin maksullisia lisäosia lisensoidaan verkkotunnuksittain, ympäristöittäin tai aktiivisen sivuston mukaan. Verkosto, joka toimi lähdepalvelimella, voi siirron jälkeen yhtäkkiä näyttää yhdistetyillä verkkotunnuksilla käytöstä poistettuja toimintoja. Tarkistakaa lisenssien hallintapaneelit ennen julkaisua, erityisesti SEO-, lomake-, käännös- ja sivunrakentajalisäosien osalta. Nämä viat eivät aina tuota näkyvää virhettä. Ne näkyvät puuttuvana schema-tulosteena, estettyinä päivityksinä tai ylläpitoilmoituksina, jotka vain verkoston ylläpitäjät näkevät.

Tässä on hyödyllinen läpikäynti ennen kuin viimeistelette nämä asetukset:

Älkää ohittako koodia, joka on teeman ulkopuolella

Multisiten viat johtuvat usein koodista, joka ei alun perinkään ollut aktiivisessa teemassa.

Tarkistakaa kaikki seuraavat:

• Must-use-lisäosat
• Drop-init
• Omat cron-skriptit
• Ympäristökohtaiset include-tiedostot
• Riippuvuudet palvelimen uudelleenkirjoitussäännöistä

Varmistakaa myös objektivälimuistin drop-init, sunrise-määritys, jos verkkotunnusten yhdistäminen riippuu siitä, sekä kaikki käyttöönoton yhteydessä luodut symboliset linkit. Nämä osat tukevat usein todennusta, uudelleenohjauksia, sivuvälimuistia, kuvankäsittelyä ja monikielistä reititystä. Jos yksi puuttuu, verkosto voi näyttää toimivalta, vaikka liiketoiminnan keskeiset polut pettävät kuormituksen alla tai toissijaisilla verkkotunnuksilla.

Käsitelkää tiedostojärjestelmän siirtoa kuin tuotantoon julkaisua. Inventoikaa se, synkronoikaa se vaiheittain ja varmistakaa ensin osat, jotka vaikuttavat liikevaihtoon, SEO:hon ja palautukseen.

Siirron jälkeinen testaus ja verkkotunnusten yhdistäminen

Siirto ei ole valmis, kun etusivu latautuu. Se on testauksen avaussiirto, ei sen päätös. Multisite-verkosto voi näyttää ensisilmäyksellä terveeltä ja samalla kätkeä rikkinäisiä käyttäjärooleja, virheellisiä mediapolkuja, vääränmuotoisia uudelleenohjauksia tai yhden yhdistetyn verkkotunnuksen, joka ohjaa väärälle sivustolle.

Nopein tapa havaita tämä on käsitellä siirron jälkeistä validointia kuin rikosteknistä tutkintaa. Ette todista, että sivusto latautuu. Yritätte todistaa, ettei mitään kriittistä puutu.

Aloittakaa vikaherkimmistä järjestelmistä

Delicious Brains raportoi, että mediatiedostojen polkujen virheellinen käsittely on yleinen sudenkuoppa multisite-siirroissa ja esiintyy noin 35 %:ssa manuaalisista siirtoyrityksistä, kun taas automatisoidut siirrot ennakkotarkistuksin voivat saavuttaa 92 %:n onnistumisasteen, ja manuaaliset siirrot ilman ennakkotarkistuksia epäonnistuvat 28 %:ssa tapauksista, kuten se kertoo artikkelissaan WordPress Multisiten jakamisesta ja alisivuston siirtämisestä.

Nämä tiedot vastaavat sitä, mitä tiimit näkevät tuotannossa. Media hajoaa ensimmäisenä, koska se riippuu yhtä aikaa polkurakenteesta, käyttöoikeuksista ja URL-osoitteiden oikeellisuudesta.

Aloittakaa näistä:

• Mediakirjastot: Avatkaa vanhoja artikkeleita, ei vain uusia. Tarkistakaa artikkelikuvat, galleriat, tekstin sisäiset kuvat ja ladattavat tiedostot.
• Ylläpitäjän pääsy: Varmistakaa Network Admin, alisivustojen ylläpito ja roolikohtaiset kirjautumiset.
• Kriittiset lomakkeet ja transaktiot: Testatkaa lomakkeiden lähetykset, haku, ostoskorit, rajattu sisältö ja sähköpostilla käynnistyvät toiminnot.
• Lisäosien tuloste: Tarkastakaa kaikki, mikä kirjoittaa omia URL-osoitteita, upottaa skriptejä tai tallentaa tietoja omiin tauluihin.

Etusivu on multisite-siirrossa vähiten hyödyllinen testisivu. Syvemmällä oleva sisältö paljastaa todelliset vahingot.

Tehkää jäsennelty tarkistuskierros

Hyvä siirron jälkeinen tarkistuskierros etenee verkostotason tarkistuksista alisivustotason tarkistuksiin. Älkää hyppikö edestakaisin.

Verkostotason tarkistukset

• Sivustorekisteri: Varmistakaa, että jokainen odotettu alisivusto on olemassa ja reitittyy oikein.
• Jaetut käyttäjät: Testatkaa käyttäjällä, joka kuuluu useisiin sivustoihin, ja tarkistakaa hänen oikeutensa jokaisessa.
• Verkoston lisäosat: Varmistakaa, että verkostotasolla aktivoidut lisäosat toimivat edelleen tarkoitetulla tavalla.
• Teemojen saatavuus: Varmistakaa, että käyttöön otetut teemat näkyvät siellä, missä niiden pitää.

Alisivustotason tarkistukset

• Käyttöliittymän renderöinti: Tarkastakaa etusivu, tärkeimmät laskeutumissivut, artikkeliarkistot ja lomakkeet.
• Toimittajan kokemus: Avatkaa lohkoeditori, median lataustyökalu, uudelleenkäytettävät mallit ja mukautetut kentät.
• URL-osoitteiden toiminta: Tarkistakaa kestolinkit, sivutus ja uudelleenohjaukset.
• Lokalisoitu sisältö: Käykää läpi kielikohtainen sisältö ja navigaatio, jos verkosto on monikielinen.

Yksinkertainen testiloki auttaa tiimejä pysymään rehellisinä:

Yhdistäkää verkkotunnukset vasta, kun verkosto on läpäissyt validoinnin

Verkkotunnusten yhdistämisen pitäisi olla yksi viimeisistä vaiheista, ei varhainen arvaus. Kun tuotu verkosto on vakaa kohteessa, ohjatkaa jokainen yhdistetty kohde harkitusti ja validoikaa vastaus sivusto kerrallaan.

SEO-herkissä verkostoissa verkkotunnusten yhdistäminen liittyy myös hakurakenteeseen. Jos monikielinen alisivusto tai alueellinen verkkotunnus alkaa siirron jälkeen käyttäytyä toisin, teidän täytyy tarkastaa canonical-tagit, alternate-tagit ja indeksointipolut. Tämä on erityisen tärkeää tiimeille, jotka vastaavat WordPress Multisiten SEO:sta, jossa tekninen reititys ja hakusignaalit liittyvät tiiviisti toisiinsa.

Tallentakaa uudelleen ja tarkistakaa, mutta älkää luottako pelkästään siihen

Kyllä, kestolinkkien tallentaminen uudelleen auttaa usein tuonnin jälkeen. Ei, se ei ole täydellinen korjaus. Se ei palauta puuttuvia latauksia, ratkaise lisäosien lisenssiongelmia eikä korjaa pieleen menneitä roolimäärityksiä.

Kypsä testauskierros päättyy vasta, kun todelliset käyttäjät pystyvät tekemään työnsä uudessa verkostossa. Siihen asti siirto on edelleen väliaikainen.

Palautussuunnitelmat ja julkaisun optimointi

Kello 2.07 yöllä DNS-vaihto on voimassa, kirjautuminen toimii edelleen ja etusivu näyttää hyvältä. Kymmenen minuuttia myöhemmin maksettu liikenne alkaa osua väärälle alueelliselle sivustolle, maksullinen lisäosa putoaa kahdella alisivustolla kokeilutilaan, ja canonical-tagit osoittavat takaisin vanhaan verkkotunnukseen. Tämä on se osa WordPress Multisite -siirtoa, jota tavalliset tarkistuslistat vähättelevät. Siirto voi onnistua ja julkaisu silti epäonnistua.

Palautuksen täytyy olla toimintamenettely, ei epämääräinen lupaus ”palauttaa varmuuskopio”. Toimistotyössä ero on yksinkertainen. Todellinen palautussuunnitelma nimeää tarkan palautuspisteen, komentopolun, sen, kuka voi hyväksyä perumisen, kuka muuttaa DNS:n ja mitkä ehdot laukaisevat päätöksen. Ilman sitä tiimit menettävät 30–60 minuuttia väittelyyn, kun käyttäjät ja hakurobotit osuvat edelleen rikkinäiseen pinoon.

Kirjoittakaa suunnitelma niin, että päivystävä kehittäjä pystyy ajamaan sen puoliunessa. Pitäkää se lyhyenä ja täsmällisenä:

1. Julkaisun tunniste, joka on sidottu lopulliseen tietokantavedokseen ja tiedostojen tilannevedokseen
2. Palautuskomennot tietokannalle ja latauksille
3. DNS:n palautuksen vastuuhenkilö sekä pääsypolku rekisterinpitäjään tai CDN:ään
4. Lisäosien lisenssien palautusmuistiinpanot kaikesta, mikä on sidottu verkkotunnukseen, IP-osoitteeseen tai ympäristöön
5. Liiketoiminnallinen palautuksen laukaisin, kuten kassan vika, ylläpitäjien lukkiutuminen ulos tai verkkotunnusten väliset reititysvirheet
6. Palautuksen jälkeinen validointi niille harvoille toiminnoille, joilla on ensimmäisenä merkitystä

Jos esimerkiksi kohteen tietokanta on jo ladattu ja teidän täytyy palata nopeasti, runbookin pitäisi sisältää tarkat komennot eikä viittausta ”S3:ssa olevaan varmuuskopioon”:

wp db import /backups/prod-prelaunch.sql
rsync -av /backups/uploads/ wp-content/uploads/
wp cache flush

Jos käytössä on objektivälimuisti tai Redis, lisätkää myös se komento. Jos reunakerroksenne hoitaa uudelleenohjauksia, kirjatkaa, sisältääkö palautus page rules -sääntöjen tai origin-ohitusten poistamisen käytöstä. Olen nähnyt teknisesti oikeiden tietokantapalautusten epäonnistuvan, koska Cloudflare, Route 53 tai kuormantasaaja jatkoi uuden originin tarjoilemista.

DNS on yleensä perumisen hitain osa, minkä vuoksi julkaisun optimointi alkaa ennen julkaisuyötä. Lyhyet TTL-arvot auttavat, mutta ne eivät takaa välitöntä korjausta. Jotkin nimipalvelimet jättävät ne huomiotta. Jotkin asiakkaat ovat aggressiivisen välimuistin takana. Varautukaa sekaliikenteen jaksoon, jolloin osa yleisöstä näkee vanhan pinon ja osa uuden.

Tämä todellisuus muuttaa tapaa julkaista. Jäädyttäkää sisältö ennen käyttöönottoa. Asettakaa tilaukset tai toimitukselliset muutokset jonoon, jos liiketoiminta sietää sen. Jos ei siedä, tarvitsette täsmäytyssuunnitelman kommenteille, lomakkeille, verkkokaupan tiedoille ja käyttäjärekisteröinneille, jotka syntyvät päällekkäisyysikkunan aikana.

Monikielinen SEO tarvitsee oman palautuskynnyksensä. Käytännössä tämä on yksi helpoimmista paikoista ohittaa liiketoimintariski, koska sivu renderöityy normaalisti. Piilossa olevat viat ovat canonical-tageissa, hreflang-pareissa, alueellisissa uudelleenohjauksissa, käännetyissä slugeissa, XML-sivukartoissa ja markkinavalitsimissa. Kokemuksemme mukaan siirretyt multisite-kohteet menettävät usein osan näistä signaaleista irrotuksen tai verkkotunnusten uudelleenyhdistämisen aikana, erityisesti kun SEO-lisäosat tallentavat asetukset eri tasolle kuin tiimi odotti.

Tarkistakaa nämä kohdat heti käyttöönoton jälkeen:

• Canonical-tagit tärkeimmissä sivupohjissa ja keskeisillä laskeutumissivuilla
• Hreflang-parit jokaiselle kieli- tai markkinaversiolle
• Lokalisoidut URL-rakenteet, kuten /de/ tai maakohtaiset aliverkkotunnukset
• Sivukartat, jotka kohteen aktiivinen SEO-lisäosa luo
• Uudelleenohjausten toiminta vanhoista alueellisista URL-osoitteista
• Indeksoinnin hallinta, jotta stagingin noindex-säännöt eivät seuranneet julkaisuun

Lisäosien lisensointi ansaitsee saman huomion. Yritystiimit jäävät tässä kiinni, koska lisäosa toimi vanhassa verkostossa ja pettää sitten irrotetulla sivustolla tai uudessa verkkotunnuksessa. Vikatila on harvoin dramaattinen. Usein kyse on puuttuvasta kenttäryhmästä, käytöstä poistetusta lomakkeiden toimituksesta, estetystä päivityskanavasta tai bannerista, joka muuttuu rikkinäiseksi tulosteeksi välimuistin vanhennuttua. Jos lisäosan toimittaja sitoo lisenssin alkuperäiseen verkostoon, pitäkää manuaaliset aktivointivaiheet julkaisun runbookissa ja päättäkää, onko tämä tilanne palautuksen laukaisin vai tunnettu julkaisun jälkeinen tehtävä.

Julkaisun optimointi tulee vakaustarkistusten jälkeen, ei ennen niitä. Tyhjentäkää välimuistikerrokset. Lämmittäkää tärkeät sivut. Käykää läpi PHP-lokit, verkkopalvelimen lokit, uudelleenohjausketjut, cron-tapahtumat ja transaktiosähköpostit. Testatkaa sitten kaupalliset polut todellisissa olosuhteissa: kirjautuneet istunnot, kielen vaihto, lomakkeiden lähetykset, haku, kassa ja kaikki kolmansien osapuolten callbackit.

Käyttäkää WP-CLI:tä siivoukseen, jonka pitää olla toistettavaa:

wp cache flush
wp rewrite flush --hard
wp cron event run --due-now
wp search-replace 'https://staging.example.com' 'https://example.com' --network --skip-columns=guid

Viimeinen komento on tehokas ja vaarallinen. Multisitessä ajakaa se vasta, kun olette varmistaneet kohdeverkkotunnukset, yhdistetyt hostit ja serialisoitujen tietojen laajuuden. Virheellinen koko verkoston korvaus on tapa aiheuttaa toinen katkos samalla, kun yritetään korjata ensimmäistä.

Vahva julkaisu on tylsä parhaalla mahdollisella tavalla. Käyttäjät jatkavat työtään. Hakusignaalit pysyvät ennallaan. Lisensoidut lisäosat validoituvat edelleen. Ja jos jokin niistä rikkoutuu niin pahasti, että se uhkaa liikevaihtoa tai toimintaa, palautus tapahtuu nopeasti, koska tiimi on jo valinnut laukaisimen, vastuuhenkilön ja tarkat komennot.

Edistyneet skenaariot ja tärkeimmät usein kysytyt kysymykset

Perjantai, klo 17.30: tietokannan tuonti on valmis, lataukset ovat paikallaan ja alisivusto latautuu. Sitten käännökset katoavat hreflang-tageista, lomakelisäosa putoaa kokeilutilaan ja SEO-tiimi huomaa, että canonical-tagit osoittavat nyt vanhaan verkoston verkkotunnukseen. Tämä on se osa, jonka tavalliset multisite-siirron oppaat yleensä ohittavat.

Kalliit viat WordPress Multisite -siirrossa tapahtuvat sen jälkeen, kun tiedostot ja taulut on siirretty. Lisäosien lisensointi voi rikkoutua, kun alisivusto lähtee verkostosta. Monikieliset lisäosat voivat jatkaa sivujen renderöintiä ja samalla menettää kielten väliset suhteet tai metatiedot. Paperilla hyvältä näyttänyt palautussuunnitelma voi hajota, jos lisenssien uudelleenaktivointia, DNS:n ajoitusta tai kolmansien osapuolten callbackeja ei koskaan testattu.

Lisäosien lisensointi on operatiivinen riski, ei siivoustehtävä

Tukifoorumin keskustelut multisite-siirrosta WordPress.orgissa nostavat toistuvasti esiin lisäosien rikkoutumisen yleisenä siirron jälkeisenä ongelmana, joka liittyy usein lisensointiin, puuttuviin multisite-lisäosiin tai verkostokohtaisiin asetuksiin. Käsitelkää sitä julkaisua edeltävänä työvaiheena, ei julkaisun jälkeisenä yllätyksenä.

Maksullinen lisäosa voi toimia oikein verkoston sisällä ja pettää sillä hetkellä, kun sivustosta tulee itsenäinen. Näen tätä useimmin verkkotunnukseen sidottujen lisenssien kohdalla, lisäosissa, jotka tallentavat tilansa tauluun wp_sitemeta sivustokohtaisten asetusten sijaan, sekä toimittajilla, jotka myyvät multisite-tuen erillisenä oikeutena.

Tarkistakaa nämä kohdat ennen kuin hyväksytte käyttöönoton:

• Tukeeko lisäosa sekä multisite- että itsenäisiä asennuksia?
• Onko nykyinen lisenssi voimassa kohdeverkkotunnukselle?
• Ovatko aktivointitiedot verkoston asetuksissa, sivuston asetuksissa, omissa tauluissa vai ulkoisessa API:ssa?
• Voiko lisäosan aktivoida uudelleen CLI:n kautta vai vain wp-adminin kautta?
• Jos lisenssi pettää, menettääkö sivusto toimintoja, menettääkö se päivitykset vai lakkaako se renderöimästä kriittistä sisältöä?

Jos toimittaja ei pysty vastaamaan näihin kysymyksiin selkeästi, varautukaa manuaaliseen korjaamiseen ja päättäkää, estääkö lisäosan vika julkaisun.

Asetusten laajuuden voi tarkistaa nopeasti WP-CLI:llä:

wp option get active_plugins
wp site option get active_sitewide_plugins
wp db query "SELECT meta_key FROM wp_sitemeta ORDER BY meta_key;"

Verratkaa irrotetuilla alisivustoilla myös lisäosakohtaisia tauluja. Jotkin lisäosat tallentavat lisenssejä, kielivastaavuuksia tai jonojen tilaa tavallisten asetusten ulkopuolelle.

Monikielinen SEO rikkoutuu hiljaa

Monikielinen alisivusto voi näyttää toimittajille hyvältä ja silti menettää hakuarvoa siirron jälkeen. Yleisiä vikoja ovat väärät canonical-tagit, puuttuvat hreflang-tagit, rikkinäiset käännetyt URL-slugit ja kielivalitsimet, jotka osoittavat vanhoihin hosteihin. Siksi monikielinen validointi kuuluu julkaisun tarkistuslistaan eikä vain yleiseen laadunvarmistukseen.

WPML-, Polylang- tai omissa monikielisissä kokoonpanoissa varmistakaa siirretyllä sivustolla kaikki seuraavat:

• Canonical-tagit osoittavat oikeaan julkaistuun verkkotunnukseen
• Hreflang-tagit viittaavat oikeisiin kieliversioihin
• Käännetyt sivut on edelleen yhdistetty toisiinsa
• XML-sivukartat sisältävät jokaisen kielen ja oikeat hostinimet
• Uudelleenohjaussäännöt säilyttävät vanhat kielipolut ja kyselyparametrit tarvittaessa

Älkää luottako etusivun tarkistukseen. Testatkaa syviä URL-osoitteita, sivutettuja arkistoja ja liikevaihtoa tuottavia sivuja.

Kolme tärkeää usein kysyttyä kysymystä

Voiko yksittäisen sivuston siirtää olemassa olevaan multisite-verkostoon?
Kyllä, mutta luokaa ensin kohdealisivusto ja palauttakaa oikeaan blog ID -kontekstiin. Jos tuotte tiedot väärällä sivuston ID:llä, latauspolut, käyttäjäroolit ja lisäosien asetukset voivat kiinnittyä vääriin tauluihin. Tarkistakaa kohde ennen tuontia komennoilla:

wp site list
wp db tables | grep _2_

Korvatkaa _2_ sillä todellisella blog ID:llä, jota aiotte käyttää.

Voiko alisivuston irrottaa omaksi itsenäiseksi WordPress-asennuksekseen?
Kyllä. Itse siirto on yleensä suoraviivainen. Riski on kaikessa sitä ympäröivässä: mediapolkujen uudelleenkirjoituksissa, ajastetuissa tehtävissä, lisensoiduissa lisäosissa ja SEO-signaaleissa, joita aiemmin hallittiin verkostotasolla. Todellisissa projekteissa juuri irrotus koettelee liiketoiminnan jatkuvuutta.

Entä käyttäjät ja oikeudet?
Multisitessä käyttäjät ovat globaaleja. Roolit eivät ole. Varmistakaa siirron jälkeen oikeudet kohdesivustolla, erityisesti toimittajien, kauppapäälliköiden ja kaikkien SSO-integroitujen tilien osalta. Jos alkuperäinen verkosto jakoi käyttäjiä kohteiden välillä, tarkistakaa, pitäisikö näiden käyttäjien ylipäätään olla olemassa irrotetulla sivustolla.

Kysymys, jota kukaan ei kysy tarpeeksi aikaisin

Mikä on nopein turvallinen palautus, jos siirretty sivusto on julkaistu ja liikevaihtoa tuottavat polut alkavat pettää?
Käyttäkää palautusta, joka palauttaa viimeisimmän toimivaksi tiedetyn tietokannan, ohjaa liikenteen takaisin vanhaan ympäristöön ja sisältää kaikki toimittajakohtaiset vaiheet, joita tarvitaan lisenssien uudelleenvalidointiin tai monikielisten palvelujen uudelleenkäyttöönottoon. Jos palautuksenne riippuu siitä, että ihmiset selvittävät asioita katkoksen aikana, se ei ole palautussuunnitelma.

Pitäkää kirjallinen järjestys, jossa on nimetyt vastuuhenkilöt, DNS:n TTL-oletukset ja tarkat palautuskomennot. Esimerkiksi:

wp db import prelaunch-backup.sql
wp search-replace 'https://new.example.com' 'https://old.example.com' --skip-columns=guid
wp cache flush

Ajakaa tämä vain siinä ympäristössä, jonka aiotte palauttaa. Multisitessä huolimaton search-replace voi laajentaa katkosta.

Multisite-siirron vaikein osa on liiketoiminnan toiminnan säilyttäminen paineen alla. Tiedonsiirto on vain yksi kerros. Lisensointi, monikielinen SEO ja palautuskuri estävät siirtoa muuttumasta liikevaihtoon vaikuttavaksi häiriöksi.

Jos tiiminne tarvitsee kokeneita tekijöitä korkean riskin multisite-siirtoon, IMADO on sellainen kehityskumppani, joka kannattaa ottaa mukaan aikaisin. Se hoitaa osat, jotka yleensä aliarvioidaan, kuten monikielisen arkkitehtuurin, multisiten monimutkaisuuden, suorituskyvyn ja julkaisukurin, tekemättä projektista geneeristä ”sivustosiirtoa”.