Hvorfor Google reverserer domeneflytting etter 4 måneder og hvordan redde WooCommerce

Å bytte domenenavn for en aktiv WooCommerce-nettbutikk er en av de mest risikofylte tekniske operasjonene innen e-handel. I oktober 2026 omtalte fagfora på Google Search Central og Search Engine Roundtable et oppsiktsvekkende tilfelle: Fire måneder etter at 301-videresendinger var implementert og adresseendringen var godkjent i Google Search Console, begynte søkemotoren plutselig å flytte organisk synlighet og indeksering tilbake til det gamle domenet.

Mange nettbutikkeiere og utviklere antar feilaktig at en flytteprosess er fullført så snart Search Console godkjenner forespørselen og de første sidene vises i søkeresultatene. I praksis overvåker Googles algoritmer kanoniske signaler fortløpende. Hvis det nye domenet viser tegn til teknisk ustabilitet, kan søkemotoren på egen hånd overstyre adresseendringen og hente fram det gamle domenet igjen.

I denne veiledningen analyserer vi årsakene til dette problemet, belyser kritiske feller i WooCommerce-databaser og viser hvilke tekniske grep som sikrer butikken mot alvorlig fall i organisk trafikk.

#Hvorfor Google går tilbake til det gamle domenet etter noen måneder

At Google vender tilbake til et gammelt domene skyldes ikke en tilfeldig feil i søkeroboten, men er en direkte konsekvens av hvordan Googles kanoniseringssystem (Canonicalization System) arbeider. Google ser verken på 301-videresendinger eller adresseendringsverktøyet som en endelig overføring av rangering. De behandles som sterke signaler som må bekreftes kontinuerlig gjennom mange uavhengige målepunkter.

Når Googlebot besøker det gamle domenet og mottar et svarhode av typen HTTP/1.1 301 Moved Permanently, overføres autoritet til den nye adressen. Samtidig sjekker boten helsetilstanden til det nye domenet. Dersom det i månedene etter flyttingen oppstår tekniske mangler:

1. Det nye domenet opplever ustabilitet med 500-, 502- eller 504-feil under belastning fra AI-crawlere og ordinære kunder.
2. Flere sider på det nye domenet svarer med statuskode 200 OK, men viser tomt innhold eller PHP-advarsler, noe som utløser en automatisk klassifisering som soft 404.
3. Taggene rel="canonical" på det nye nettstedet peker feilaktig tilbake til det gamle domenet på grunn av feilkonfigurerte SEO-utvidelser eller hardkodede filtre i undertemaet.
4. Den interne lenkestrukturen (menyer, bunntekst, produktbeskrivelser, brødsmuler) benytter fremdeles det gamle domenet.
5. Den eksterne lenkeprofilen til det nye domenet forblir fraværende, samtidig som hurtigbufringsfeil på den gamle tjeneren fører til at 301-hoder faller bort.

Når slike avvik vedvarer, faller tilliten til det nye domenet drastisk. Når usikkerheten passerer en kritisk grense, konkluderer Googlebot med at flyttingen var utilsiktet eller feilaktig, og gjenoppretter de opprinnelige adressene i søkeindeksen.

#Hvordan Google vurderer kanoniske signaler ved domenebytte

Kanonisering i moderne søkemotorer er en sammensatt beslutningsprosess. Systemet baserer seg ikke utelukkende på en enkel kode i HTML-toppen, men sammenstiller formelle instruksjoner med den faktiske nettverksoppførselen.

#Hvilke kanoniske signaler avgjør domenvalget i søkealgoritmene

Tabellen nedenfor viser hvordan Googlebot vekter ulike signaler under vurderingen av kanonisk adresse:

Dersom disse signalene spriker (for eksempel hvis en 301-videresending peker til det nye domenet, men den kanoniske taggen i HTML-koden på det nye domenet viser tilbake til det gamle), oppstår det en konflikt i algoritmen. Over tid vil motoren velge domenet med lengst historikk og sterkest ekstern lenkestøtte.

#Hvorfor feilaktige rel canonical-tagger reverserer migrering i Google

I WooCommerce-butikker genererer utvidelser som Yoast SEO, Rank Math eller The SEO Framework kanoniske tagger basert på nettstedsadressen i WordPress-innstillingene. Hvis utviklere kopierer databasen, men glemmer egendefinerte kodebiter i temaet:

// Farlig filter i functions.php i undertemaet
add_filter('wpseo_canonical', function($canonical) {
    return str_replace('ny-butikk.no', 'gammel-butikk.no', $canonical);
});

Da sender hver eneste produktside på det nye domenet en entydig beskjed til Googlebot: Denne siden er kun en kopi, og det autoritative originaldokumentet finnes på det gamle domenet. Når roboten leser tusenvis av slike sider, følger den anvisningen og fjerner det nye domenet fra indeks.

#Hvilke feil i 301-videresendinger ødelegger en WooCommerce-nettbutikk

Riktig oppsett av videresendinger krever langt mer oppmerksomhet enn noen enkle linjer i en .htaccess-fil. I store nettbutikker med titusenvis av varelinjer kan små rutingfeil føre til uopprettelige skader på indekseringen.

#Hvorfor viderekoblingskjeder og CDN-grenser fører til tilbakeslag

Moderne kantenettverk har bestemte begrensninger. For eksempel har Cloudflare Pages en streng grense på 100 KB for konfigurasjonsfilen _redirects (tilsvarer omtrent 2000 til 2500 statiske rutingregler). Dersom man laster opp en fil på 400 KB, blir ikke byggingen avbrutt med feilmelding. Systemet kutter ganske enkelt reglene som overskrider grensen.

Dermed fungerer de første 2000 produktene med korrekte 301-hoder, mens de resterende 15 000 produkt- og kategorialenkene ender med uoppdagede 404-feil eller havner på forsiden.

Et annet vanlig problem er viderekoblingskjeder:

Gammel URL -> Ny URL (HTTP) -> Ny URL (HTTPS uten www) -> Ny URL (HTTPS med www og skråstrek)

Ifølge Googles dokumentasjon om HTTP-feil følger Googlebot opptil 10 videresendingshopp ved gjennomsøking av nettinnhold, og verktøyet for nettadresseinspeksjon følger ikke videresendinger i det hele tatt. Veiledningen for flytting av nettsteder fraråder også kjeder: hver gamle adresse bør videresendes direkte til sitt endelige mål. Hvert mellomliggende hopp er en ekstra HTTP-forespørsel før innholdet nås, ganget med hver adresse i katalogen.

#Hvordan videredirigere fasettert navigasjon og filtreringsparametere riktig

WooCommerce-butikker produserer store mengder URL-varianter via GET-parametere for filtrering:

• ?filter_farge=svart
• ?filter_stoerrelse=xl&min_price=100
• ?merke=produsent-a

En vanlig feil er å forsøke å mappe hver enkelt filtervariant manuelt i statiske omdirigeringstabeller. Dette overbelaster tjenerens minne. Den teknisk solide løsningen benytter dynamiske regler i Nginx:

# Nginx-oppsett på gammel tjener for å bevare forespørselssti og parametere
server {
    listen 443 ssl http2;
    server_name gammel-butikk.no www.gammel-butikk.no;

    ssl_certificate /etc/ssl/certs/gammel-butikk.crt;
    ssl_certificate_key /etc/ssl/private/gammel-butikk.key;

    # Nøyaktig 1:1 videresending som bevarer hele stien og spørrestrengen
    location / {
        return 301 https://ny-butikk.no$request_uri;
    }
}

Ved å bruke variabelen $request_uri blir en forespørsel til https://gammel-butikk.no/kategori/sko/?filter_farge=svart umiddelbart sendt til https://ny-butikk.no/kategori/sko/?filter_farge=svart i ett enkelt hopp, uten tap av signaler.

#Hvordan migrere WooCommerce-databasen uten å ødelegge taksonomier

WordPress-databasen benytter spesielle formater for lagring av data. Innstillinger, oppsett av Gutenberg-blokker og produktmetadata lagres som serialiserte PHP-objekter.

#Hvorfor direkte SQL-søk og erstatt skader serialiserte PHP-data

En serialisert streng i PHP inneholder nøyaktige angivelser av tegnlengde. Et enkelt eksempel fra wp_options:

s:22:"https://gammel-butikk.no";

Verdien s:22 angir at den etterfølgende teksten har en lengde på 22 tegn. Kjører man en standard SQL-spørring direkte i databasen:

-- FARLIG SPØRRING: ØDELEGGER SERIALISERTE PHP-DATA
UPDATE wp_options 
SET option_value = REPLACE(option_value, 'gammel-butikk.no', 'ny-moderne-nettbutikk.no');

Det nye domenet ny-moderne-nettbutikk.no har 24 tegn, men lengdeindikatoren i databasen forblir s:22. Når WordPress forsøker å lese inn verdien via unserialize(), feiler parseren. Resultatet er at betalingsløsninger slutter å virke, fraktsoner forsvinner og blokkstrukturer i editoren blir ødelagt.

#Ferdig WP-CLI-skript for trygt domenebytte i databasen

Det anbefalte verktøyet for oppdatering av domener i WordPress er kommandolinjeverktøyet WP-CLI. Det leser serialiserte verdier inn i minnet, foretar tekstendringen, beregner tegnlengden på nytt og lagrer dataene trygt.

Følgende Bash-skript automatiserer prosessen, inkludert sikkerhetskopiering og tømming av hurtigbuffer:

#!/usr/bin/env bash
# Sikker domeneflytting for WooCommerce med WP-CLI
set -euo pipefail

OLD_DOMAIN="gammel-butikk.no"
NEW_DOMAIN="ny-butikk.no"
WP_PATH="/var/www/ny-butikk/public"

echo "=== Starter databasemigrering ==="

# 1. Ta sikkerhetskopi av databasen før modifisering
wp db export "${WP_PATH}/backup-pre-migration-$(date +%F).sql" --path="${WP_PATH}"

# 2. Gjennomfør en testkjøring for å inspisere treff
echo "Kjører test (Dry Run)..."
wp search-replace "https://${OLD_DOMAIN}" "https://${NEW_DOMAIN}" \
    --all-tables \
    --dry-run \
    --path="${WP_PATH}"

# 3. Utfør selve erstatningen for fullstendige HTTPS-adresser
echo "Utfører faktisk søk-og-erstatt for HTTPS..."
wp search-replace "https://${OLD_DOMAIN}" "https://${NEW_DOMAIN}" \
    --all-tables \
    --precise \
    --recurse-objects \
    --path="${WP_PATH}"

# 4. Erstatt rene domenenavn uten protokoll, men hopp over GUID
wp search-replace "${OLD_DOMAIN}" "${NEW_DOMAIN}" \
    --all-tables \
    --precise \
    --skip-columns=guid \
    --path="${WP_PATH}"

# 5. Forny permalenkestrukturen i WooCommerce
echo "Fornyer omskrivingsregler..."
wp rewrite flush --hard --path="${WP_PATH}"

# 6. Tøm objektbuffer (Redis / Memcached)
wp cache flush --path="${WP_PATH}"

echo "=== Databasemigrering fullført uten feil ==="

Parameteren --skip-columns=guid er avgjørende. I henhold til WordPress-retningslinjene skal guid-kolonnen i wp_posts fungere som en unik identifikator for nyhetslesere, og må aldri endres ved domenebytte.

#Hvor lenge må du beholde det gamle XML-nettstedskartet og tjeneren aktiv

En alvorlig feil er å stenge den gamle tjeneren eller la domenet utløpe etter seks måneder.

Google Search Central anbefaler at videresendingsinfrastrukturen holdes i drift i minst 12 måneder. For nettbutikker er det mest fornuftig å beholde det gamle domenet og videresendingene permanent. Et utløpt domene kan bli kjøpt opp av andre og brukt til useriøse formål, noe som ødelegger verdifulle historiske lenker.

I tillegg bør det gamle domenet fortsette å levere et dedikert XML-nettstedskart med alle de tidligere adressene:

<?xml version="1.0" encoding="UTF-8"?>
<!-- XML-nettstedskart på gammel-butikk.no med videresendte adresser -->
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://gammel-butikk.no/produkt/baerbar-pc/</loc>
    <lastmod>2026-10-14</lastmod>
  </url>
  <url>
    <loc>https://gammel-butikk.no/kategori/elektronikk/</loc>
    <lastmod>2026-10-14</lastmod>
  </url>
</urlset>

Dette nettstedskartet legges inn i Google Search Console for det gamle domenet. Det gir Googlebot en direkte oversikt over adresser som må sjekkes jevnlig for å bekrefte at 301 Moved Permanently-svaret er varig.

#Hvordan sjekke tjenerlogger og oppdage indekseringsreversering i Search Console

Tidlig oppdagelse av uregelmessigheter hindrer inntektstap. Når en migrering er i ferd med å slå feil, viser tegnene seg i tjenerloggene flere uker før det merkes på søkeresultatene.

#Hvilke avvik i Search Console-rapportene bør du se etter

I Google Search Console bør du følge med på tre rapporter:

1. Rapport for sideindeksering på det nye domenet: En markant økning i Gjennomgått: ikke indeksert for øyeblikket eller Duplikat: brukeren har ikke valgt kanonisk side. Dette viser at Googlebot nøler med å inkludere de nye adressene.
2. Ytelsesrapport for det gamle domenet: Hvis visninger for det gamle domenet begynner å øke igjen etter måneder med nesten null aktivitet, betyr det at Google igjen leverer gamle adresser til brukerne.
3. Nettadresseinspeksjon: Test sentrale produkt- og kategorisider. Hvis feltet Kanonisk adresse valgt av Google viser det gamle domenet, mens Kanonisk adresse valgt av bruker viser det nye, foreligger det en aktiv konflikt.

#Hvordan overvåke HTTP-statuskoder i Cloudflare Logpush og Nginx

Gjennomgang av tilgangslogger gir sanntidsinnsikt i robotenes aktivitet. For å filtrere forespørsler fra Googlebot på den gamle tjeneren, kan du bruke denne kommandoen:

# Filtrer Nginx-tilgangslogger etter Googlebot-statuskoder på gammelt domene
awk -F'"' '$6 ~ /Googlebot/ { print $1, $2, $3 }' /var/log/nginx/gammel-butikk.access.log \
  | awk '{ print $1, $6, $7 }' \
  | sort | uniq -c | sort -nr | head -n 30

Ved normal drift skal resultatet kun inneholde koden 301. Dersom det opptrer 200, 302, 404 eller 502, tyder det på feil som krever umiddelbar utbedring.

#Hva du må gjøre med interne lenker i Gutenberg-blokker og ACF-felter

En hyppig årsak til reversering av migreringer er gjenværende interne lenker. Selv om du har kjørt wp search-replace, kan gamle adresser ligge igjen i uvanlige dataformater som Base64-strenger, JSON i wp_termmeta eller statiske lenker i maler.

Følgende områder krever grundig kontroll:

• Navigasjonsmenyer i WordPress: Sjekk under Utseende -> Menyer at menypunkter av typen Egendefinerte lenker ikke har hardkodede adresser til gammel-butikk.no.
• Blokkmaler (Full Site Editing): HTML-filer i mappene /templates og /parts må undersøkes for statiske lenker til vilkår eller kontaktsider.
• ACF Flexible Content: Forsider lagrer ofte relasjoner som ID-er, men i tekstfelter fra editoren finnes det ofte manuelt innlagte lenker til det gamle domenet.
• Kasse- og betalingsmoduler: Kontroller at moduler for betaling eller frakt ikke har gamle retur-URL-er lagret i innstillingene.

Med et enkelt kommandolinjeverktøy kan du skanne det nye nettstedet for gjenværende lenker:

# Skann den nye nettbutikken for gjenværende referanser til det gamle domenet
wget --spider --recursive --no-verbose --output-file=wget-scan.log https://ny-butikk.no || true
grep "gammel-butikk.no" wget-scan.log || echo "Ingen direkte lenker til gammelt domene funnet."

#Hvordan løse problemet i 7 steg hvis Google har reversert domeneflyttingen

Hvis nettbutikken din er rammet av reversering og gamle adresser dukker opp i søkeresultatene igjen, bør du gjennomføre denne redningsplanen:

+-------------------------------------------------------------------+
|               GJENOPPRETTINGSPLAN VED REVERSERT FLYTTING          |
+-------------------------------------------------------------------+
                                  |
                                  v
         [ STEG 1: Kontroller HTTP-hoder og fjern 301-løkker ]
                 (Sørg for at alle gamle URL-er gir ren 301)
                                  |
                                  v
        [ STEG 2: Sjekk rel canonical-tagger på nytt domene ]
               (Ingen side må peke tilbake til gammelt domene)
                                  |
                                  v
       [ STEG 3: Rett opp soft 404-feil i produktkatalogen ]
               (Utsolgte varer må svare med statuskode 200)
                                  |
                                  v
      [ STEG 4: Kjør grundig søk-og-erstatt i databasen ]
               (Fjern gamle adresser fra menyer, ACF og bunntekst)
                                  |
                                  v
         [ STEG 5: Oppdater og send inn XML-nettstedskart ]
               (Aktive kart på både gammel og ny GSC-property)
                                  |
                                  v
       [ STEG 6: Send inn adresseendring på nytt i GSC ]
               (Forny forespørselen etter at feil er utbedret)
                                  |
                                  v
      [ STEG 7: Styrk eksterne signaler for det nye domenet ]
               (Oppdater Google Bedriftsprofil og sosiale medier)

1. Undersøk HTTP-hoder: Bruk cURL for å kontrollere at enhver sti på det gamle domenet leder direkte med koden 301 til riktig side på det nye domenet. Fjern unødvendige mellomledd.
2. Korriger kanoniske tagger: Kontroller kildekoden på det nye domenet. Taggene må stemme nøyaktig med gjeldende nettadresse og ha korrekt HTTPS-protokoll.
3. Fjern soft 404-feil: Gjennomgå sider som rapporteres som innholdsløse i Search Console. Utsolgte varer bør vises med statuskode 200 OK, lagerstatus og forslag til alternative varer, i stedet for tomme feilsider.
4. Gjenta databaserens: Kjør wp search-replace med --precise og --all-tables for å sikre at ingen gamle adresser ligger igjen i temainnstillinger eller innlegg.
5. Bruk doble nettstedskart: Påse at det nye domenet har et kart med utelukkende friske 200 OK-adresser, mens det gamle domenet lister alle videresendte adresser.
6. Forny adresseendringen: Dersom det har gått 180 dager siden forrige innsending, sender du inn adresseendringen på nytt i Search Console etter at de tekniske feilene er rettet.
7. Oppdater eksterne kanaler: Oppdater nettadresser i Google Bedriftsprofil, betalingsløsninger, sosiale medier og bransjeregistre for å sende tydelige signaler til søkemotorene.

#Teknisk konklusjon for programvarearkitekter og nettbutikkeiere

At Google reverserer en domeneflytting er et alvorlig faresignal: Søkemotoren har oppdaget uoverensstemmelser mellom den planlagte flyttingen og den faktiske tilstanden på nettstedet.

I moderne nettbutikker sikres en vellykket flytting gjennom teknisk nøyaktighet:

• Videresendinger må gå direkte i ett trinn og bevare alle filterparametere.
• Databasen må oppdateres med WP-CLI for å bevare serialiserte PHP-data.
• Kanoniske tagger og interne lenker må peke til det nye domenet fra første sekund etter DNS-endringen.
• Det gamle domenet, SSL-sertifikatet og det tilhørende nettstedskartet må holdes aktive i minst 12 måneder.

Før du gjennomfører endringer på produksjonsservere, anbefales det å bestille en helhetlig WordPress migrasjonsvurdering for å kvalitetssikre omdirigeringer og databasestrukturer.

Ved å følge disse rutinene forhindrer du at indekseringen faller tilbake til det gamle domenet, og sikrer stabil omsetning for nettbutikken din.