Brutna länkar: hitta källan, välj åtgärd och testa igen

Varför HTTP-statuskoden är din startpunkt, inte slutpunkten

Det vanligaste misstaget när man hanterar brutna länkar är att behandla alla fel som identiska: en länk pekar fel, man redirectar den, problemet är löst. Verkligheten är mer nyanserad. En 404 uppstår när servern aktivt svarar att resursen inte finns. En 410 kommunicerar att resursen är permanent borttagen och avsiktligt inte längre tillgänglig. En 5xx innebär att servern misslyckades med att hantera förfrågan, oavsett om resursen existerar. En 403 betyder att servern förstår förfrågan men nekar att utföra den. En timeout ger ingen statuskod alls och kan bero på allt från brandväggsregler till överlastade ursprungsservrar. En redirect-kedja returnerar tekniskt 200 vid slutdestinationen, men varje extra hopp är en potentiell felpunkt och en signal om att länkarkitekturen aldrig städades upp efter en migrering.

Det finns också det trasiga fragmentet: en URL som returnerar 200 men vars ankare, till exempel #avsnitt-3, inte existerar på sidan. Crawlers flaggar inte alltid detta automatiskt eftersom HTTP-svaret är framgångsrikt. Ändå hamnar besökaren mitt på sidan utan det utlovade kontextuella stödet. Fragmentfel är vanligast efter innehållsredigeringar där rubriker byter text och ID ändras utan att interna länkar uppdateras.

Att förstå distinktionen mellan dessa feltyper är inte akademisk noggrannhet utan direkt praktisk nödvändighet. Om du redirect-löser en 403 har du inte fixat felet, du har bara gömt det. Om du tar bort länken till en 410-sida som fortfarande har inkommande externa länkar förlorar du möjligheten att med en 301 leda det länkvärdet till en relevant ersättningssida. Åtgärden måste matcha diagnosen.

Verktygsval och vad en crawler faktiskt mäter

Innan du börjar samla data är det viktigt att förstå vad ditt verktyg faktiskt gör. Screaming Frogs crawler kan visa felstatus och vilka sidor som länkar till dem, vilket gör den till ett naturligt startval för länkdiagnos. Det är en viktig distinktion: crawlern skickar HTTP-förfrågningar och registrerar svaret, den läser inte din källkod och gissar sig fram.

RANGELs eget verktyg för HTML-kontroll arbetar på ett annat plan. Det granskar markup och länkstruktur i den HTML du matar in lokalt, men skickar inte nätverksförfrågningar. Det kan identifiera att en href finns och hur ankartexten är formulerad, men kan inte bekräfta att destinationen svarar med 200. För statuskontroll är en faktisk crawler nödvändig.

Screaming Frog erbjuder en dedikerad guide för broken link checking med detaljer om hur du konfigurerar crawlen för specifika feltyper. Var uppmärksam på ett par konfigurationsval som påverkar resultaten: om du crawlar med JavaScript-rendering aktiverat hanterar verktyget dynamiskt genererade länkar som annars är osynliga i källkoden, vilket är särskilt relevant om din sajt är byggd med ett modernt JavaScript-ramverk. Mer om det finns i vår guide om JavaScript SEO och läsbar HTML.

En annan faktor som snedvrider crawlresultat är cache. Om du testar en URL som nyligen redirectades och CDN:et fortfarande serverar den gamla destinationen, registrerar crawlern den gamla statuskoden. Töm CDN-cache för berörda URL:er innan du crawlar om efter en åtgärd, annars riskerar du att markera åtgärdade fel som kvarstående.

Bygg journalen: fem kolumner som håller ordning

Den operativa kärnan i länkarbetet är inte crawlverktyget utan journalen du bygger av exportdata. En fungerande journal behöver exakt fem kolumner för att vara handlingsbar utan att bli onödigt komplex.

Kolumn ett är käll-URL: den sida där den brutna länken finns. Det är här åtgärden ofta genomförs, eftersom du redigerar länken i källsidans innehåll snarare än att skapa något på destinationssidan.

Kolumn två är href: den exakta URL som länken pekar mot, inklusive fragment om sådant finns. Notera att en href kan vara relativ i källkoden men absolut i crawlrapporten. Du vill ha den absoluta varianten i journalen.

Kolumn tre är observerad HTTP-status: den faktiska statuskod crawlern returnerade, eller notering om timeout om ingen statuskod returnerades. Skriv aldrig bara "bruten" här utan den faktiska siffran.

Kolumn fyra är vald åtgärd: ett av fyra alternativ som vi definierar nedan. Åtgärden väljs efter en bedömning som inkluderar statuskod, om sidan har externa inkommande länkar och var länken befinner sig i din struktur.

Kolumn fem är omtestat: datum och utfall för det manuella omtestet efter att åtgärden genomfördes. Innan omtestet är markerat klart är ärendet öppet, oavsett vad du tror att du har gjort.

Nedan visas ett illustrativt exempel med fem rader från en hypotetisk sajt inom B2B-tjänster. Alla URL:er och data är fingerade för att visa hur journalen fungerar i praktiken.

Notera att journalen inte innehåller gissningar om hur lång tid åtgärden tar eller hur stor effekten blir. Den dokumenterar fakta, beslut och verifiering. Det är det som gör den användbar som arbetsunderlag snarare än ett statusdokument som förlorar relevans dagen efter det skapades.

RANGELs feljournal och beslutsmatris för HTTP-statuskoder

Det centrala redskapet i RANGELs arbetsmetod är beslutsmatrisen: en systematisk koppling mellan observerad statuskod, tillgänglig information om sidan och den åtgärd som följer. Matrisen är inte ett löfte om utfall utan ett resonerat beslutsunderlag som gör att du kan hantera hundra brutna länkar konsekvent snarare än att avgöra varje fall intuitivt.

Matrisen bygger på tre informationskällor utöver statuskoden. Den första är om målsidan har registrerade inkommande externa länkar, vilket du kan kontrollera via ett länkanalysverktyg. Den andra är var länken finns på källsidan: i den globala navigationen, i en sidfotssektion, i brödtext eller i en sidofältslista. Den tredje är om det finns en semantiskt rimlig ersättningssida att redirecta till.

För en 404 kontrollerar ni om sidan flyttat och om en relevant ersättare finns. Uppdatera egna källänkar och överväg en omdirigering när den nya sidan faktiskt ersätter den gamla. För en 410 kontrollerar ni avsikten med borttagningen. Den statusen beskriver att resursen är borta, inte att en relevant ersättare aldrig kan finnas. Dokumentera beslutet efter verkligt innehåll och kunduppgift.

För en 5xx-status måste du skilja på serverfel på din egen sajt och på en extern domän. Är det din server ska du kontrollera applikationsloggar, eventuella minnesgränser eller felaktig serverrouting. Är det en extern sida du länkat till kan du inte kontrollera deras server, och rätt åtgärd är att antingen vänta och testa om, eller ta bort länken om felet kvarstår. För en 403 gäller att resursen troligen finns men är skyddad; undersök om länken ska finnas alls och om du eventuellt länkat till en URL som kräver inloggning.

Redirect-kedjor, alltså URL:er som svarar med 301 som pekar på en annan 301 som pekar på ett slutsvar, löses effektivast i källan. Redigera länken i källsidan så att den pekar direkt på slutdestinationen. Konfigurerar du enbart serverredirects utan att uppdatera källlänkarna lever kedjan kvar i din HTML och crawlers ser den fortfarande. Mer om hur URL-struktur och redirectstrategi hänger ihop beskriver vi i vår guide om SEO-migrering, URL-karta och säker lansering.

Prioritering: vad du åtgärdar först och varför

Inte alla brutna länkar är lika viktiga att hantera. Prioritering bygger på en kombination av var länken befinner sig strukturellt och om den berörda sidan har extern länkauktoritet att bevara. Här är fyra tydliga prioritetsnivåer att arbeta med.

Prioritet ett är navigations- och footerlänkar som är brutna. Dessa länk-instanser återkommer på hundratals eller tusentals sidor och utgör ryggraden i din interna länkstruktur. En bruten navigeringslänk påverkar varje sida som inkluderar navigationen. Rätta sådana fel omedelbart oavsett statuskod.

Prioritet två är sidor med verifierade inkommande externa länkar som returnerar 404 eller 410. Här handlar det om att bevara länkauktoritet genom att konfigurera rätt redirect, under förutsättning att en semantiskt relevant ersättningssida faktiskt existerar. En redirect till en orelaterad sida bara för att bevara länkvärdet är vilseledande för besökaren och bör undvikas.

Prioritet tre är interna brödtextlänkar till 404-sidor utan externa inkommande länkar. Dessa kan du hantera i en samlad redaktionell session: uppdatera länken om en relevant ersättningssida finns, ta annars bort länken och behåll texten om den fortfarande är meningsfull utan länken. Vår guide om interna länkar och begriplig webbplatsstruktur ger ett bredare perspektiv på hur du tänker kring internlänkning som helhet.

Prioritet fyra är externa utgående länkar till timeout-adresser eller 5xx-sidor. Dessa är ofta symptom på att externa resurser förändrats utan att du kan påverka det. Hantera dem i en separat session och fokusera på om länken tillför läsaren värde nog att motivera en aktiv utredning, eller om den bör tas bort direkt.

Illustrativt typfall: B2B-tjänstesajt efter kategoriomstrukturering

För att göra beslutsprocessen konkret arbetar vi med ett hypotetiskt illustrativt fall. Antag att ett B2B-företag vi kallar Nordisk Processpartner AB genomförde en kategoriomstrukturering av sin sajt för sex månader sedan. Sajten hade tidigare en URL-struktur med /losningar/kategori/produkt/ och gick över till /tjanster/produkt/. Under migreringen konfigurerades serverredirects för de viktigaste landningssidorna, men brödtextlänkar i äldre blogginlägg och resurssidor uppdaterades aldrig. Antagande: sajten har cirka 200 publicerade sidor, varav 40 är blogginlägg med genomsnittligt tre interna länkar per inlägg.

En crawl efter omstruktureringen producerade följande (illustrativa, fingerade) fördelning: 28 unika brutna destinationer returnerade 404, 4 returnerade 301-kedjor med tre hopp, 1 returnerade 410 och 2 returnerade timeout. Det finns inga 5xx-fel i detta hypotetiska fall.

Steg ett är att koppla de 28 unika 404-destinationerna mot den gamla URL-kartan från migreringen. Av de 28 har 19 en definierad ny URL i URL-kartan. Dessa kan åtgärdas med direkta 301-redirects på servernivå utan att redigera varje källsida. Resterande 9 saknar en definierad ersättning och måste hanteras sida för sida: antingen tas länken bort eller ersätts med en länk till en närstående tematisk sida.

Steg två är att kontrollera de 4 redirect-kedjorna. Alla 4 har sin ursprungliga href kvar i källsidornas HTML och pekar på den gamla strukturen som serverside är redirectad till en mellanstation som i sin tur är redirectad till slutdestinationen. Åtgärden är enkel: redigera href i källsidorna till att peka direkt på slutdestinationen och låt den första redirect-regeln på servern leva kvar som säkerhetsnät för eventuellt externa inkommande länkar som ännu inte uppdaterats.

Steg tre är 410-sidan. Den gäller en kundpresentationssida som företaget aktivt valde att ta bort permanent. Länken i det enda blogginlägget som pekar dit tas bort, och texten omformuleras för att vara meningsfull även utan länken. I detta illustrativa fall saknas en relevant ersättare, så ingen redirect konfigureras.

Steg fyra är de 2 timeout-adresserna. Båda är externa utgående länkar. Manuell testning nästa dag ger 200 för den ena, vilket tyder på en tillfällig nertid. Den andra ger fortfarande timeout efter 48 timmar. Länken till den andra tas bort. Länken till den första behålls.

Journalen uppdateras med åtgärd och datum för varje rad. Omtestning genomförs sju dagar senare efter att CDN-cache förfallit naturligt. Alla 301:or verifieras med curl mot respektive URL. Notera att detta hypotetiska exempel inte inkluderar några mätbara förbättringsresultat, eftersom vi inte kan förutse hur crawlers och rankingalgoritmer reagerar på länkfixar i ett specifikt fall.

Escaped länk- och fragmentexempel i HTML

En praktisk detalj som sällan diskuteras är hur du representerar problematiska URL:er i HTML-dokumentation och i din journal utan att de tolkas av webbläsaren som faktiska länkar. Om du dokumenterar ett fel i ett internt wiki-system eller i en HTML-rapport behöver du escapa tecken som annars bryter markeringen.

Nedan visas ett exempel på hur en bruten href med ett fragment ser ut i källkoden, escapad för att visas korrekt i en HTML-sida:

<a href="/guider/dataskydd/#avsnitt-gdpr">Läs om GDPR-krav</a>

Om ankaret #avsnitt-gdpr inte finns i destinationssidans HTML returnerar servern 200 (sidan laddas) men besökaren hamnar längst upp på sidan utan att scrollas till rätt position. Crawlers flaggar vanligtvis inte detta som ett fel eftersom HTTP-statuskoden är framgångsrik. Du hittar fragmentfel genom att antingen manuellt inventera sidans rubriker och ID:n, eller genom att använda ett verktyg som specifikt kontrollerar fragment-ankar.

För att verifiera att ett ankare finns kan du enkelt inspektera HTML-källan och söka efter attributet id som matchar fragmentet:

<h2 id="avsnitt-gdpr">GDPR-krav för B2B-sajter</h2>

Om ingen sådan rad finns i källkoden är fragmentet trasigt. Åtgärden är antingen att lägga till ID-attributet på rätt element, eller att uppdatera href till att peka på ett fragment som faktiskt finns. Glöm inte att samma problem uppstår automatiskt om du använder rubrikbaserade ankaren och sedan byter rubriktext, eftersom de flesta CMS genererar ID från rubriktexten.

Brutna länkar: hitta källan, välj åtgärd och testa igen
https://rangel.se/guider/brutna-lankar/

LÄSARUPPGIFT
Bygg en femkolumns länkjournal (käll-URL, href, HTTP-status, åtgärd, omtestat) och genomför rätt åtgärd per statustyp för minst tio brutna länkar på din webbplats.

Felsök en länk från källan till slutmålet
[ ] Reproducera länkhändelsen
Underlag att dokumentera: Spara käll-URL, href, tidpunkt, status och kundens avsedda nästa steg.
Mitt underlag:
Ansvarig / nästa steg:

[ ] Välj åtgärd efter faktisk orsak
Underlag att dokumentera: Skilj borttagen sida, tillfälligt fel, nekad åtkomst, redirectkedja och saknat fragment.
Mitt underlag:
Ansvarig / nästa steg:

[ ] Testa den ursprungliga kundvägen
Underlag att dokumentera: Kontrollera både ändrad källänk och slutmål efter åtgärd; dokumentera kvarvarande okända fel.
Mitt underlag:
Ansvarig / nästa steg:

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

Omtestning: cache, latens och bekräftelse

Omtestning är det steg som oftast hoppas över, med följden att journalen markeras som klar trots att felen tekniskt lever kvar. Det finns tre vanliga källor till falska positiver vid omtestning.

Den första är CDN-cache. Om din sajt använder ett CDN-lager kan en redirect som konfigurerades för tio minuter sedan fortfarande serveras som det gamla svaret under timmar eller till och med ett dygn beroende på hur lång TTL din konfiguration använder. Töm cache för berörda URL:er i ditt CDN-gränssnitt innan omtestning, eller vänta till TTL passerats naturligt om du inte har flush-behörighet.

Den andra är crawlcache i Screaming Frog. Om du crawlar om samma projekt i närtid utan att starta en ny session kan verktyget returnera cachade svar. Starta en ny crawl mot specificerade URL:er istället för att förlita dig på en inkrementell uppdatering.

Den tredje är server-side latens. En URL som svarar med timeout kan ge 200 fem minuter senare om servern temporärt var överbelastad. Testa tre gånger under minst 24 timmar och registrera varje testresultat separat i journalen innan du avgör om felet är permanent eller tillfälligt.

Ett HTTP-test kan visa svarskod och Location. Observera att curl -I skickar HEAD, vilket inte alltid får samma hantering som ett faktiskt GET-anrop. Kontrollera den metod och miljö som motsvarar den brutna kundvägen, följ relevanta redirects och spara slutdestinationen. Ett lyckat svar bevisar inte att rätt innehåll eller fragment visas.

Teknisk SEO-checklista för länkrevidering

Nedanstående checklista är avsedd att köras i angiven ordning. Varje steg är en faktisk uppgift, inte en kategori av uppgifter.

1. Kör en fullständig crawl med statuskodsinsamling aktiverad. Exportera till CSV.
2. Filtrera på statuskoderna 4xx, 5xx och 0 (timeout). Spara som separat fil.
3. Identifiera unika brutna destinationer (href), inte unika käll-URL:er. En destination kan länkas från tio källsidor.
4. Kontrollera inkommande externa länkar för varje unik bruten destination i ett länkanalysverktyg. Notera om externa inkommande länkar finns.
5. Klassificera varje destination i journalen med statuskod och åtgärd enligt beslutsmatrisen ovan.
6. Kolla om brutna destinationer finns i global navigation eller footer. Om ja, märk som prioritet ett.
7. Genomför serverredirects för 404:or med externa inkommande länkar och definierad ersättningssida. Dokumentera redirect i URL-kartan.
8. Redigera källsidor för resterande 404:or: uppdatera href eller ta bort länken beroende på om en relevant ersättningssida finns.
9. Hantera redirect-kedjor genom att uppdatera källlänken till slutdestinationen direkt.
10. Testa timeout-URL:er manuellt tre gånger under 48 timmar. Besluta om ta bort eller behålla.
11. Töm CDN-cache för berörda URL:er.
12. Omtesta alla åtgärdade destinationer med ny crawl eller manuell curl-kontroll. Uppdatera journalen med datum och utfall.

Om din sajt nyligen genomgick en migrering är det extra viktigt att gå igenom den fullständiga URL-kartan som bör ha upprättats inför migreringen. Saknas en URL-karta är det ett tecken på att migreringen behöver en efterhandsgranskning; mer om hur en korrekt genomförd migrering dokumenteras finns i vår guide om URL-karta, kontroll och säker lansering.

Gränsdragningen mot duplicerade URL:er och canonical

Arbetet med brutna länkar tangerar ibland ett angränsande problem som är viktigt att inte blanda ihop: sidor som tekniskt svarar med 200 men som är oavsiktliga dubletter av en annan sida. En bruten länk är ett fel i ett hypertextdokument som leder till en icke-fungerande destination. En duplicerad URL är ett indexeringsproblem där sökmotorer kan välja fel version av en sida som den kanoniska.

Det finns dock ett praktiskt överlapp: om du fixar en 404 med en 301-redirect till en sida som redan har en canonical-tag som pekar på en tredje URL riskerar du att skapa en situation där redirect-målet inte är den faktiska kanoniska URL:en. Det är inte katastrofalt men det är slarvig teknik. Kontrollera att den sida du redirectar till faktiskt är den URL du vill ska vara auktoritär, och att dess canonical-tag antingen är självrefererande eller pekar på en logisk kanonisk version. Mer om hur canonical och indexering hänger ihop finns i guiden om canonical, robots och indexering.

Det är också värt att notera att om du hanterar sidor med strukturerad data, exempelvis produktsidor eller artikelsidor med schema-markup, påverkar URL-ändringar den data som är knuten till respektive URL. Om en 301-redirect leder till en ny URL men strukturerad data inte uppdateras kan det uppstå inkonsekvenser i hur sidans innehåll beskrivs maskinläsbart. Vår guide om strukturerad data och korrekt beskrivning förklarar hur du undviker den typen av inkonsekvens. Vill du läsa mer om HTTP-redirecters tekniska mekanik är MDN:s referensmaterial om redirections i HTTP ett grundläggande och tillförlitligt dokument att utgå ifrån.

Länkrevidering i ett bredare SEO-arbete

Länkrevidering är inte ett projekt med ett definierat slutdatum. Det är ett återkommande underhållsmoment som bör integreras i din löpande tekniska SEO-process. Hur ofta du behöver köra en fullständig crawl beror på hur dynamisk din sajt är: en sajt som publicerar nytt innehåll varje vecka och regelbundet uppdaterar kategorisidor har ett högre behov av frekventa kontroller än en statisk presentationssajt som sällan ändras.

En rimlig rytm för de flesta B2B-sajter är en fullständig crawl med statuskontroll en gång per månad och en manuell kontroll av navigations- och footerlänkar direkt efter varje publicering av ny innehållsstruktur. Om du genomför en re-design eller kategoriomsstrukturering är länkrevidering en obligatorisk del av acceptanstestningen, inte ett efterarbete. Vår SEO-checklista för att kontrollera blockerande faktorer innehåller en sektion om just tekniska kontroller som bör genomföras i samband med strukturförändringar.

Om du arbetar med ett team av redaktörer som publicerar innehåll självständigt är det värt att dokumentera en enkel intern rutin: varje redaktör kontrollerar att alla href:er i ett nytt inlägg är aktiva innan publicering. Det kräver inget specialverktyg, en manuell klickkontroll räcker om sidan inte innehåller mer än ett dussin länk-instanser. Automatiserade kontroller med crawlers är mer effektiva för retrospektiv granskning av en stor webbplats men ersätter inte den enkla vanan att testa innan publicering.

För B2B-marknadsförare som vill sätta länkrevidering i ett affärsmässigt sammanhang och prioritera åtgärder utifrån faktisk affärsnytta, inte enbart teknisk korrekthet, är RANGELs verktyg för SEO-affärscase ett stöd för att strukturera den typen av resonemang baserat på dina egna antaganden och transparent aritmetik. Om du vill ha stöd med det löpande tekniska arbetet kan du se vad vår tekniska SEO-tjänst innebär och begära en offert därifrån.

Återkommande insamling och sortering av en feljournal kan automatiseras. Beslut om att ta bort eller flytta innehåll behöver ett dokumenterat underlag, en ansvarig och ett omtest. Separera observation från åtgärd så att processen kan köras av flera personer utan att varje rad leder till en slentrianmässig redirect. Formatverktyget kan hjälpa till när en faktisk ny innehållsuppgift behöver ett upplägg; det diagnostiserar inte länkfel.