Sådan undgår du at falde i Google efter en ny hjemmeside

Annonce – sponsoreret indhold.

Hvis du er faldet i Google efter ny hjemmeside, skyldes det som regel tekniske fejl i omlægningen og sjældent selve designet: gamle adresser, der ikke peger videre til de nye, URL’er, der er ændret uden plan, metadata, der er forsvundet, eller en side, der stadig er blokeret for Google. Fejlene kan forebygges, hvis SEO indgår i projektet fra kravspecifikationen og ikke først efter go-live. Her får du en guide i den rækkefølge, du skal handle i.

Hvad der sker, når du er faldet i Google efter ny hjemmeside

Google kender din gamle hjemmeside som en samling adresser med en historik: links fra andre sites, interne henvisninger, brugersignaler og et indhold, som algoritmen har vurderet over tid. Når du lancerer en ny platform, ser Google en ny samling adresser. Hvis du ikke fortæller, hvordan de gamle hænger sammen med de nye, skal Google genopbygge sin forståelse fra bunden. Imens kan placeringerne glide, og trafikken falder.

Et midlertidigt udsving er normalt, fordi Google skal gennemløbe og vurdere siderne igen. Et vedvarende fald peger næsten altid på en konkret fejl, som kan findes og rettes. Det er den forskel, du skal lære at se.

Mange migreringer går galt, fordi ansvaret er delt. Udviklerne leverer en teknisk korrekt platform, designeren leverer et flot udtryk, og ingen har ansvaret for, at søgesynligheden overlever flytningen. Derfor er det klogt at inddrage en Google ekspert tidligt i projektet. Vedkommende kan se, hvilke sider der driver trafik, og hvilke tekniske valg der kan koste placeringer. Det er langt billigere at indtænke det i kravspecifikationen end at rydde op efter lanceringen.

Det gælder uanset om du skifter CMS, går fra skræddersyet løsning til standardplatform, migrerer webshop eller bare laver et redesign. I alle tilfælde er den tekniske omlægning også en SEO-omlægning. Læs gerne mere om det større billede i Digital transformation: Hvad betyder det for din virksomhed, hvor en ny hjemmeside ofte er ét led i en bredere forandring.

De fem tekniske fejl, der oftest koster placeringer

1. Manglende eller forkerte 301-redirects

Den hyppigste årsag til et fald. Når en URL ændres eller fjernes, skal den gamle adresse sende besøgende og Google videre med en 301-redirect til den nye, mest relevante side. Uden den ender brugeren på en 404-side, og de links og den autoritet, den gamle side havde opbygget, mister værdi.

Typiske fejl i praksis:

• Alt sendes til forsiden. Det er en genvej, der ofte opfattes som en dårlig match. Redirecten skal pege på en side med tilsvarende indhold.
• Redirect-kæder. Gammel URL peger på en mellemadresse, som peger på den endelige. Hvert led sinker og svækker signalet.
• 302 i stedet for 301. En midlertidig redirect fortæller, at flytningen ikke er permanent.
• Glemte sider. Gamle blogindlæg, kategorisider, PDF-filer og billeder, som stadig har eksterne links eller trafik.

2. Ændret URL-struktur uden plan

Et nyt system har ofte sin egen logik for adresser: andre mappestier, filendelser, parametre eller sprogstruktur. Hvis /ydelser/seo pludselig bliver til /services/seo-optimering, er det en ny side i Googles øjne. Hold URL-strukturen så uændret som muligt for de sider, der performer. Hvis strukturen skal ændres, skal hver ændring dokumenteres i et redirect-kort. Vær også opmærksom på små forskelle som med eller uden efterfølgende skråstreg, store og små bogstaver, og www eller ikke-www. Alle varianter skal samle sig på én kanonisk version.

3. Mistet metadata og tilpasset indhold

Ved migrering mellem systemer følger title-tags og meta descriptions ikke altid med. Ofte bliver de erstattet af standardskabeloner som “Hjem – Firmanavn”. Det samme gælder overskriftsstruktur (H1-H3), alternative billedtekster, strukturerede data og interne links. Hvis du samtidig skærer tekst ned af designhensyn, kan en side miste netop de ord, den rangerede på.

Eksportér metadata og indhold fra den gamle side før migreringen, og kontrollér, at det er indlæst korrekt i den nye. Det kan gøres med et crawl-værktøj og en simpel sammenligning.

4. Noindex og robots.txt fra staging

Et staging-miljø bør være lukket for søgemaskiner, typisk med noindex eller en blokering i robots.txt. Problemet opstår, når disse indstillinger følger med til produktion. Resultatet er en flot ny side, som Google får besked på ikke at vise. Det er en klassiker, og den er let at undgå, hvis den står på go-live-listen.

5. Brudt intern linking, canonical og sitemap

Interne links, der peger på gamle adresser, tvinger Google gennem redirects på hver eneste side. Forkerte canonical-tags kan fortælle Google, at en helt anden URL er den rigtige. Et forældet XML-sitemap med gamle adresser sender modstridende signaler. Alle tre skal opdateres, så de kun indeholder de nye, endelige URL’er, der svarer med statuskode 200.

Langsom genindeksering: hvad du kan forvente

Selv med en perfekt migrering tager det tid, før Google har gennemløbet alle sider igen. Hvor lang tid afhænger af sidens størrelse, hvor ofte Google normalt besøger den, og hvor ren den tekniske opsætning er. Du kan ikke give et sikkert tal på forhånd, og det bør du heller ikke love ledelsen. Det, du kan gøre, er at gøre Googles arbejde så let som muligt:

• Indsend det nye sitemap i Google Search Console, så Google kender de nye adresser med det samme.
• Brug rapporten Sideindeksering til at se, hvilke sider der er indekseret, og hvilke der er udelukket, og hvorfor.
• Brug URL-inspektion på vigtige sider for at bede om genindeksering og se, hvordan Google faktisk ser siden.
• Brug værktøjet til adresseændring i Search Console, hvis du samtidig skifter domæne.
• Behold den gamle Search Console-ejendom og opret den nye, så du kan sammenligne før og efter.

Når du skifter domæne, skal redirects fra det gamle domæne holdes aktive længe efter lanceringen. Gamle links rundt om på nettet peger stadig dertil, og det skal de blive ved med at kunne.

Tjekliste før go-live

Brug listen som fast punkt i projektplanen, og giv hver opgave en ansvarlig. Den følger den rækkefølge, du bør arbejde i.

Før udviklingen er færdig

1. Crawl den eksisterende side og gem en komplet liste over URL’er, statuskoder, titles, meta descriptions, overskrifter og interne links.
2. Udtræk data fra Search Console og analytics: hvilke sider får trafik, hvilke søgeord og hvilke konverteringer. Disse sider er højeste prioritet.
3. Hent eksterne links og se, hvilke sider der har flest. De må aldrig give 404.
4. Lav redirect-kortet med én gammel URL pr. linje og den tilsvarende nye URL.

På staging-miljøet

5. Test redirects i bulk, og kontrollér, at de giver 301 og lander direkte på slutadressen.
6. Kontrollér metadata, overskrifter, canonical-tags og strukturerede data på de vigtigste sidetyper.
7. Test hastighed og mobilvisning. Mål Core Web Vitals på centrale skabeloner, så du ikke lancerer en langsommere side end den gamle.
8. Tjek, at indhold er tilgængeligt for Google. Hvis siden er bygget med meget JavaScript, skal vigtigt indhold og links kunne ses i den renderede HTML.

På lanceringsdagen

9. Fjern noindex og robots.txt-blokeringer, og bekræft, at robots.txt tillader gennemløb.
10. Aktivér redirects, og stikprøvetest de vigtigste adresser.
11. Indsend det nye sitemap og verificér Search Console og analytics på det nye setup.
12. Kontrollér sporing: at konverteringer, formularer og køb registreres korrekt.
13. Opdatér interne links, så de peger direkte på de nye URL’er.

Vælg gerne et tidspunkt for lancering, hvor der er mindst forretningsrisiko, og hvor udviklerne er tilgængelige i dagene efter. Lancering på en fredag eftermiddag uden beredskab er en dårlig idé.

De første uger efter lanceringen

Arbejdet stopper ikke, når siden er live. De første uger er den periode, hvor små fejl kan nå at blive til store tab, hvis ingen holder øje.

• Tjek 404-fejl i Search Console og i serverlogs. Adresser med eksterne links eller trafik skal have en redirect med det samme.
• Følg de vigtigste søgeord og landingssider og sammenlign med tallene fra før lanceringen. Sammenlign på samme ugedage og med hensyn til sæson.
• Crawl den nye side igen og kig efter redirect-kæder, manglende titles, dublerede sider og blokerede ressourcer.
• Gennemgå Sideindeksering for sider, der udelukkes, selv om de skal være med.
• Hold gamle redirects i drift. Fjern dem ikke, fordi de virker “rodede” i konfigurationen.

Skil gerne rigtige problemer fra almindelig støj. Hvis forsiden og kerneydelser mister placeringer og bliver væk fra indekset, er der en teknisk årsag. Hvis lange-hale-sider svinger lidt, er det ofte en del af Googles genvurdering. Vær også opmærksom på, at et redesign, der ændrer sidens tekst og struktur markant, kan ændre rangeringen uden at noget er “gået i stykker”. Her handler det om indholdet.

Sådan samarbejder udviklere og SEO i praksis

De fleste problemer skyldes manglende samarbejde, ikke manglende viden. Få SEO-kravene skrevet ind i projektet på samme niveau som funktionelle krav. Det betyder redirect-krav i kravspecifikationen, definerede URL-regler, felter til metadata i CMS’et og en acceptprøve, som SEO-ansvarlig skal godkende, før lanceringen frigives. Hvis du arbejder agilt, kan SEO-checks indgå i “definition of done” for relevante tickets.

Mange virksomheder vælger at supplere internt med specialister, fordi migreringer er en sjælden, men kritisk opgave. Det er en af grundene til, at flere tech-virksomheder søger ekstern hjælp, som du kan læse mere om i Derfor vælger tech-virksomheder ekstern SEO-hjælp i 2026. Uanset model er pointen den samme: Nogen skal have eksplicit ansvar for, at søgesynligheden overlever flytningen.

Ofte stillede spørgsmål

Er det normalt at falde i Google efter en ny hjemmeside?

Mindre udsving i den første periode er almindelige, fordi Google skal gennemløbe og vurdere siderne igen. Et markant og vedvarende fald er derimod et tegn på en teknisk fejl eller en stor ændring i indholdet, og det bør undersøges med det samme i Search Console og et nyt crawl.

Hvor lang tid tager det, før placeringerne er tilbage?

Det afhænger af sidens størrelse, kvaliteten af redirects og hvor mange ændringer der er lavet. Der findes ingen garanteret tidsramme. Hvis migreringen er rent udført, kommer placeringerne typisk gradvist tilbage. Hvis der er fejl, kommer de først tilbage, når fejlene er rettet.

Skal jeg lave redirects for alle gamle sider?

Prioritér sider med trafik, placeringer, konverteringer eller eksterne links. Sider uden værdi og uden et naturligt modstykke kan returnere 404 eller 410. Men hvis der findes en relevant erstatning, er en 301-redirect næsten altid den bedste løsning.

Kan jeg rette fejlene efter lanceringen?

Ja, og det bør du gøre hurtigt. Indfør manglende redirects, ret metadata, fjern fejlagtig noindex og indsend sitemap igen. Jo længere fejlene får lov at stå, jo længere tid tager det at genvinde placeringerne, så overvågning i dagene efter lanceringen er afgørende.