SEO-migrering: URL-karta, kontroll och säker lansering

Varför en WordPress-till-Astro-migrering kräver mer än ett plattformsbyte

Att flytta en webbplats från WordPress till Astro är inte primärt ett tekniskt problem – det är ett kartläggningsproblem. Plattformarna skiljer sig i hur de genererar URL-strukturer, hanterar metadata, skickar e-post och exponerar API-ytor. Det som fungerade tyst i bakgrunden på WordPress, exempelvis ett plugin som skötte transaktionella mejl eller en .htaccess-regel som normaliserade slash-hantering, måste nu vara ett medvetet designval i den nya miljön.

Den vanligaste felkällan vid den här typen av migrering är inte att teamet saknar kompetens – det är att de hoppar direkt från export till implementation utan att bygga ett beslutsunderlag. Resultatet är en redirect-karta med luckor, en staging-miljö som aldrig validerats mot produktionsbeteendet, och en lansering utan definierade rollback-kriterier. Det är inte en osannolik sekvens: det är den normala sekvensen när projektets tidspress är högre än dess riskmedvetenhet.

Den här guiden behandlar hela kedjan: inventering och klassificering av URLs, redirect-karta med testmatris, staging-konfiguration, preflight-kontroll och en rollback-plan med konkreta triggervärden. Om du redan arbetar med teknisk SEO som en löpande disciplin är migreringen ett tillfälle att städa och dokumentera det som annars förblir implicit. Om du gör det i ett engångsprojekt är strukturen nedan det minimum som gör utgången förutsägbar.

Steg ett: inventering som beslutsunderlag, inte exportlista

Det första misstaget är att behandla sitemap-exporten som en färdig URL-karta. En sitemap listar de URLs webbplatsen vill visa upp – den listar inte parameterbaserade arkivsidor, paginering, äldre slugs som ändrades utan redirect, eller admin-ytor som råkat indexeras. En komplett inventering kräver tre datakällor i kombination: sitemap-export, crawl av live-sajten med ett verktyg som Screaming Frog eller liknande, och en loggfils-analys om du har tillgång till serverloggar från de senaste 90 dagarna.

När du har sammanställt listan ska varje URL tilldelas en av fyra dispositioner:

• BEHÅLL – URL:en lever vidare med samma eller justerad sökväg i Astro.
• OMDIRIGERA – URL:en har historiskt värde (trafik, inkommande länkar) och ska peka till en ny ekvivalent sida via 301.
• KONSOLIDERA – Flera URL:er täcker samma ämne; välj en kanonisk destination och redirecta övriga dit.
• RADERA – URL:en saknar historiskt värde och inga kända inkommande referenser; låt den returnera 404 utan redirect.

Motivering ska dokumenteras per rad, inte per kategori. Om du kan öppna kartan om sex månader och förstå varför en specifik URL fick dispositionen RADERA har du en användbar artefakt. Om du bara har kategorisumman har du en summarisk lista.

En dimension som ofta förbises i URL-inventeringen är bilder och mediafiler. WordPress lagrar uppladdade bilder under /wp-content/uploads/ med en hierarki baserad på uppladdningsdatum. Om dessa bilder refereras i externa sammanhang – inbäddade på andra sajter, länkade i nyhetsbrev, indexerade med alt-text i bildsökning – behöver du antingen bevara sökvägarna eller redirecta dem. Det är sällan värt att redirecta varje enskild bildfil, men det är värt att inventera vilka bildsökvägar som faktiskt finns i externa inkommande länkar.

RANGELs beslutsträ för URL-disposition och redirect-kedjor

Nedan är RANGELs operativa ramverk för att fatta URL-beslut systematiskt. Det är inte en generisk checklista – det är ett beslutsträd som ger olika utfall beroende på kombinationen av tre faktorer: historisk trafik (har sidan fått organiska besök de senaste 12 månaderna?), inkommande externa länkar (finns det en eller fler externa domäner som pekar hit?), och innehållsrelevans (motsvarar sidans ämne något som ska finnas i den nya sajten?).

Beslutstabellen är ett arbetsverktyg, inte ett facit. Det finns gränsfall: en sida med noll trafik men med en mycket stark extern länk från en auktoritativ domän kräver en annan bedömning än en sida med en länk från en glömd katalog. Använd tabellen för att strukturera diskussionen, inte för att automatisera bort omdömet.

Redirect-kartan: format, kedjor och det konkreta testproblemet

En redirect-karta är ett strukturerat dokument – vanligen ett kalkylblad eller en CSV – med kolumnerna: gammal URL, ny URL, HTTP-statuskod, status (testad/ej testad) och kommentar. Varje rad är en mappning som ska implementeras och sedan verifieras.

Ett fel att undvika i redirect-kartor är kedjebildning: gammal URL pekar till mellanliggande URL som pekar till slutlig URL. Crawlers och webbläsare följer kedjor, men varje hopp adderar latens och introducerar en ny felkälla. Sträva efter att varje gammal URL redirectas direkt till slutdestinationen i ett enda hopp. Om din WordPress-sajt redan har interna redirectar måste du lösa upp dem i den nya kartan – det räcker inte att repetera den gamla kedjan i en ny config.

Här är ett konkret format för en Astro-sajt som hanterar redirects i astro.config.mjs:

// astro.config.mjs (illustrativt utdrag)
export default defineConfig({
  redirects: {
    '/gamla-tjanster/webbdesign': '/tjanster/webbdesign',
    '/blogg/2021/01/seo-tips': '/guider/seo-checklista',
    '/om-oss/team': '/om-oss',
  }
});

Astro genererar 301-redirectar av dessa mappningar i statiskt läge. Om du använder on-demand rendering – vilket är relevant att förstå för mer komplexa sajter, se Astros dokumentation om on-demand rendering för hur serverrutter hanteras – kan du istället implementera redirects i middleware eller edge-funktioner, vilket ger mer kontroll men också mer att testa.

301 och 308 är permanenta HTTP-redirects; 308 bevarar metod och kropp, vilket innebär att en POST-förfrågan förblir POST efter omdirigeringen. För vanliga GET-anrop från crawlers och webbläsare är skillnaden utan praktisk betydelse. Välj 308 specifikt när du migrerar en slutpunkt som tar emot POST-data, exempelvis ett formulär eller ett webhook-anrop.

Testmatris: verifiera varje redirect mot staging

En redirect-karta som inte testats är en hypotes. Testmatrisen är den systematiska verifieringen av att varje hypotes håller. Matrisen ska köras mot staging-miljön innan du rör DNS, och den ska upprepas mot produktionen i de första timmarna efter lansering.

För varje rad i redirect-kartan ska du verifiera tre saker:

1. Statuskod på gammal URL: Returnerar rätt HTTP-statuskod (301 eller 308). Inte 302, inte 200, inte 404.
2. Destination utan kedja: Följ redirecten med curl -L --max-redirs 1 och kontrollera att destinationen returnerar 200 i ett enda hopp. Om du behöver fler hopp finns en kedja att lösa upp.
3. Inga loopar: Kör curl -L --max-redirs 5 och kontrollera att du inte fastnar i en cyklisk redirect. En loop ger ett curl-fel om maxgränsen nås.

För en sajt med upp till några hundra URLs kan du köra detta manuellt med ett skript. För större sajter är ett crawlverktyg effektivare. Dokumentera resultaten i testmatrisen med kolumnerna: URL, förväntad kod, faktisk kod, destination, kedjehoppar, godkänd (ja/nej).

Staging-konfiguration: noindex, canonicals och den kritiska skillnaden

Staging-miljön ska aldrig indexeras av sökmotorer. Det låter självklart men implementeras ofta fel. Det finns två vanliga misstag: antingen blockeras staging via robots.txt men inte via HTTP-header eller meta-robots (vilket ger inkonsekvent beteende beroende på hur crawlern hanterar robots.txt), eller så skyddas staging med HTTP Basic Auth utan att teamet kontrollerar att auth-väggen faktiskt hindrar crawlning och inte bara mänsklig åtkomst.

Rätt konfiguration för en Astro-staging-miljö kombinerar:

• En robots.txt med Disallow: / för alla user-agents.
• En X-Robots-Tag: noindex HTTP-header på alla sidor, satt i middleware eller hosting-config.
• En explicit meta-robots-tagg i <head> med content="noindex,nofollow".

Canonical-taggar på staging ska peka på produktions-URL:en – inte på staging-domänen. Det är en separat kontroll från noindex. Noindex är en direktiv som instruerar sökmotorn att inte indexera sidan; canonical är en preferenssignal som anger den auktoritativa URL:en om sidan ändå crawlas. De löser olika problem och kan inte ersätta varandra. Läs mer om hur canonical-logiken fungerar i relation till indexering i guiden om canonical, robots och indexering.

Verifiera staging-konfigurationen genom att manuellt hämta HTTP-headers med curl och läsa källkoden på en representativ staging-sida. Lita inte på att konfigurationen är rätt för att du satte en flagga i ett deploymentskript – verifiera att flaggan faktiskt genererar rätt output i den körda appen.

E-postflöden och dashboardåtkomst: det som försvinner tyst

WordPress hanterar transaktionella e-postmeddelanden via wp-mail.php och plugins som Contact Form 7, Gravity Forms, WooCommerce, eller ett SMTP-plugin kopplat till en extern e-posttjänst. När WordPress tas bort försvinner alla dessa mekanismer utan att ge ett tydligt felmeddelande – de slutar helt enkelt fungera.

Inventera alla e-postflöden som webbplatsen genererar:

• Kontaktformulär och deras mottagaradresser.
• Beställningsbekräftelser och notifikationer om du kör e-handel.
• Användarregistrering och lösenordsåterställning om sajten har konton.
• Automatiska notifikationer till administratörer vid nya inlägg eller kommentarer.

För varje flöde: identifiera den nya mekanismen i Astro-sajten. Det kan vara ett fristående formulär-API (Netlify Forms, Formspree, ett eget serverless-anrop), en e-posttjänst med API (Resend, Postmark, SendGrid) eller en webhook mot ett externt system. Testa varje flöde i staging innan lansering och bekräfta att rätt e-postadress tar emot rätt meddelande med rätt innehåll.

Dashboard-åtkomst är en annan tyst förändring. WordPress admin-panel på /wp-admin försvinner. Om kunden eller interna användare är vana att logga in där för att uppdatera innehåll måste du identifiera motsvarigheten i Astro – exempelvis ett headless CMS, ett Git-baserat redigeringsflöde eller ett annat administrationsverktyg – och utbilda användarna innan sajten går live. En migrering som tekniskt fungerar men lämnar redaktörerna utan tillgång till att uppdatera innehåll är inte slutförd.

SEO-migrering: URL-karta, kontroll och säker lansering
https://rangel.se/guider/seo-migrering/

LÄSARUPPGIFT
Exportera alla publicerade URL:er från din WordPress-sajt och skapa en redirect-karta som kopplar varje gammal URL till sin nya destination.

Förbered en verifierbar webbplatsflytt
[ ] Bygg URL-kartan
Underlag att dokumentera: Matcha viktiga gamla URL:er mot motiverade nya destinationer.
Mitt underlag:
Ansvarig / nästa steg:

[ ] Testa redirects och metadata
Underlag att dokumentera: Spara statuskedja, canonical och innehåll för varje prioriterad URL.
Mitt underlag:
Ansvarig / nästa steg:

[ ] Sätt rollback och uppföljning
Underlag att dokumentera: Ange ansvar, stoppvillkor och jämförbara mätningar efter flytt.
Mitt underlag:
Ansvarig / nästa steg:

Markeringarna är dina egna arbetsnoteringar, inte en granskning av RANGEL eller ett kvalitets-/rankingbetyg.

Illustrativt typfall: flytt av en B2B-tjänstesajt

Följande är ett hypotetiskt typfall baserat på en vanlig konfiguration. Alla siffror och val är illustrativa och har explicita antaganden.

Scenario: Ett illustrativt B2B-företag, Nordtek AB (fiktivt), driver en WordPress-sajt med 85 publicerade sidor, ett kontaktformulär, en söksida och en nyhetsarkiv-struktur med paginering. De migrerar till Astro med statisk generering och ett headless CMS för nyheter.

URL-inventering: Crawlen returnerar 142 unika URLs inklusive pagineringssidor (/nyheter/page/2/ etc.), parametervarianter (?replytocom=123) och admin-ytor som råkat indexeras. Efter klassificering: 61 URL:er får disposition BEHÅLL (varav 12 får ny slug), 18 URL:er får OMDIRIGERA, 8 URL:er konsolideras till 3 kanoniska sidor, och 55 URL:er (paginering, parametervarianter, admin) raderas utan redirect.

Redirect-kartan innehåller 30 rader (12 slug-ändringar + 18 externa omdirigeringar). Testmatrisen körs med ett shellskript mot staging. Av 30 rader misslyckas 3: en catch-all-regel i Astros redirect-config fångar upp två URL:er som borde returnera 404, och en redirect-kedja på tre hopp identifieras (gammal WordPress-redirect som upprepats i ny config). Alla tre åtgärdas och matrisen körs om.

E-postflöden: Kontaktformuläret migreras till Netlify Forms med en e-postnotifikation till info@nordtek.se. Testet i staging bekräftar att meddelandet anländer korrekt. Inga användarregistreringsflöden finns. CMS-notifikationer konfigureras direkt i det headless CMS:et.

Observation efter lansering (antagande: 30 dagar med noggrant underhåll): Inga garanterade trafikutfall anges – detta är inte ett löfte utan ett illustrativt exempel på vad noggrann process ger förutsättningar för. Det som är mätbart direkt: 0 brutna redirect-kedjor i Coverage-rapporten, 0 oavsiktligt indexerade staging-URL:er, alla kontaktformulärsinlämningar anländer korrekt.

Preflight-checklist: 24 timmar före DNS-byte

Preflight är den sista samlade kontrollen innan du gör den förändring som inte kan ångras utan kostsamma åtgärder. Genomför den med minst två personer och dokumentera resultaten med tidsstämpel.

1. Bekräfta att staging-testmatrisen är godkänd (alla rader, inga öppna fel).
2. Bekräfta att staging har korrekt noindex-konfiguration (verifiera med curl på minst fem URL:er).
3. Bekräfta att produktions-Astro-instansen genererar rätt canonicals (verifiera källkoden på minst fem URL:er).
4. Bekräfta att alla e-postflöden är testade och bekräftade i staging.
5. Bekräfta att DNS TTL är sänkt till 300 sekunder minst 24 timmar i förväg (underlättar rollback).
6. Bekräfta att det gamla WordPress-hotellet är kvar och aktivt (inte avvecklat) och kan reaktiveras vid behov.
7. Bekräfta att rollback-proceduren är dokumenterad med konkreta triggervärden (se nästa kapitel).
8. Bekräfta att interna länkar i den nya sajten är uppdaterade och inte pekar på gamla WordPress-URL:er. Se guiden om interna länkar för principer om hur intern länkstruktur bör byggas.
9. Bekräfta att strukturerad data är implementerad korrekt om den fanns på den gamla sajten. Hur strukturerad data ska hanteras vid migrering beskrivs i guiden om strukturerad data; ett kompletterande perspektiv på schema-specifikationen finns hos Schema.org: Article.
10. Bekräfta att JavaScript-beroenden för SEO-kritiska sidor är testade. Astro levererar som standard statisk HTML, men om du använder Islands-arkitektur med klientrendering är det värt att granska JavaScript SEO-perspektiven.

Rollback: definition, triggervärden och procedur

Rollback är inte en plan du lägger upp om något går fel – det är en plan du har redo innan du gör det som kan gå fel. Skillnaden är inte semantisk: en improviserad rollback under press tar längre tid, fattar sämre beslut och dokumenteras inte. En förberedd rollback är en checklist som vem som helst i teamet kan köra.

Definiera konkreta triggervärden för rollback innan lansering. Triggervärden är observerbara, inte subjektiva. Exempel på triggervärden med tydliga antaganden:

• Fler än X procent av de testade redirect-URL:erna returnerar fel HTTP-statuskod inom 2 timmar efter DNS-propagation (sätt X baserat på hur många fel du bedömer som acceptabelt – noll är rimligt för en liten sajt).
• Kontaktformulär levererar inte e-post efter bekräftad inlämning.
• En eller fler sidor som ska returnera 200 returnerar 500 eller 404 utan förklaring.
• Staging-URL:er dyker upp i indexeringsverktyg (indikerar att noindex-konfigurationen inte fungerade som förväntat).

Rollback-proceduren för en WordPress-till-Astro-migrering är i princip: peka om DNS till det gamla WordPress-hotellet. Det förutsätter att WordPress-instansen är orörd och aktiv. Avveckla inte WordPress-hostingen förrän du är säker på att den nya sajten fungerar stabilt – minst två veckor efter lansering är en rimlig tumregel, men sätt din egen gräns baserad på riskbedömning.

Om du vill strukturera ett affärscase för migreringen innan du startar projektet kan verktyget SEO-affärscase hjälpa dig att räkna på illustrativa scenarier med dina egna antaganden på ett sätt som är kommunicerbart med beslutsfattare. Verktyget gör transparent aritmetik på de värden du matar in – det är inte en kommersiell prognos.

Om utgångsläget är WordPress kan du först dokumentera vad temat och tilläggen faktiskt levererar. Vid flytten får journalen för brutna länkar fånga källsida, destination och omtest efter URL-ändringar.

Övervakning efter lansering: vad du tittar på och varför

De första 14 dagarna efter en migrering är en observationsperiod, inte en bekräftelse på att allt fungerar. Indexeringseffekter tar tid att materialiseras och felsignaler är inte alltid omedelbara. Det du kan observera direkt är tekniska signaler: HTTP-svar, crawl-täckning och formulärfunktion. Det du inte kan observera direkt är rankingeffekter – de är beroende av crawlfrekvens, indexeringsprioritet och faktorer utanför din kontroll.

Konkreta observationspunkter de första dagarna:

• Granska HTTP-statuskoder för alla primära URL:er med ett crawlverktyg. Alla förväntade 200-sidor ska returnera 200; inga oavsiktliga 301-kedjor ska finnas.
• Kontrollera att inga staging-URL:er har indexerats. Google Search Console mäter Googles sökindex – använd URL-inspektionsverktyget där för att kontrollera om staging-URL:er förekommer i Googles index.
• Verifiera att sitemap.xml på produktionsdomänen är korrekt genererad och innehåller rätt URL:er.
• Testa kontaktformulär och andra interaktiva element manuellt från en extern anslutning.
• Granska serverloggar eller hosting-analytics för ovanliga 404-mönster som kan indikera brutna interna eller externa länkar.

För att strukturera den löpande tekniska granskningen kan SEO-checklistan ge ett ramverk för vad som är värt att kontrollera regelbundet, inte bara vid migreringen.

Diagnoslogiken är enkel: om du ser oväntade 404:or, identifiera källan (intern länk, extern referens eller direct-URL) och avgör om det kräver en ny redirect-rad eller en länkkorrigering. Om du ser oväntade 301:or, spåra kedjan och förkorta den. Om du ser staging-URL:er i indexet, granska noindex-konfigurationen omedelbart och begär borttagning via Search Console.

En migrering är slutförd när alla definierade preflight-kriterier är uppfyllda, testmatrisen är godkänd och övervakningsperioden inte har genererat några öppna tekniska fel. Det är ett hanterbart mål – inte ett perfekt tillstånd, men ett tillstånd där du vet vad som fungerar, vad som inte fungerar och vad du ska göra åt det.