Google indekserte nettstedet under feil subdomene: slik rydder du opp

Søk etter firmanavnet ditt, og øverst står kanskje ftp.dittfirma.no, test.dittfirma.no eller en IP-adresse i stedet for www. Utvikleren sier at verten er slettet, og resultatene står likevel der. Den 23. oktober 2026 la en nettstedsansvarlig ut akkurat dette spørsmålet på r/DoSEO og r/TechSEO, og John Mueller fra Google svarte etter et kvarter. Plattformen spiller ingen rolle: WordPress, Shopify med eget domene, et headless-oppsett og en statisk side havner alle her på samme måte.

Kort fortalt: det gamle vertsnavnet svarer noe i dag, og det svaret bestemmer hva du gjør. Tabellen under gir valget, resten av artikkelen forklarer hvert punkt med kilder fra Google Search Central.

#Hva skal jeg gjøre med det gamle subdomenet: beslutningstabell

#Hvordan sjekke hva subdomenet svarer i dag

Et av svarene i tråden pekte på det viktigste:

Sjekk først hva en gammel HTTPS-adresse faktisk returnerer nå: en DNS-feil er ikke en 404.

(u/inevidimka, r/DoSEO, 23. oktober 2026, egen oversettelse)

dig +short ftp.example.com
curl -sI https://ftp.example.com/blogg/eksempelartikkel

Tomt svar fra dig betyr at navnet ikke lenger slås opp. Får du en IP, viser curl om du får 200 med hele siden, 404 eller 410, en videresending eller en TLS-feil fordi sertifikatet ikke dekker navnet. Sjekk flere adresser som Google faktisk viser. Googles veiledning om DNS- og nettverksfeil bruker dig på samme måte for A-, CNAME- og NS-poster.

Den vanligste fellen er en slettet virtuell vert der DNS-posten fortsatt står. Da svarer serverens standardnettsted, som regel det samme som på www, og problemet er tilbake.

#Hvorfor valgte Google ftp-adressen og ikke www

Den som spurte, hadde sjekket URL-inspeksjonen i Search Console. FTP-adressen var indeksert og hentet uten feil. Tvillingen på www var ukjent for Google, uten områdekart og uten henvisende side. Detaljen som forklarer resten:

Den brukerdeklarerte kanoniske adressen pekte på selve FTP-adressen. Den Google-valgte kanoniske adressen var også FTP-adressen.

(u/Gullible-Winter294, r/DoSEO, 23. oktober 2026, egen oversettelse)

En DNS-post (ftp, staging eller wildcard) peker til samme server som produksjon, serveren svarer med produksjonsnettstedet fordi det er standardverten, og malen bygger canonical-taggen fra vertsnavnet i forespørselen i stedet for en fast base-URL. Hver kopi erklærer seg dermed som originalen, og Google velger én av dem.

#Fjerner 404 eller en DNS-feil adressene fra Google

Ja, begge deler, men etter et gjenbesøk. Googles dokumentasjon om HTTP-statuskoder sier at indekserte adresser som svarer med 4xx, fjernes fra indeksen. Alle 4xx unntatt 429 behandles likt, så 404 og 410 virker på samme måte. DNS-feil, tidsavbrudd og brutte forbindelser behandles som 5xx, og DNS-veiledningen sier at indekserte adresser som ikke kan nås, fjernes fra indeksen i løpet av dager.

En kommentar i tråden ga et tall:

Google avindekserer når den ser 404-feil. Det kan ta opptil 3 måneder

(u/KindlyConnection4420, r/DoSEO, 23. oktober 2026, egen oversettelse)

Google oppgir ingen slik frist. Adressen faller ut når roboten kommer tilbake, og en lite viktig adresse på en død vert kan måtte vente en stund på det.

#Videresende det gamle subdomenet med 301

Finnes de samme artiklene på hoveddomenet, er videresending fra side til side den beste reparasjonen. Mueller nevnte den som alternativ:

Alternativt: endre DNS til å peke på et nettsted der du kan gjøre en 301-videresending av alle adresser til www, og send eventuelt inn en adresseendring i Search Console.

(u/johnmu, r/TechSEO, 23. oktober 2026, egen oversettelse)

Googles veiledning om kanonisering kaller videresending et sterkt signal om at målet skal bli kanonisk, og den tar med lenker som peker til feil vert. Navnet må slås opp og ha et gyldig sertifikat, ellers stopper roboten på TLS-feilen. Send hver adresse til sin egen tvilling, ikke alt til forsiden. Ifølge veiledningen om flytting av nettsted bør videresendingene stå minst ett år, og verktøyet for adresseendring krever minst 180 dager.

#Bekrefte og fjerne et slettet subdomene i Search Console

Mueller begynte med “bekreft via DNS” (egen oversettelse). Fjerningsverktøyet og URL-inspeksjonen virker bare for adresser i en egenskap du eier, og en vert som ikke serverer noe, kan ikke ha en HTML-bekreftelsesfil. En domeneegenskap bekreftes med en DNS-post (TXT eller CNAME) og dekker alle subdomener og protokollene http, https og ftp. Bekreft example.com som domeneegenskap, så hører ftp.example.com og staging.example.com til den, med eller uten server bak.

Fjerningsverktøyet kan så skjule alle adresser med et prefiks, for eksempel https://ftp.example.com/. Googles hjelpeside for verktøyet sier at et prefiks på staging ikke rammer www eller domenet uten www, at en godkjent forespørsel varer omtrent seks måneder, og at en forespørsel på en adresse som allerede svarer med 404 eller 502/503, får utløpe fordi Google regner siden som borte. Ifølge veiledningen om fjerning av sider virker forespørselen innen et døgn. Verktøyet skjuler bare resultater: varig blir det først med 404 eller 410, passord eller noindex. Bruk det når feil adresser skader nå. For en duplisert blogg som uansett får 301 eller 404, holder Muellers siste setning: virker ikke adressene lenger, faller de ut av seg selv (egen oversettelse).

#Er det verdt å gjøre noe hvis nettstedet er nytt

Mueller la til et alternativ som ofte blir oversett:

Hvis dette er et relativt nytt nettsted, kan du også bare la være å gjøre noe og la det ordne seg selv. Hvis adressene ikke lenger virker, faller de ut av seg selv.

(u/johnmu, r/TechSEO, 23. oktober 2026, egen oversettelse)

Det passer når den gamle verten allerede svarer med 404, 410 eller DNS-feil, nettstedet har få innkommende lenker og ingen sensitive data ligger i resultatene. Har ftp-adressene samlet lenker over flere år, mister du dem uten en 301. Har testkopien priser eller persondata, venter du ikke: da er fjerningsverktøyet riktig, sammen med en varig løsning.

#Hvilke statuser i Search Console ser du underveis

Siderapporten i domeneegenskapen viser begge vertene samtidig. Statusene under er definert i Googles dokumentasjon for siderapporten, og hver av dem sier noe konkret om hvor langt oppryddingen har kommet.

Statusnavnene står på engelsk fordi de vises slik i mange kontoer. Legg også merke til at live-testen i URL-inspeksjonen følger videresendinger og tester sluttadressen uten å si fra, ifølge samme side. Tester du en gammel ftp-adresse live, ser du resultatet for www, og det kan se ut som om videresendingen ikke gjorde noe.

#Videresender WordPress, Shopify eller Cloudflare Pages feil vertsnavn automatisk

Plattformene beskytter som regel mot én duplikat og overlater resten til deg.

WordPress videresender bare mellom www og uten www. Kildekoden til redirect_canonical() har kommentaren “Only redirect no-www <=> yes-www”, og for alle andre vertsnavn beholder funksjonen det som ble forespurt. En forespørsel til ftp.example.com får siden, ikke en videresending. Selve canonical-taggen kommer fra wp_get_canonical_url(), som kaller get_permalink() og dermed følger nettstedsadressen i innstillingene. Peker en WordPress-kopi canonical til ftp-verten, se etter WP_HOME eller WP_SITEURL bygget fra $_SERVER['HTTP_HOST'] i wp-config.php, eller en utvidelse som skriver om canonical. Avkrysningen for å fraråde søkemotorer har siden WordPress 5.3 skrevet ut en noindex-metatagg i stedet for Disallow: / i robots.txt, ifølge utviklernotatet fra kjerneteamet. Samme notat kaller en HTTP-header den mest effektive måten å holde utviklingsnettsteder ute på.

Shopify lar deg velge hvilket domene kundene ser, og videresende alle andre domener dit fra domenesiden i administrasjonen. Et ekstra domene eller subdomene uten den innstillingen er en duplisert vert.

Cloudflare Pages legger X-Robots-Tag: noindex på hver forhåndsvisning som standard. Produksjonsadressen <prosjekt>.pages.dev er en egen vert, og Cloudflares veiledning for å videresende pages.dev til eget domene bruker en Bulk Redirect med status 301, “Preserve path suffix” og “Subpath matching”, altså nettopp videresending fra side til side.

Astro bygger canonical-adresser og områdekart fra site-innstillingen i astro.config.mjs. Next.js setter sammen relative metadata-adresser, også alternates.canonical, med metadataBase, og en relativ adresse uten metadataBase gir byggefeil. I begge rammeverkene er en fast produksjonsadresse i konfigurasjonen det som hindrer at en kopi erklærer seg selv kanonisk.

#Hva gjør jeg hvis kopien ligger på et domene jeg ikke eier

Ikke alle feil verter ligger under ditt eget domene. En testkopi kan ligge på et subdomene hos et tidligere byrå eller en hostingleverandør, og da kan du verken bekrefte en domeneegenskap eller bruke fjerningsverktøyet. Googles hjelpeside for fjerningsverktøyet peker for sider du ikke kontrollerer til verktøyet for utdatert innhold. Forespørsler derfra vises hos eieren under fanen for utdatert innhold, og hjelpesiden skiller mellom to typer: finnes ikke siden lenger, fjernes resultatet fra indeksen; er bare deler av innholdet fjernet, slutter Google å vise siden for det fjernede innholdet.

Det forutsetter at kopien faktisk er borte. Svarer verten fortsatt med hele nettstedet, må den som eier domenet slette den, sette passord på den eller legge til noindex. Be om det skriftlig, med liste over adressene fra curl-sjekken, og legg ved at DNS-posten også bør slettes.

Egne forespørsler i fjerningsverktøyet kan for øvrig avbrytes fra historikken, som viser gjeldende og utløpte forespørsler for de siste seks månedene. Det er nyttig hvis du ved en feil har fjernet et prefiks som også dekker sider du vil beholde.

#Hvorfor robots.txt på den gamle verten gjør vondt verre

Googles side om noindex sier at en side som er blokkert i robots.txt, aldri hentes, så noindex-regelen blir aldri lest, og siden kan fortsatt dukke opp i resultatene. Kanoniseringsveiledningen legger til at Google kan indeksere blokkerte adresser uten innhold. La verten være tilgjengelig til 301, 404 eller noindex er lest.

#Slik får du adressene på hoveddomenet indeksert

• Bygg canonical fra en fast base-URL, så sider på www alltid oppgir www.
• Legg hoveddomenets adresser i områdekartet i produksjonsegenskapen. Google kaller det et svakt signal, men signalene virker sterkere sammen.
• Sjekk at interne lenker, hreflang og Open Graph-adresser bruker hovedverten.
• Kjør en live-test av noen www-adresser i URL-inspeksjonen og be om indeksering av de viktigste.

Kom feil vert etter et plattformbytte, tar migreringstjenesten vår og artikkelen om hvorfor Google reverserer domenemigrering for seg videresendingskartet. Guiden til Search Console og Indexing API forklarer siderapporten du følger med i.

#Hvordan hindre at test- og utviklingsverter blir indeksert

• Passord på alt som ikke er produksjon. Googles veiledning om å kontrollere hva du deler sier at passordbeskyttelse holder innhold ute av søket og etter hvert fjerner det hvis det allerede vises.
• X-Robots-Tag: noindex i HTTP-svaret. Spesifikasjonen for robots-metataggen og X-Robots-Tag tillater regelen som header, så den dekker også PDF-er og bilder. Sett den i serverkonfigurasjonen for vertsnavnet, ikke i applikasjonen, så en databasekopi fra test til produksjon ikke tar den med.
• Slett DNS-posten når verten slettes. En CNAME til en tjeneste du ikke bruker lenger, er oppskriften på overtakelse av subdomene, der en angriper tar det forlatte navnet hos leverandøren og publiserer eget innhold under subdomenet ditt.
• Unngå wildcard-DNS. Cloudflares dokumentasjon forklarer at * svarer for alle navn uten egen post. Sammen med en standardvert serverer hver skrivefeil i et subdomene nettstedet ditt.
• La standardverten avvise ukjente vertsnavn. nginx sender en forespørsel der Host ikke matcher noe server_name til standardserveren for porten, som er den første server-blokken med mindre en er merket default_server, slik veiledningen om behandling av forespørsler beskriver. Apache bruker på samme måte den første virtuelle verten i lista, ifølge dokumentasjonen om navnebaserte verter.

Et oppsett for nginx der ukjente navn møter en lukket dør og testverten har både passord og noindex:

server {
    listen 80 default_server;
    listen 443 ssl default_server;
    ssl_reject_handshake on;   # nginx 1.19.4+, avviser TLS for ukjente navn
    return 444;                # lukker forbindelsen uten svar
}

server {
    listen 443 ssl;
    server_name staging.example.com;
    # ssl_certificate og ssl_certificate_key for dette navnet her
    auth_basic "Staging";
    auth_basic_user_file /etc/nginx/.htpasswd;
    add_header X-Robots-Tag "noindex" always;
}

Parameteren always er viktig. Dokumentasjonen for headers-modulen sier at add_header bare gjelder svar med 200, 201, 204, 206, 301, 302, 303, 304, 307 og 308 hvis ikke always er satt, så uten den går 401-svaret fra passordbeskyttelsen ut uten noindex. ssl_reject_handshake krever nginx 1.19.4 eller nyere, og kode 444 er nginx sin egen måte å lukke forbindelsen på.

#Rekkefølgen i praksis, steg for steg

1. Kjør dig og curl -sI mot fem til ti adresser som Google viser, og noter hva hver av dem svarer.
2. Legg til TXT- eller CNAME-posten for domeneegenskapen hos DNS-leverandøren og bekreft eiendomsretten i Search Console.
3. Åpne siderapporten og filtrer på den gamle verten, så du vet hvor mange adresser det gjelder.
4. Velg rad i beslutningstabellen øverst: 301, 404/410 eller DNS-feil.
5. Ligger det sensitivt innhold i resultatene, send en prefiksfjerning for hele verten samme dag.
6. Rett canonical-basen og områdekartet på produksjon, og be om indeksering for de viktigste www-adressene.
7. Slett DNS-poster som peker til tjenester du ikke bruker, og innfør passord og noindex-header på alle testverter.
8. Følg med på statusene i siderapporten. Videresendingene skal stå i minst ett år, ifølge veiledningen om flytting av nettsted. Har du sendt inn en adresseendring, krever verktøyet i tillegg minst 180 dager.

Serveroppsettet for passord og noindex-header finner du i guiden til staging-arbeidsflyt. En nettstedsjekk går gjennom DNS-poster og indekserte vertsnavn, og løpende vedlikehold holder listen oppdatert etter hvert server- eller byråbytte.