SEO-analyse: slik gjør jeg en SEO-analyse av et nettsted steg for steg

En SEO-analyse er en beslutning om hva på nettstedet som bør rettes først, med bevis ved hver anbefaling og en måte å sjekke på etter innføringen. Feillisten fra et verktøy er bare materialet til analysen. Den tekniske SEO-analysen er den delen som sjekker om robotene til søkemotorer og AI-assistenter kan hente og lese nettstedet, og om søkemotoren kan indeksere det.

Jeg gjør analysen i åtte steg:

1. Jeg fastsetter målet og situasjonen til nettstedet før jeg starter en crawler, altså et program som går gjennom nettstedet slik en søkerobot gjør.
2. Jeg sjekker om robotene i det hele tatt får nettstedet.
3. Jeg samler data fra flere kilder og sjekker hva hver av dem ikke ser.
4. Jeg undersøker søkeord og Google-resultater før jeg tar for meg teknikken.
5. Jeg går gjennom nettstedet etter problemkatalogen med vilkår for prioritet.
6. Jeg viser bevis ved hvert punkt.
7. Jeg fastsetter rekkefølge, arbeidsmengde og varianter.
8. Jeg leverer resultatet til kryssjekk, og etter innføringen sjekker jeg hvert punkt.

Hva er en SEO-analyse, og hva skiller en teknisk SEO-analyse fra den?

En SEO-analyse sier hvilken tilstand nettstedet er i og hva som begrenser synligheten, mens en teknisk SEO-analyse sjekker om søkemotoren kan hente, rendre og indeksere nettstedet. I en full analyse sjekker jeg teknikk, struktur og innhold på sidene, søkeord, eksterne lenker og konkurranse, og til slutt setter jeg opp rekkefølgen på tiltakene. Den tekniske analysen holder når spørsmålet er teknisk: fall etter en innføring, migrering, sider som faller ut av indeksen.

En analyse er inngangen til strategien og ikke strategien. Strategien sier hvilken etterspørsel du kjemper om og hva du dropper, mens analysen sier hva som i dag står i veien for det. I teksten om SEO-strategi beskrev jeg hvordan det ene går over i det andre.

Hvordan gjør du en SEO-analyse steg for steg?

Rekkefølgen på stegene har betydning, for de tidligere stegene avgjør om tallene fra de senere er pålitelige. To steder stopper jeg prosessen for en beslutning: etter det første steget fastsetter jeg omfanget, og etter kryssjekken, før det sendes til kunden, sjekker jeg prioriteringene og påstandene.

Steg 1. Mål og situasjon før jeg starter crawleren

Det første spørsmålet er om nettstedet mister trafikk eller ikke bygger den, for svaret avgjør hele analysen. Et nettsted uten synlighet trenger først et kart over søkeord og sidene som skal svare på dem. Et nettsted som har synlighet, trenger først at det som allerede har plasseringer, blir beskyttet, før noen begynner å forbedre det.

Før jeg starter, spør jeg om ting som intet verktøy viser. Hvilke produkter eller tjenester som tjener penger, om det er planlagt bytte av publiseringssystemet eller ombygging, hvem som skal innføre anbefalingene og hvor mye tid de har. Av svarene følger omfanget av analysen og listen over ting jeg ikke skriver ut, fordi ingen kommer til å innføre dem.

Dette steget må du gjøre selv, selv om mange spesialister i dag overlater det til en språkmodell. En språkmodell kan være til hjelp, men den forstår ikke virksomheten til kunden. Den tilfører heller ikke det kreative, unike blikket som en erfaren SEO-spesialist har.

Steg 2. Får robotene i det hele tatt nettstedet

Før jeg leser noe tall fra et verktøy, sjekker jeg om serveren slipper robotene inn, for en blokkert robot gir data som ser ut som SEO-problemer. I én uke i juli 2026 viste tre «SEO-problemer» i tre ulike nettsteder seg å være blokkering av roboter:

1. Et nettsted «mistet» over 2 200 lenker, fordi sidene lenkene førte fra, sto bak en brannmur som avviste roboten til verktøyet for lenkeanalyse.
2. En nettbutikk hadde i verktøyet en helsescore på 0 med nesten 42 tusen feil, fordi roboten til verktøyet i stedet for sider fikk svar fra Cloudflare-brannmuren.
3. På det tredje nettstedet stoppet en blokkering crawleren på den første adressen, og i tre uker la ingen merke til det.

Den samme adressen henter jeg som en vanlig nettleser og som robotene til Google, Bing, OpenAI, Perplexity og Anthropic, og så sammenligner jeg svarkodene og størrelsen på siden. Forskjellen mellom nettleseren og roboten er det første jeg må forklare før jeg begynner å telle noe. En slik test sender forespørsler fra IP-adressen min under navnet til roboten, og brannmurer gjenkjenner de ekte robotene til Google og Bing på adressen de kommer fra. En blokkering av «Googlebot» i testen beviser derfor ikke en blokkering av den ekte Googlebot. Search Console, Googles gratis panel for eiere av nettsteder, viser hvordan den ekte Googlebot ser nettstedet.

Filen robots.txt leser jeg helt til slutt med en parser, altså et program som anvender reglene slik en robot gjør, og ikke med øynene. Googles robot anvender bare én gruppe regler, den med det best samsvarende robotnavnet, og hopper over de andre. Regelen Disallow: uten sti blokkerer ingenting (Google Search Central). I august 2026 så et utdrag av robots.txt på et av nettstedene ut til å blokkere Google. Parseren viste at Googlebot hadde full tilgang, mens robotene til Bing og AI-assistentene var blokkert. Diagnosen ble altså en annen: problemet gjaldt Bing og AI-robotene og ikke Google.

Manglende robots.txt blokkerer ikke Google, men etter hver innføring sjekker jeg at filen ikke er borte. Google behandler en 4xx-feil på robots.txt (unntatt 429) som om filen ikke fantes, altså uten begrensninger (Google Search Central). Mitt eget nettsted ga i august 2026 en 404-feil på robots.txt før jeg rettet det.

Steg 3. Data fra flere kilder og det hver av dem ikke ser

Hvert tall fra en crawler er en hypotese helt til en annen kilde bekrefter det. Jeg samler crawl med og uten JavaScript og data om hastighet fra ekte brukere fra CrUX-rapporten. Dertil kommer lenkeprofilen og Google-resultatene for de viktige søkeordene på måledagen. I teksten om lenkebygging beskrev jeg hvordan jeg sjekker lenkeprofilen før jeg planlegger en kampanje. Ved hver fil skriver jeg ned kilden, datoen og omfanget, slik at hvert tall kan gjenskapes etter en måned.

Data fra Search Console henter jeg via API-et, altså grensesnittet for automatisk henting av data, for eksporten fra panelet kutter listen ved 1 000 rader. API-et gir opptil 50 tusen rader per dag for hver type resultater, for eksempel hver for seg for resultater av sider, bilder og video (Google, Search Console-hjelp). I teksten om AI-verktøy i SEO viste jeg hvordan en avkuttet eksport blåste opp klikkraten (CTR) på ett nettsted.

En crawler kan undervurdere størrelsen på nettstedet, så antall sider og produkter sjekker jeg i en annen kilde. I to nettbutikker kom crawleren til den første siden i produktlisten i en kategori og gikk ikke lenger, selv om de neste sidene i listen fungerte og ikke var blokkert. I den ene butikken fant den under halvparten av produktene, i den andre under en tredjedel. Hvis jeg hadde oppgitt disse tallene som tilstanden til butikkene, ville analysen beskrevet hull i tilbudet som ikke fantes.

Plutselige endringer i daglige data beskriver jeg før jeg tilskriver dem en årsak. Det gjør jeg for klikk, visninger, plasseringer, økter og forespørsler fra Googles robot. Jeg leter etter dager der medianen over sju påfølgende dager avviker med minst 25 % fra medianen over fjorten dager før dem. Ved hver slik dato skriver jeg ned forklaringen: innføring, Google-oppdatering, feil, endring i målingen eller «årsak ukjent». Beskrivelsen av datoene gir hypoteser, og årsaken peker jeg ut først etter at jeg har sjekket andre mulige forklaringer.

Steg 4. Søkeord og Google-resultater før teknikken

Først leter jeg etter muligheter, deretter retter jeg feil. En del tekniske problemer lar seg bare vurdere på bakgrunn av søkeord: om et filter i en butikk skal indekseres, om en tagg fortjener en egen side, om to sider virkelig konkurrerer om det samme. I katalogen er 32 typer problemer merket med at de ikke kan vurderes uten analyse av søkeord og Google-resultater.

Manglende side for et viktig søkeord er et av de hyppigere problemene i analysene mine: 15 av 63 analyser, i 14 av 50 nettsteder. Crawleren melder det ikke selv, for den henter bare sidene som finnes. Det blir synlig først når jeg setter etterspørselen opp mot listen over adresser og mot hvilke sider hos konkurrentene som dukker opp i resultatene.

Steg 5. Gjennomgang etter katalogen med vilkår for prioritet

Den samme feilen har høy eller lav prioritet avhengig av hvor den finnes. En intern lenke til en adresse med omdirigering i en mal som gjentas på tusenvis av sider, har høy prioritet. Den samme lenken i innholdet i ett enkelt innlegg har middels prioritet, og i arkiverte innlegg lav.

Hver type problem i katalogen har en regel for oppdaging, et vilkår for melding, et nødvendig bevis, en prioritet med vilkår og en måte å sjekke på etter innføringen. Av de 256 typene begynner 86 prioritetsregelen med «høy», men nesten alltid med et vilkår: når søkeordet har etterspørsel, når siden har trafikk, når feilen er i malen.

Derfor fastsetter ikke helsescoren fra et verktøy prioriteringene. Verktøyet teller feil og ikke trafikken som avhenger av dem. En anbefaling om sider med ukjent trafikk får ikke høy prioritet før jeg har sjekket dataene.

Steg 6. Bevis ved hvert punkt

Et punkt uten bevis blir stående i analysen som «skal sjekkes» og ikke som en anbefaling. Beviset er et skjermbilde av stedet i koden eller HTML fra serveren ved siden av versjonen etter at JavaScript er kjørt. Det kan også være en graf fra Search Console eller en måling av hastighet med navnet på elementet som ødelegger den. Et element som forverrer lastingen eller flytter oppsettet på siden, navngir jeg slik målingen peker på det, og ikke slik det passer med hypotesen min.

Hvert punkt beskriver jeg i fire deler, fra problemet til sjekken av rettelsen. Jeg skriver hva problemet går ut på, hvorfor det skader og hva det påvirker, hvordan det rettes steg for steg og hvordan vi sjekker at rettelsen virket. Koden som skal rettes, kopierer jeg ordrett fra nettstedet, slik at utvikleren ser nøyaktig stedet som skal endres.

Slik ser en kort melding om lenker til omdirigeringer ut:

• Problem: lenker i menyen fører til adresser uten skråstrek på slutten, som omdirigerer til versjonen med skråstrek.
• Hvorfor det skader: menyen er på hver side, så hvert klikk og hver henting fra en robot går gjennom en ekstra omdirigering. I rapporter fra verktøy gjør tusenvis av slike lenker det vanskeligere å finne viktigere feil.
• Rettelse: bytte ut adressene i menymalen med de endelige, med et kodeutdrag før og etter endringen.
• Sjekk: etter innføringen viser crawlen ingen lenker til adresser med omdirigering i malen.

Steg 7. Rekkefølge, arbeidsmengde og varianter

Resultatet av analysen er en rekkefølge og ikke et antall funn. Først i dokumentet står en tabell over alle punkter med prioritet og arbeidsmengde. Arbeidsmengden beskriver jeg i fire kategorier: noen timer, en dag eller to, en uke eller et helt prosjekt. Et team med mindre kapasitet får en minimumsvariant ved siden av den fulle, med en tydelig beskrivelse av hva det taper på å velge den korteste veien.

Innføringen følger analysen nøyaktig. Hvis det ved prisingen av innføringen dukker opp en rimeligere variant, er det kunden som velger den, og jeg skriver det rett ut og bytter ikke ut anbefalingen uten at kunden vet det.

Steg 8. Kryssjekk og kontroll etter innføringen

Før analysen går til kunden, sjekkes den av noen som ikke har skrevet den. Jeg gjør to runder kontroll: den første på hele dokumentet, den andre bare på det som endret seg etter den første. Kontrollen regner om tallene fra bunnen av og leter etter påstander som ikke kan forsvares med bevis. Til slutt sjekker jeg selv prioriteringene og påstandene som avhenger av situasjonen til kunden.

Etter innføringen sjekker jeg hvert punkt på det fungerende nettstedet og merker det som innført riktig, delvis eller ikke innført. Denne sjekken er inkludert i prisen for analysen. Uten dette steget ender analysen i et dokument og ikke i en endring på nettstedet.

Hva sjekker jeg i en teknisk SEO-analyse?

I en teknisk SEO-analyse går jeg gjennom godt over ti områder, og problemene melder jeg oftest i omdirigeringer, arkitektur og innhold. Den siste kolonnen viser i hvor mange av de 63 analysene i arkivet forfatteren meldte minst ett problem fra området. Kolonnen «Hva jeg sjekker» gir eksempler og ikke hele omfanget av området. Tabellen viser utvalgte områder, og katalogen deler problemene inn i 22.

Et problem som sjelden meldes, trenger ikke å forekomme sjelden. Hastighet og JavaScript har få meldinger i denne tabellen, men analysene i arkivet hadde ulikt omfang. Et lavt antall meldinger sier derfor ikke hvor ofte disse problemene finnes på nettsteder.

Hvordan sjekker jeg indekseringen av et nettsted?

Indekseringen sjekker jeg på tre lister: hva som står i nettstedskartet, hva Google har indeksert og hva crawleren finner via lenker. Avviket mellom disse tre listene viser et problem bedre enn hver av dem alene. Et nettstedskart med adresser som gir omdirigering, feil eller er utelukket fra indeksen, ble meldt i 20 av 63 analyser, i 18 av 50 nettsteder. For enkeltadresser bruker jeg URL-inspeksjon i Search Console, som også viser siden etter at JavaScript er kjørt.

Påvirker Core Web Vitals plasseringene?

Core Web Vitals er en del av rangeringssystemene til Google, men de slår ikke relevansen til innholdet. Google skriver rett ut at rangeringssystemene bruker Core Web Vitals. De skriver også at de alltid prøver å vise det mest relevante innholdet, selv med svak opplevelse på siden (Google Search Central). I analysen bruker jeg data fra ekte brukere fra CrUX-rapporten og ikke en enkelt test i et laboratorieverktøy. Der Google har slike data for enkelte sidetyper, oppgir jeg dem hver for seg. Manglene i disse dataene beskriver jeg i analysen. Fra 12. mars 2024 er målet på reaksjonen til siden INP, som erstattet FID (web.dev).

Hvilke feil finner jeg oftest i SEO-analyser?

Oftest gjentar ryddefeil seg, altså de som verktøyene lett oppdager: lenker til omdirigeringer og til 404-feil, nettstedskart med feil adresser og dupliserte titler og beskrivelser av sider. Interne lenker til adresser med omdirigering dukket opp i 24 av 63 analyser, i 20 av 50 nettsteder. Verktøyene oppdager dem godt, og kostnaden ved å rette dem avhenger av malen og systemet til nettstedet.

Problemer i strukturen som meldes sjeldnere, kan ha større innvirkning på trafikken enn ryddefeil. Manglende sider for viktige søkeord ble meldt i 15 av 63 analyser, og like mange ganger en blogg som ikke lenker til tilbuds- og kategorisidene. Katalogen gir en manglende side høy prioritet når søkeordet har etterspørsel og konkurrentene har plasseringene med egne sider. En blogg uten lenker får høy prioritet når målsidene har trafikk eller omsetning og bloggen har autoritet. Disse vilkårene sjekker jeg på data før jeg gir prioritet.

• 938funn i 63 analyser i 50 nettsteder, som jeg bygde katalogen med 256 typer problemer avArkiv av analyser 2020-2026, katalog fra 11. oktober 2026
• 38 %av analysene med interne lenker til adresser med omdirigering, det oftest meldte problemet i arkivet (24 av 63)Katalog fra 11. oktober 2026
• 15 av 63analyser med manglende sider for viktige søkeord, noe crawleren ikke melder selvKatalog fra 11. oktober 2026
• 14typer anbefalinger som katalogen i dag merker som utdaterte, og 30 til som endret praksisKatalog fra 11. oktober 2026

Hva har endret seg i SEO-analyser siden 2020?

I analysene fra 2023-2026 dukker strukturerte data og paginering opp oftere enn i 2020-2022, mens omdirigeringer, kanoniske adresser og indeksering dukker opp sjeldnere. Problemer med strukturerte data ble meldt i 23 av 33 nyere analyser mot 16 av 30 eldre. Omdirigeringer og svarkoder: 23 av 33 mot 27 av 30. Blokkering av AI-roboter dukker opp først i analyser fra 2026. Året for analysen er datoen på filen i arkivet, så det er ikke alltid året arbeidet ble utført.

Nedgangen beviser ikke at problemene med omdirigeringer har forsvunnet. Sammensetningen av analysene endret seg: de nyere handlet oftere om strukturerte data, innhold og synlighet i AI, og arbeidsmåten endret seg også. Av denne grafen kan man lese hva analysene tok for seg, og ikke hvordan nettstedene i Polen har endret seg.

Hvilke SEO-anbefalinger er utdaterte i dag?

Noen anbefalinger dukker fortsatt opp i analyser og veiledninger, selv om det i dag ikke lønner seg å innføre dem. En del av dem virket for noen år siden, og en del har Google frarådet eller hoppet over lenge. I tabellen oppgir jeg ved hver praksis grunnen og hva man bør gjøre i stedet.

Kilder til tabellen: Google om paginering, Google om fem feil med rel=canonical, Google om FAQ- og HowTo-resultater, Matt Cutts om nofollow og fordeling av lenkekraft, John Mueller om omdirigeringer til forsiden, via Search Engine Roundtable, Google om robots.txt, Google om ikke-støttede regler i robots.txt, Google om nettstedskart, Google om feltene lastmod, changefreq og priority, web.dev om INP, Google om søkefeltet i resultatene.

Derfor har hver anbefaling i katalogen min et felt for aktualitet med begrunnelse. Katalogen merker i dag 14 typer anbefalinger som utdaterte og 30 som endret praksis. En anbefaling som var riktig for noen år siden, kommer ikke med i en analyse bare fordi den en gang virket.

Hvordan sjekker jeg tilgangen for AI-roboter i analysen?

Tilgangen for AI-roboter sjekker jeg i samme steg som tilgangen for Googlebot, for den samme innstillingen i brannmuren eller CDN-et kan blokkere dem. CDN er et nettverk av mellomliggende servere, for eksempel Cloudflare. I september 2026 sjekket jeg 12 av kundenes domener som ligger bak Cloudflare. Selve filen robots.txt viste:

• 3 domener blokkerte det samme settet med sju roboter som samler data til trening av modeller, med identisk liste over navn. En identisk liste tyder på en felles kilde, for eksempel en ferdig innstilling i Cloudflare-panelet. Utenfra kan man ikke se denne innstillingen, så den må bekreftes i selve panelet.
• 1 domene blokkerte robotene som henter sider til svar i ChatGPT, Perplexity og Claude. Det gjorde det ikke rett ut, men med en generell regel for alle roboter som ikke var nevnt ved navn. Det samme domenet viste GPTBot en sikkerhetsside uten noindex-markeringen, som utelukker en side fra indeksen. Hvis en indekserende robot hadde fått en slik side, kunne blokkeringssiden havnet i indeksen i stedet for innholdet.
• 8 domener hadde ingen blokkeringer i robots.txt.

Om robotene som henter sider til svar og robotene som samler data til trening bestemmer du hver for seg. I teksten om AI SEO og GEO beskrev jeg hvordan man skiller dem. Fra 31. august 2026 finnes det også en egen innstilling i Search Console som utelukker et nettsted fra AI Overview, AI-modus og generative funksjoner i Discover. Ifølge Google påvirker den ikke resten av søkeresultatene (Search Console-hjelp). En slik innstilling sjekker jeg i analysen på samme måte som robots.txt, for noen kan ha skrudd den på uten at den som er ansvarlig for SEO vet om det. Om merkevaren dukker opp i svarene etter at tilgangen er åpnet, er en egen måling, som jeg beskrev i teksten om AI-synlighet.

En test fra én IP-adresse viser bare en del av situasjonen, og den kan selv gi falsk alarm. I den samme gjennomgangen meldte en serie forespørsler blokkering etter at en grense var overskredet på to domener. Denne blokkeringen ble utløst av mine egne tidligere forespørsler. En kontroll noen minutter senere, med én robotidentifikator og enkeltforespørsler, ga fem og sju riktige svar på rad. Hadde det ikke vært for denne kontrollen, ville to kunder fått beskjed om en blokkering som ikke fantes. Først serverloggene viser om ChatGPT faktisk henter nettstedet. I teksten om filen llms.txt viser jeg hva man ser i loggene til nettstedet mitt.

Kode 200 betyr ikke at roboten fikk innholdet. Hos en kunde med en JavaScript-applikasjon fikk Googlebot og Bingbot ferdig HTML fra en prerender-tjeneste, mens robotene til AI-assistentene fikk en tom side. Tjenesten gjenkjente robotene på navnet og hadde ikke AI-robotene på listen. Testen min ga resultatet «i orden», for den målte svarkoden og ikke innholdet. Siden da sammenligner jeg innholdet roboten får med innholdet etter at JavaScript er kjørt i nettleseren.

Holder en gratis SEO-analyse?

Et gratis verktøy viser en liste over feil, men av selve rapporten går det ikke fram hvilke av dem som koster deg trafikk. På det polske søkeordet «audyt seo» er 7 av 9 organiske resultater på første side i Google verktøy eller tilbud om gratis analyse (resultater fra 17. oktober 2026). En slik rapport teller feil etter reglene til verktøyet og ikke etter hvor mye trafikk og omsetning som avhenger av dem. Man må også sjekke at resultatet ikke stammer fra en blokkering av roboten, som i tilfellet med nettbutikken med helsescore 0.

Du får gjort mye gratis hvis du vet hvor du skal se. Search Console viser Googles data om indeksering, Core Web Vitals og siden etter at JavaScript er kjørt. Gratisversjonen av Screaming Frog går gjennom opptil 500 adresser i én crawl (Screaming Frog), som holder for et lite bedriftsnettsted. En analyse med en konsulent gir mening når feilen koster mye (migrering, trafikkfall, en stor butikk) eller når du ikke har tid til å sette sammen og vurdere dataene.

Kan ChatGPT gjøre en SEO-analyse?

ChatGPT eller en annen AI-modell kan ikke gjøre en full analyse alene, for den ser ikke nettstedet slik en søkerobot gjør. Vanligvis ser den det gjennom et verktøy som henter det og gjør det om til tekst. Modellen leser dataene du gir den og foreslår hva som bør sjekkes. Verktøyet for henting kan likevel miste en del av siden: i september 2026 sjekket jeg at verktøyet for henting av sider i Claude Code skjærer bort strukturerte data når siden gjøres om til tekst. Modellen svarte at informasjonen ikke fantes, selv om den lå i en markering på samme side. En analyse gjort på den måten ville meldt mangel på strukturerte data som ikke mangler. I prosessen min er AI et verktøy, først og fremst til å samle data fra crawlen, Search Console og andre kilder. Omfang, vurdering og prioriteringer fastsetter jeg selv.

Hva koster en SEO-analyse?

Analysen regner jeg som en konsultasjon: 70 EUR netto per time arbeid, med en øvre grense for timer fastsatt før start. Antall timer avhenger av hva som må sjekkes:

• en diagnostisk analyse, altså ett eller to konkrete problemer (fall, migrering, indeksering), er vanligvis 10-16 timer, altså 700-1 120 EUR netto;
• en full analyse med rekkefølge på tiltakene er vanligvis 32-50 timer, altså 2 240-3 500 EUR netto;
• et lite nettsted på opptil 500 adresser ligger nærmere den nedre grensen, og en butikk med tusenvis av adresser og filtre nærmere den øvre;
• språkversjoner legger vanligvis til 3-5 timer, og en pågående krise som må diagnostiseres, 4-8 timer.

I prisen inngår analysen, en rapport med anbefalinger, møtet der vi går gjennom den, og sjekken etter innføringen. Selve innføringen gjør teamet ditt, eller jeg priser den særskilt.

Uten tilgang til Search Console, CDN-panelet og hostingen kan jeg ikke sjekke den tekniske delen fullt ut, og jeg sier det før jeg priser. Da peker jeg på hva jeg ikke kan verifisere uten disse tilgangene, og snevrer inn omfanget tilsvarende. I teksten om SEO-konsultasjon beskrev jeg når en samtale om én beslutning holder i stedet for en analyse.

Vanlige spørsmål om SEO-analyse

Hvor bør du begynne?

Begynn med ett spørsmål: mister nettstedet trafikk, eller bygger det den ikke. Av svaret avhenger det om du først beskytter sidene som har plasseringer, eller leter etter søkeord det mangler sider for. Gjør deretter de tre gratis sjekkene fra svaret om å gjøre analysen selv: robots.txt, rapporten om indeksering i Search Console og en crawl med gratisversjonen av Screaming Frog. Hvis resultatet overrasker deg eller du ikke vet hva som bør rettes først, er det et godt tema for en konsultasjon.