Innhold i denne artikkelen
En lang liste med røde feil er lite nyttig hvis du ikke vet hvilke som kan koste deg kunder. Bruk Screaming Frog til å kontrollere viktige URL-er, finne feil og redirectkjeder, og sammenligne før og etter endringer, ikke bare til å produsere en rapport.
Hva er Screaming Frog?
Screaming Frog SEO Spider henter sider og registrerer blant annet svarstatus, lenker, titler og indekseringssignaler. Du kjører verktøyet fra din egen maskin.
Du kan tenke på det som en teknisk befaring av nettstedet. Verktøyet følger adressene du gir det, og samler funn som ellers ville krevd at du åpnet side etter side manuelt. Det hjelper deg å se mønstre, for eksempel at mange produktsider har samme feil, men avgjør ikke hvilke tiltak som er viktigst for kundene dine.
Hvordan bruker du Screaming Frog?
Start med én konkret oppgave. Nedenfor går jeg gjennom arbeidsrekkefølgen jeg ville brukt for å finne feil og kontrollere en migrering, fra valg av adresser til kontroll etter retting.
1. Velg hva du skal undersøke
Før du starter, bestem om du skal undersøke interne feil, kontrollere en redirect-plan eller sammenligne en lansering. Det avgjør hvilke adresser du trenger og hva du skal eksportere.
I en teknisk gjennomgang vil jeg først vite hvilke sider virksomheten ikke har råd til å miste. En gammel side med relevante henvendelser fortjener en annen oppfølging enn en utgått kampanje. Verktøyet kjenner ikke den forskjellen av seg selv.
Lag et prioritert utvalg med viktige landingssider, produkter og adresser som har trafikk eller eksterne lenker. Search Console, et nettstedskart og en eksisterende redirect-plan kan supplere hverandre. Ingen av dem er nødvendigvis en komplett liste alene.
2. Velg vanlig crawl eller List mode
I vanlig Spider mode starter du med en adresse og lar verktøyet følge lenker innenfor oppsettets avgrensning. Det er nyttig for å finne interne lenker som peker feil.
I Mode → List laster du opp eller limer inn de konkrete URL-ene du vil undersøke. Bruk komplette adresser med https:// eller http://. Som standard følger List mode ikke videre lenker. Det gjør den nyttig når du skal sjekke gamle adresser uten å gjennomsøke hele nettstedet.
Kontroller innstillingene før du kjører. Håndtering av redirects, crawlgrenser og hvilke lenker som følges, påvirker resultatet. Ved redirectkontroll trenger du også informasjon om sluttdestinasjonen, ikke bare første svar.
3. Finn 404-feil og hvor lenken kommer fra
Når kjøringen er ferdig, åpner du Response Codes og undersøker filteret for klientfeil, 4XX. En 404 betyr at adressen ikke ble funnet, men sier ikke hvorfor den ble etterspurt.
Marker en feiladresse og undersøk Inlinks når crawlen har registrert lenkene dit. Da kan du finne siden som må oppdateres. En ren URL-liste i List mode gir ikke nødvendigvis denne lenkekonteksten.
Skill mellom to tiltak: rett den interne lenken dersom den peker feil, og vurder hva den gamle adressen bør returnere. Hvis innholdet har en relevant erstatning, kan en permanent redirect være riktig. Hvis det faktisk er borte uten erstatning, kan 404 eller 410 være korrekt.
Ikke omdiriger alle feil til forsiden. Det gjør ikke forsiden til et nyttig svar på det leseren lette etter. Se guiden til redirects for valg av riktig håndtering.
4. Følg redirecten helt frem
Bruk 3XX-filteret i Response Codes til å undersøke omdirigeringer. Se både på status og destinasjon. Leverandørens redirect-veiledning forklarer også rapportene for kjeder og løkker.
En gammel adresse som returnerer 301, kan fortsatt ende på feil produkt, en ny 404 eller en kjede med unødvendige mellomsteg. En løkke kan hindre at brukeren kommer frem i det hele tatt.
Ved permanent flytting er en direkte vei til den relevante erstatningen normalt enklere å kontrollere. Oppdater også interne lenker så de peker rett på den nye siden.
Å få 200 til slutt er bare én kontroll. Åpne et utvalg av destinasjonene og se at innholdet faktisk passer. Verktøyet kan ikke avgjøre om den nye kategorisiden er en god erstatning for en detaljert produktveiledning.
5. Sammenlign før og etter migrering
Ta vare på URL-grunnlaget og resultatene før lansering. Etterpå kjører du de gamle adressene igjen for å kontrollere hvordan de håndteres. Undersøk også de nye sidene og de interne lenkene.
Med lisens og database storage mode kan du bruke Screaming Frogs innebygde crawl comparison. Den kan synliggjøre endringer i blant annet status, titler og sidestruktur. Bruk sammenlignbare innstillinger, ellers kan en endring i oppsettet se ut som en endring på nettstedet.
Uten denne funksjonen kan du kontrollere et avgrenset utvalg manuelt og notere gammel adresse, forventet destinasjon, faktisk destinasjon og funn. Ikke anta at lagring og eksport fungerer likt i alle lisensnivåer.
Før migreringen godkjennes
- Gamle viktige URL-er er kontrollert mot forventet erstatning.
- Redirectkjeder og løkker er undersøkt.
- Nye destinasjoner har riktig innhold, ikke bare status 200.
- Interne lenker og nettstedskart bruker de nye adressene.
- Uønsket noindex, robots-blokkering og canonical er kontrollert.
- Search Console og trafikk følges også etter lanseringen.
6. Ikke forveksle crawlen med Google
Screaming Frog kan hente en side som Google ennå ikke har indeksert. Det kan også møte blokkeringer eller få en annen visning enn en robot eller nettleser med andre innstillinger.
Bruk Search Console til å kontrollere Googles rapporterte status. Hvis innholdet lastes med JavaScript, må du vurdere om crawlen har sett den relevante versjonen. Passordbeskyttelse og sikkerhetsregler kan også påvirke funnene.
En god gjennomgang slutter derfor med en kort, prioritert oppgaveliste og en ny kontroll. Ikke med et regneark som ingen har ansvar for å følge opp.
