Hur kontrollerar ni om en sida är indexerad i Google?
Kontrollera den exakta URL:en i rätt Search Console-egendom och läs först uppgifterna om Googles indexerade version. Öppna också adressen i webbläsaren och notera eventuell omdirigering och slutlig URL. Ni behöver åtkomst till webbplatsens egendom. Klistra in adressen i URL-inspektionen och öppna resultatet för den URL:en, inte för en liknande adress eller en annan språkversion.
Varför är indexering viktig för SEO?
Indexering gör det möjligt för sidans innehåll att ingå i Googles urval för sökresultat; den garanterar varken synlighet på en viss sökning eller en viss placering. En viktig tjänstesida som inte finns i indexet kan inte bidra med sitt innehåll till det urvalet. Därför bör ni kontrollera att rätt sida finns med innan ni utvärderar dess placeringar. Kontrollera de viktiga kanoniska sidorna, inte att varje filteradress eller dubblett indexeras. Google hittar vanligen sidor automatiskt; en manuell begäran är inte ett obligatoriskt steg för varje ny sida. Google beskriver hur indexet används när sökresultat väljs.
Hur använder ni URL-inspektionen steg för steg?
URL-inspektionen visar Googles uppgifter om en bestämd adress i den egendom ni har öppnat. Ha den fullständiga sidans URL till hands. Granska varje språkversion som en egen adress när den har en separat URL. Googles instruktioner för URL-inspektionen.

- Välj rätt egendom i Search Console. Öppna sidan i webbläsaren och notera om den omdirigerar; kontrollera att ni granskar den adress ni avser.
- Klistra in hela sidans URL i granskningsfältet högst upp och tryck på Enter. Välj inte bara startsidan när det är en artikel eller tjänstesida ni vill undersöka.
- Vänta tills Search Console har hämtat indexuppgifterna och visar resultatet. Läs statusen för just den inskrivna adressen.
Meddelandet om att uppgifter hämtas från Googles index hör till granskningen. Det är inte en bekräftelse på att en indexeringsbegäran har skickats eller att sidan har indexerats på nytt.

Hur skiljer ni indexstatus från resultatet av ett realtidstest?
Indexstatus beskriver Googles registrerade version; ett realtidstest undersöker den sida som går att hämta nu och visar inte om en ny version redan har indexerats. Använd skillnaden när en ändring är nyare än rapportens senaste genomsökning.
| Vad visas? | Hur ska uppgiften användas? |
|---|---|
| Adressen finns på Google | Sidan har indexerats. Kontrollera ändå vilken version och canonical uppgiften gäller; statusen lovar inte en placering eller trafik. |
| Adressen finns inte på Google | Öppna detaljerna om sidindexering och läs orsaken innan ni ändrar något. En avsiktlig dubblett behöver inte indexeras separat. |
| Realtidstestet hittar inget hinder | Det hjälper er att kontrollera en rättelse, men är inte bevis på indexering. Testet bedömer inte alla villkor och förutsäger inte Googles val av canonical. |
Notera vilken indexeringsstatus som visas, senaste genomsökning och vald canonical när uppgifterna finns. Öppna detaljerna för sidindexering för att se vad verktyget faktiskt har observerat. Välj därefter test av den aktuella URL:en om ni behöver undersöka en ändring som ännu inte syns i det indexerade underlaget. Googles instruktion för URL-inspektion beskriver skillnaden mellan underlagen och testets begränsningar.
Kan en site-sökning ersätta kontrollen i Search Console?
Nej. En site-sökning är en kompletterande kontroll, inte en fullständig förteckning över Googles index. Ett illustrativt sökexempel är site:example.com. Om en adress saknas bland resultaten räcker det inte som bevis för att den är oindexerad. Kontrollera den exakta adressen i URL-inspektionen; använd inte antalet site-resultat som ett exakt mått på indexerade sidor. Google förklarar begränsningarna för site-operatorn.
Vad betyder ”Crawled – currently not indexed” och ”Discovered – currently not indexed”?
”Crawled – currently not indexed” betyder att Google har hämtat sidan utan att indexera den. ”Discovered – currently not indexed” betyder att adressen är känd men ännu inte hämtad. Googles dokumentation om sidindexering förklarar statusarna.
Statusen ensam visar inte att texten är dålig eller att sidan ska tas bort. Undersök den aktuella adressens åtkomst, innehåll, länkar och avsedda roll innan ni väljer åtgärd.
Vilka statusar behöver åtgärdas?
Åtgärda en status när den strider mot vad just den URL:en ska göra. En avsiktligt borttagen sida behöver inte indexeras, och en gammal adress som leder till rätt ersättare behöver inte visas som en egen sida. Skilj därför önskat beteende från ett faktiskt hinder innan ni ändrar inställningar.
| Status eller observation | Vad ska kontrolleras? | Nästa steg |
|---|---|---|
| Omdirigerad sida | Har sidan ersatts av rätt fungerande adress? | Inspektera måladressen och använd den i interna länkar. |
| 404 eller 410 | Är sidan avsiktligt borttagen eller saknas den av misstag? | Återställ en sida som ska finnas. Behåll inte en trasig adress i navigationen. |
| Soft 404 | Visar svaret tomt innehåll eller ett fel trots att servern säger att hämtningen lyckades? | Rätta innehållet eller låt serverns svar motsvara att sidan saknas. |
| Serverfel, exempelvis 500 | Går felet att återskapa och finns det serverloggar? | Utred driften innan ni skickar fler indexeringsbegäranden. |
| Alternativ sida med avsedd canonical | Representerar rätt huvudadress samma innehåll? | Bekräfta huvudadressen; försök inte indexera varje dubblett. |
| Utesluten av noindex | Ska sidan vara sökbar eller är undantaget avsiktligt? | Ändra regeln endast för sidor som ska kunna indexeras. |
Statusarnas tekniska innebörd beskrivs i Googles dokumentation om HTTP-svar och rapporten om sidindexering. Tabellen är ett beslutsstöd, inte en diagnos av er webbplats.

Vad är skillnaden mellan robots.txt och noindex?
Robots.txt styr hämtning och är inte en säker metod för att hålla en URL utanför sökresultaten. En noindex-instruktion behöver kunna läsas av sökmotorn för att fungera som avsett. Google förklarar skillnaden.
Blockera därför inte hämtningen och anta samtidigt att Google säkert har sett en ny noindex-instruktion. Kontrollera det faktiska tillståndet.
Var kan en noindex-regel finnas?
Noindex kan anges i sidans robots-meta-tagg eller i HTTP-svaret som X-Robots-Tag. Kontrollera därför både den levererade HTML-koden och svarshuvudena. Att ta bort regeln i ett administrationsfält räcker inte om en mall eller serverregel fortfarande skickar den. Google stöder inte en noindex-rad i robots.txt. Se Googles dokumentation om noindex.
Illustrativt exempel: en ny tjänstesida har öppnats för besökare efter en testperiod men ärver fortfarande noindex från testmiljön. Ta först ställning till att sidan ska vara offentlig och sökbar, rätta den källa som skickar regeln och testa den publicerade adressen. Noindex är inte en åtkomstkontroll som skyddar konfidentiella uppgifter. Privata test- eller kundsidor behöver fortfarande lämpligt åtkomstskydd, exempelvis inloggning.

Hur påverkar dubbletter och sidans innehåll indexering?
Dubbletter kan samlas under en representativ adress, medan sidans innehåll bedöms som en del av indexeringen. Ett eget svar garanterar inte indexering. Om två adresser visar samma text ska ni inte automatiskt skriva en tredje version. Bedöm först om adresserna är dubbletter, språkversioner eller faktiskt olika erbjudanden. Canonical används för representativ adress, inte för att göra två olika kundbehov till samma fråga.
En ny sida bör även gå att nå från relevant innehåll på webbplatsen. Läs om interna ingångar till sidor.
Hur undersöker ni en oväntad canonical?
Jämför den adress ni avsett med den adress Google har valt och kontrollera vad båda faktiskt visar. Är innehållet en dubblett, eller beskriver sidorna olika tjänster? Kontrollera därefter vilken adress interna länkar, sitemap och sidans canonical anger. Googles vägledning om canonical förklarar signalerna; en vald preferens är inte en order som garanterat följs.
Illustrativt exempel: en gammal adress och en ny adress visar samma guide. Dokumentera vilken som ska vara huvudadress och samordna signalerna kring den. Om adresserna i stället beskriver två självständiga erbjudanden ska innehållets skillnad utredas, inte döljas genom att båda pekar mot samma canonical.
Hur följer ni upp en rättelse av sidan?
Dokumentera vad som ändrats och kontrollera status efteråt. Att skicka samma begäran många gånger ersätter inte en löst åtkomstfråga eller ett bättre innehåll.
Hur begär ni indexering efter en rättelse?
Efter en rättelse kan en ägare eller fullständigt behörig användare begära indexering av en enskild URL i Search Consoles URL-inspektion. Funktionen gäller den granskade adressen. En redan indexerad sida kan behöva granskas på nytt efter en ändring; den behöver inte skickas in upprepade gånger bara för att den finns i indexet.

- Granska den exakta URL:en med ett konto som är ägare eller har fullständig behörighet. Kontrollera att rätt adress visas på resultatsidan.
- Läs eventuella hinder. Om sidan har rättats sedan den senaste genomsökningen, kör ett realtidstest och kontrollera den publicerade versionen innan ni går vidare.
- Välj Begär indexering på granskningsresultatet när ni vill begära en ny genomsökning av den tillgängliga sidan.
- Vänta på det snabba testet. Om verktyget bedömer att sidan inte kan indexeras behöver hindret åtgärdas; fler klick på samma begäran löser det inte.
- Notera datumet och eventuell bekräftelse på mottagen begäran. Följ sedan indexstatusen separat. Bekräftelsen betyder inte att sidan redan har lagts till i indexet.
Google begränsar antalet begäranden. Att skicka samma URL flera gånger gör inte genomsökningen snabbare, och en begäran garanterar inte indexering. Googles anvisning för en ny genomsökning.
Illustrativt exempel: en avsedd offentlig sida hade noindex. Efter att instruktionen har ändrats behöver det aktuella testet kunna läsa den nya versionen. Googles dokumentation om noindex beskriver instruktionens funktion och hur den kan kontrolleras. Därefter kan en behörig användare begära indexering. Ett godkänt åtkomsttest är fortfarande inte ett besked att sidan redan är indexerad. Registrera ändringsdatumet och jämför det med den senare indexeringsinformationen.
Hur skickar ni en sitemap till Google Search Console?
En ägare till Search Console-egendomen kan skicka in adressen till en publicerad sitemap via rapporten Webbplatskartor. Att filen tas emot garanterar inte att dess sidor indexeras. En sitemap, eller webbplatskarta, samlar adresser som Google ska kunna upptäcka. Den är användbar för många nya eller uppdaterade URL:er och kompletterar relevanta interna länkar.
- Hitta webbplatsens verkliga sitemap-adress i publiceringssystemet eller dess dokumentation. Exempel kan vara https://example.com/sitemap.xml eller https://example.com/sitemap_index.xml, men filnamnet måste stämma med er webbplats.
- Kontrollera att filen finns och är tillgänglig för Googlebot utan inloggning. Stäm av att den anger rätt kanoniska adresser till sidor som ni vill ha i sökresultaten.
- Öppna rätt egendom med ägarbehörighet och välj rapporten Webbplatskartor. Ange sitemap-filens adress i fältet för en ny webbplatskarta och skicka in den.
- Läs resultatet i rapporten. Om hämtning eller bearbetning misslyckas, öppna felinformationen och rätta filen eller åtkomsten.
- Följ senare upp de viktiga sidornas indexering. En lyckad inläsning av sitemap-filen är ett annat resultat än att varje listad sida har genomsökts och indexerats.
Skicka filens URL, inte bara domänens startsida. Om fältet redan visar ett adressprefix ska den del ni fyller i tillsammans med prefixet bilda exakt sitemap-adress, utan dubbel domän. Exemplen ovan är exempeladresser, inte en uppgift om var er egen fil ligger. Google beskriver inskickning, ägarbehörighet och felstatusar.
En sitemap kan hjälpa Google att hitta sidor men ersätter inte åtkomst, indexerbart innehåll eller intern länkning. Välj de URL:er som ska representera innehållet, inte varje teknisk variant. Googles instruktioner för att bygga en sitemap och begränsningarna för vad en sitemap garanterar.
Hur lång tid tar en ny genomsökning?
En ny genomsökning kan enligt Google ta från några dagar till några veckor. Det är ett intervall för genomsökning, inte ett löfte om när sidan indexeras eller får en placering. Följ statusen i Search Console; en begäran garanterar inte att sidan tas med i sökresultaten. Samma Google-vägledning om genomsökning anger den begränsningen.
Om ord som hämtning och rendering är oklara ger förklaringen av sökprocessens olika steg bakgrunden. Den här guiden används därefter för att kontrollera en faktisk URL, utan att gissa utifrån en enda status.
För ett konstaterat tekniskt problem finns SOVRA Digitals tekniska audit.
Vad behöver finnas i uppföljningen?
En användbar uppföljning skiljer den genomförda rättelsen från ett senare observerat resultat. Spara underlaget för den specifika URL:en så att nästa kontroll kan jämföras med samma sida:
- Före: avsedd uppgift, rapporterad status, senaste genomsökning och vald canonical.
- Ändring: vad som rättades, i vilken datakälla och när det publicerades.
- Direkt kontroll: svar från servern, instruktioner och innehåll som finns i den publicerade versionen.
- Senare kontroll: nytt datum för genomsökning, aktuell indexstatus och eventuell ändrad canonical.
- Slutsats: vad underlaget visar och vad som fortfarande är okänt.
Googles URL-inspektion skiljer uppgifter om den indexerade versionen från ett aktuellt test. Om rapporten fortfarande bygger på tiden före rättelsen visar den inte att den nya versionen har underkänts. Att en sida sedan blir indexerad visar i sin tur inte att den får trafik eller en viss placering.
Koppla indexeringskontrollen till rätt åtgärd
SOVRA Digital undersöker tekniska hinder och väger dem mot sidans innehåll och uppgift. Audit och tekniskt arbete ingår i SEO-paketet och prioriteras inom uppdragets avtalade kapacitet.

