Vilka fel i din crawlrapport du bör åtgärda först

Börja med fel som hindrar viktiga sidor från att fungera, hämtas eller indexeras. Bedöm därefter vilka åtgärder som har störst betydelse för webbplatsens affär. Antalet varningar i rapporten är inte en prioriteringsordning.

En crawlrapport kan innehålla tusentals anmärkningar utan att tala om vilken du ska börja med. Verktyget hittar avvikelser, men din uppgift är att avgöra vilka av dem som faktiskt behöver åtgärdas. Screaming Frog skriver själva att deras prioriteringar saknar webbplatsens sammanhang och inte ska behandlas som fasta regler för arbetet. 

Det betyder inte att du ska bortse från rapporten. Det betyder att varje rekommendation behöver ett svar på frågan om vad felet hindrar och vilka sidor som påverkas.

Kontrollera att felet finns

Innan du skickar en uppgift till en utvecklare behöver du kontrollera att rapporten visar ett problem på webbplatsen och inte en begränsning i undersökningen.

En crawler kan exempelvis få ett annat svar än en vanlig besökare eftersom den blockeras. En crawl utan rendering av JavaScript kan också sakna innehåll som laddas in med JavaScript. Ett tomt fält i rapporten är därför inte tillräckligt för att slå fast att innehållet saknas för Google. 

Ta några berörda adresser och kontrollera vad servern svarar, vilken HTML som levereras och vad som visas efter rendering. Jämför med sidgranskningen i Search Console när du behöver undersöka Googles åtkomst.

Skilj på en bekräftad avvikelse och en hypotes. ”Crawlern fick inget innehåll” är en observation. ”Google kan inte läsa våra produktsidor” är en slutsats som kräver mer underlag.

Prioritera sidorna innan du prioriterar felen

Tänk dig en nätbutik där rapporten visar 800 saknade metabeskrivningar, 60 adresser som svarar med 404 och 24 kategorisidor med noindex. Det här är ett påhittat exempel, men ett användbart sätt att pröva prioriteringen.

Om kategorierna ska synas i Google och säljer butikens viktigaste produkter börjar du med deras noindex. När Google hämtar en sida och läser direktivet ska sidan inte finnas kvar i sökresultatet. Att skriva 800 metabeskrivningar löser inte det problemet. 

De 60 adresserna med 404 behöver däremot undersökas. Är det aktiva produkter som har försvunnit av misstag, gamla adresser efter en flytt eller permanent borttagna produkter utan ersättare? Samma statuskod kan kräva olika åtgärder.

Komplettera därför rapporten med sidtyp, avsedd indexering och affärsmässig betydelse. Använd historiska klick, relevanta sökningar och uppgifter om försäljning eller förfrågningar som stöd. Lägg också till sidor som företaget vill växa med.

Prioritera inte enbart efter dagens trafik. En viktig kategori kan ha noll klick just för att den har varit blockerad sedan publiceringen. Frånvaron av trafik är då en del av problemet, inte ett skäl att lägga sidan sist.

Ta hand om hindren för viktiga sidor

Återkommande serverfel på sidor som ska fungera hör högt upp på arbetslistan. Google minskar tillfälligt hämtningen vid svar i serien 5xx, och adresser som fortsätter att ge serverfel kan så småningom försvinna ur index. Kontrollera att felet återkommer och undersök omfattningen tillsammans med den som ansvarar för driften. 

Oavsiktlig noindex på viktiga sidor är ett annat tydligt hinder. Kontrollera både sidans HTML och serverns svarshuvuden. Direktivet kan ligga på olika ställen, och en ändring i sidmallen hjälper inte om servern fortfarande skickar noindex. 

En blockering i robots.txt behöver bedömas separat. Den styr hämtning och är inte samma sak som noindex. En blockerad adress kan fortfarande förekomma i sökresultatet, och Google kan inte läsa ett noindex på en sida som inte får hämtas. Öppna därför inte alla blockerade adresser bara för att verktyget markerar dem. Kontrollera vilka som faktiskt ska vara tillgängliga. 

Granska också canonical när viktiga sidor pekar ut oväntade huvudversioner. Om butikens kategorier anger startsidan som canonical behöver du undersöka varför. Men beskriv inte signalen som ett säkert besked om vad Google har gjort. Canonical är en rekommendation, och Googles val kan skilja sig från webbplatsens. Kontrollera den valda adressen i Search Console. 

För nätbutiken i exemplet behöver du inte vänta på ett synligt trafiktapp innan du tar bort en bekräftat felaktig noindex på de 24 kategorierna. Du har redan konstaterat att inställningen strider mot sidornas uppgift.

Skilj trasiga sidor från borttagna sidor

En adress som svarar med 404 är inte automatiskt något som ska återställas. Om innehållet är permanent borttaget och saknar en relevant ersättare kan 404 eller 410 vara rätt svar. Har innehållet däremot flyttat ska den gamla adressen normalt omdirigeras till den nya. Google avråder från att skicka många gamla adresser till en irrelevant destination, exempelvis startsidan. 

Undersök därför både målsidan och länkarna som leder dit.

Om en aktiv kategori har försvunnit av misstag är uppgiften att återställa den. Om en produkt har fått en ny adress behöver du en korrekt omdirigering och uppdaterade interna länkar. Om produkten är permanent borttagen utan ersättare kan du behöva ta bort eller ändra länkarna i navigationen, rekommendationsmodulerna och artiklarna.

Prioritera särskilt trasiga länkar som ligger i viktiga köpvägar. En länk från huvudmenyn till en sida som inte finns är en annan arbetsuppgift än en gammal adress som bara förekommer i en historisk export.

Leta efter en gemensam orsak

Gör inte en separat utvecklingsuppgift av varje rad i rapporten. Gruppera adresserna efter sidtyp, mall och sannolik felkälla.

I nätbutiken kan de 24 kategorierna ha fått noindex genom en gemensam inställning. Då är det den inställningen som ska rättas. Att redigera varje kategori för sig riskerar att lämna grundproblemet kvar när nästa kategori publiceras.

Samma arbetssätt hjälper dig att bedöma arbetsinsatsen. Hundratals fel kan kräva en liten ändring i en mall. Ett enda fel i navigationen kan kräva ett större ingrepp.

Men en gemensam lösning behöver också tydliga undantag. En uppgift som bara säger ”ta bort noindex” är för bred om samma system hanterar interna sökresultat eller andra sidor som avsiktligt hålls utanför index. Ange vilka sidtyper som ska ändras och vilka som ska lämnas orörda.

Låt inte enkla åtgärder tränga undan viktiga

När de allvarliga hindren är hanterade behöver du väga förväntad nytta mot arbetsinsats, osäkerhet och risken med ändringen.

Det är lätt att börja med sådant som går snabbt att bocka av. Metabeskrivningar och titellängder är synliga i rapporten och enkla att räkna. Men en titel blir inte automatiskt dålig för att den passerar verktygets teckengräns. Google anger ingen fast maximal längd för title eller metabeskrivning, även om det som visas i sökresultatet kan kortas av. 

Bedöm vad som faktiskt behöver förbättras. En titel som bara säger ”Produkter” kan behöva ändras eftersom den inte beskriver sidan. En tydlig titel som är något längre än verktygets rekommendation kan du välja att behålla.

De 800 metabeskrivningarna i exemplet behöver alltså inte bli nästa stora projekt. Börja med att granska hur butikens viktiga sidor presenteras i sökresultaten. Google använder främst sidinnehållet för beskrivningen och kan använda metabeskrivningen när den passar bättre. Att fältet är tomt betyder inte att sökresultatet saknar beskrivning. 

En enkel åtgärd får gärna göras tidigt om den inte tränger undan viktigare arbete. Men ”det går snabbt” är inte samma motivering som ”det här bör göras först”.

Skriv vad som ska vara annorlunda efter ändringen

Din prioritering behöver gå att genomföra utan att utvecklaren först måste göra om analysen. Beskriv felet, vilka sidor som berörs, varför ändringen behövs och hur den ska kontrolleras.

För nätbutiken skulle uppgiften kunna formuleras så här:

De 24 kategorisidorna i den bifogade adresslistan ska kunna indexeras men skickar i dag noindex. Ta bort direktivet för dessa kategorier och kontrollera den gemensamma inställningen så att nya kategorier inte får samma fel. Ändra inte avsiktlig noindex för interna sökresultat. Efter publicering ska samtliga 24 adresser svara med 200, visa rätt kategoriinnehåll och sakna noindex både i HTML och i serverns svarshuvuden.

Efter ändringen crawlar du de berörda adresserna igen och kontrollerar även några sidor som inte skulle påverkas. Följ därefter upp Googles hämtning och indexering i Search Console. En tekniskt korrekt sida är inte garanterad indexering, och en begäran om ny hämtning ger ingen sådan garanti heller. 

Spara publiceringsdatumet och resultatet från kontrollen i uppgiften. Markera den tekniska rättningen som verifierad när den är kontrollerad, och håll uppföljningen av indexering och trafik separat.