Fel gällande genomsökning och indexering i Google Search Console uppstår när Googlebot inte kan nå dina sidor, har problem att läsa dem, blockeras tekniskt eller bedömer att den aktuella URL:en inte är värd att indexera. För att lösa detta behöver du först definiera felets omfattning, köra live-test med URL-inspektionsverktyget, och systematiskt kontrollera robots.txt, noindex, canonical, omdirigering, serverstatuskod, sitemap och innehållskvalitet. Det bästa är att börja med de sidor som påverkar trafik och intäkter mest, och arbeta stegvis – försök inte åtgärda alla varningar samtidigt.
Denna guide är utformad som en praktisk checklista för Hostragons blogg. Målet är att hjälpa dig tolka rapporterna om täckning och indexering i Search Console, identifiera felens verkliga orsaker och skapa hållbara tekniska SEO-förbättringar. För e-handel, företagswebbplatser, bloggar, nyhetssajter och projekt med många URL:er påverkar crawlbudget, serverhälsa och rätt indexeringsstrategi direkt synligheten.
Vad är skillnaden mellan genomsökning och indexering?
Genomsökning innebär att Googlebot upptäcker och försöker få tillgång till dina sidors HTML, bilder, CSS, JavaScript och andra resurser. Indexering är när Google analyserar den genomsökta sidan och avgör om den ska visas i sökresultaten. En sida kan vara genomsökbar men ändå inte indexeras. På samma sätt kan en URL finnas i sitemap men blockeras av robots.txt, noindex eller serverfel och därmed inte bearbetas av Google.
Ett exempel: En produktsida finns i sitemap.xml, den är åtkomlig via interna länkar och returnerar statuskod 200. Men om HTML-källan innehåller noindex-tagg, kommer Google att genomsöka sidan men inte indexera den. I ett annat scenario saknas noindex, men servern returnerar ett 500-fel vid hög trafik – då får Googlebot inte tillförlitlig åtkomst och indexeringsprocessen fördröjs.
Vilka rapporter bör du först titta på i Google Search Console?
Enligt SEO-standarder 2026 är korrekt data det första steget i problemlösning. I Search Console bör rapporterna Sidor, Sitekartor, URL-inspektion och Genomsökningsstatistik analyseras tillsammans. Det är missvisande att bara lita på en rapport. Exempelvis kan en URL som visas som ”Ej indexerad” i Sidrapporten ändå vara indexerbar vid ett live-test med URL-inspektionen – detta beror ofta på skillnaden mellan Googles senaste genomsökning och din senaste åtgärd.
1. Sidrapporten
Sidrapporten visar vilka URL:er som är i index, vilka som är exkluderade och vilka feltyper som finns. Målet är inte att få alla exkluderade URL:er indexerade. Exempelvis varukorgsidor, filterkombinationer, interna sökresultat och dubbla parametrar exkluderas medvetet. Prioritera kategori-, produkt-, tjänste-, blogg- och varumärkessidor som ska generera organisk trafik.
2. URL-inspektionsverktyget
URL-inspektionen är det mest pålitliga verktyget på sidnivå. Här ser du senaste genomsökningsdatum, crawl-status, användarvalda canonical, Googles valda canonical och om sidan är indexerbar. När du arbetar med ett fel, kör live-test på samma URL och skicka indexeringsbegäran om åtgärden är lyckad. Men det är bättre att åtgärda grundorsaken än att manuellt skicka begäran för hundratals URL:er.
3. Sitekartor
Sitekartan är din vägledning till Google om vilka URL:er som är viktiga. Endast URL:er som returnerar 200, är self-canonical, saknar noindex och ska indexeras bör finnas i sitemap. Om en sitemap med 10 000 URL:er innehåller 3 000 omdirigerade eller 404-URL:er slösar du Googlebots tid. Om du använder WordPress, kontrollera inställningarna för din SEO-plugin; vid specialbyggd lösning – kontrollera logiken för sitemap-generering. WordPress hosting-lösningar [iç-link: ...]
4. Genomsökningsstatistik
Genomsökningsstatistik visar hur ofta Googlebot besöker din site, antal requests, genomsnittlig svarstid och vilka statuskoder som mottas. Om svarstiden ökar, 5xx-fel blir vanliga eller robots.txt inte är åtkomlig påverkas din indexeringsprestanda. Under kampanjer, på nyhetssajter och i stora e-handelsprojekt är stark hosting-infrastruktur avgörande. högpresterande webbhotell [iç-link: ...]
Vanliga Google Search Console-fel och deras lösningar
Tabellen nedan sammanfattar de vanligaste fel och varningar i Search Console kring genomsökning och indexering – använd den som första checklista och följ sedan de detaljerade stegen under respektive rubrik.
| Fel eller varning | Möjlig orsak | Prioritet | Grundläggande lösning |
|---|---|---|---|
| Serverfel 5xx | Hosting, resursgräns, underhåll, mjukvarufel | Mycket hög | Granska loggar, öka resurser, åtgärda felaktiga plugins |
| Blockerad av robots.txt | Felaktig disallow-regel | Hög | Öppna viktiga kataloger, kör live-test |
| Noindex-tagg | Sid- eller mallinställning | Hög | Ta bort noindex från sidor som ska indexeras |
| Upptäckt, ej indexerad | Crawlbudget, låg kvalitet, långsam server | Medel-hög | Förbättra interna länkar, hastighet, unikt innehåll och sitemap |
| Genomsökt, ej indexerad | Innehållskvalitet eller liknande sidor | Medel | Berika sidan, kontrollera canonical och duplicerat innehåll |
| Omdirigeringsfel | Kedjor, loopar eller felaktig 301/302 | Hög | Skapa enkla 301-omdirigeringar |
| 404 – ej hittad | Borttagen URL, felaktig intern länk, gammal sitemap | Beroende på situation | Omdirigera vid behov, annars ta bort från sitemap och interna länkar |
Hur löser man serverfel 5xx?
5xx-fel betyder att Googlebot stöter på serverproblem när den försöker nå sidan. 500, 502, 503 och 504 är vanligast. Dessa är kritiska – om Google bedömer din server som instabil minskas crawl-frekvensen. 503 under kort underhåll är okej; men långvariga 5xx kan leda till indexförlust.
Praktisk checklista
- Kontrollera CPU, RAM, disk I/O och processgränser i din hostingpanel.
- Granska serverloggar för återkommande PHP-, MySQL- eller applikationsfel.
- Om du använder WordPress – testa tillfälligt senaste tema, plugin eller säkerhetsinställningar.
- Kontrollera om intensiv bottrafik, skadliga requests eller DDoS förekommer.
- Implementera cache-system, CDN och databasoptimering.
Exempel: Om en e-handel med 20 000 produkter får tunga databasfrågor vid Googlebot-besök och kategorisidor ger 504 timeout, räcker det inte att bara be Search Console att verifiera. Förbättra först databasindex, sidindelning, cache och hostingresurser. Vid tillväxt – uppgradera från delad hosting till VPS eller hanterad server för bättre crawlhälsa. VPS-serverlösningar [iç-link: ...]
Hur rättar man crawl-blockeringar i robots.txt?
Robots.txt instruerar sökmotorer om vilka delar som får genomsökas. Ett felaktigt kommando kan påverka hela sajtens synlighet. Om tillfälliga blockeringar glöms att tas bort vid lansering, kan Google missa viktiga sidor.
Grundläggande kontrollpunkter:
- Din robots.txt ska vara åtkomlig på dittdomän.se/robots.txt.
- Disallow: / ska aldrig användas på en live-site – det blockerar hela webbplatsen.
- Blockera inte CSS- eller JavaScript-filer i onödan – Google behöver rendera sidor korrekt.
- Sitekarta ska anges i robots.txt.
- Blockera admin, varukorg, användarkonto etc. – men inte kategorier eller innehåll.
Robots.txt är inte ett verktyg för att ta bort sidor från index. Om en URL redan är indexerad och sedan blockeras, kan Google inte återbesöka sidan och se noindex-tagg – den kan bli kvar i sökresultaten utan beskrivning. För att ta bort sidan ur index: tillåt först genomsökning, lägg till noindex, och därefter vid behov permanent borttagning.
Noindex-fel: När är det ett problem och när är det rätt strategi?
Noindex säger åt Google att inte indexera sidan. Det är ingen teknisk fel om det används korrekt enligt SEO-strategi. Problemet uppstår om noindex finns på sidor som ska generera organisk trafik. I WordPress är det vanligt att ”Blockera sökmotorer” är aktiverat, SEO-plugins sätter fel innehållstyp som noindex eller custom-mallar har fel meta-taggar.
Kontrollera i URL-inspektionen om sidan är indexerbar. Titta sedan i sidans källkod efter robots meta-tag och HTTP X-Robots-Tag. För PDF, bilder och fil-URL:er kan X-Robots-Tag användas. Om sidan är viktig: ta bort noindex, se till att den ger 200-status, finns i sitemap och har interna länkar.
Upptäckt, ej indexerad – vad innebär det?
Det betyder att Google känner till URL:en men ännu inte valt att genomsöka den. Vanligt på stora sajter med många nya produkter eller blogginlägg. Google fördelar crawlbudget baserat på sajtens auktoritet, serverrespons, URL-kvalitet och interna länkar. Om du skapar tusentals lågkvalitativa URL:er kan viktiga sidor få fördröjd genomsökning.
Lösningssteg
- Stöd viktiga URL:er med interna länkar från startsida, kategorier och relaterat innehåll.
- Ha endast rena, indexerbara URL:er i sitemap.
- Optimera sidans laddningstid – särskilt TTFB ska vara konsekvent låg.
- Undvik onödig tillväxt av filter-, sorterings- och parametrar-URL:er.
- Lägg till unika beskrivningar, pris, lagerstatus, bilder, tekniska detaljer och användbara data.
Exempel: Om ett webbhotell skapar 200 sidor för olika paketkombinationer med snarlika texter, ökar antalet ”upptäckt men ej genomsökt”. Välj istället sidor med verklig sökintention och lägg till unika jämförelser, användningsscenarier, prisinformation och tekniska specifikationer.
Genomsökt, ej indexerad – hur åtgärdar du?
Denna varning betyder att Google har genomsökt sidan men valt att inte indexera den. Oftast beror det på innehållskvalitet, repetitiv sidstruktur, lågt informationsvärde eller canonical-signal. Google indexerar numera sidor som verkligen bidrar till användaren, inte bara tekniskt tillgängliga.
För att lösa: öka sidans unika värde. Om du har en generell tjänstesida på 150 ord – gör den till en djupgående resurs som besvarar användarfrågor, förklarar tekniska egenskaper, prislogik, visar bilder och länkar till relaterade sidor. Utöka inte bara ordmängden; lägg till verkliga exempel, tabeller, jämförelser och information som underlättar beslut. SEO-anpassad webbsidesguide [iç-link: ...]
Canonical-fel och dubblett-URL-problem
Canonical-tagg bestämmer vilken version av liknande eller duplicerade sidor som är huvud-URL. I e-handel är det vanligt att parametrar för färg, storlek, sortering, filter och kampanjer genererar många URL:er med samma innehåll. Om Google väljer en annan canonical än du angett, ser du skillnad mellan användarvalda och Google-valda canonical i Search Console.
Lösning för canonical:
- Varje sida som ska indexeras ska vara self-canonical.
- Parametrar och duplicerade URL:er ska canonical-länka till relevant huvudsida.
- Canonical-målets URL ska returnera 200, sakna noindex och inte blockeras i robots.txt.
- Använd inte canonical och 301-omdirigering motstridigt.
- Lista endast canonical-URL:er i sitemap.
Felaktig canonical kan flytta synlighet från en välbyggd sida till en annan URL. Testa därför canonical-generering på mallnivå, särskilt för kategori-, produkt- och tjänstesidor.
Omdirigeringsfel – kedjor, loopar och felaktiga koder
Omdirigeringsfel uppstår när flyttade eller borttagna URL:er inte pekas rätt. Vanligast är omdirigeringskedjor, loopar, felaktig användning av 302 istället för 301, och konflikter mellan http-https samt www-versioner.
Ideal omdirigering: från gammal URL till ny i ett steg med 301. Om en gammal bloggpost flyttas till ny kategori, ska den inte först gå till http, sedan https, sedan www och slutligen till nya slug – detta sinkar både användarupplevelse och Googlebot. Vid SSL-migrering, uppdatera alla interna länkar, canonical-taggar och sitemap till https-version. SSL-certifikatsalternativ [iç-link: ...]
Hur hanterar man 404 och soft 404?
404 betyder att en URL inte finns. Alla 404 är inte dåliga. URL:er som är borttagna, utan alternativ och utan trafikvärde kan returnera 404 eller 410. Problemet är om viktiga sidor blir 404, sitemap innehåller 404-URL:er eller interna länkar leder till tomma sidor.
Soft 404 är när sidan returnerar 200 men innehållet beter sig som ”sidan hittades inte”. Om en utgången produktsida är tom men ger 200, tolkar Google det som soft 404. Om alternativ finns – omdirigera till relevant kategori eller likvärdig produkt med 301. Om inget alternativ finns – använd 410 för tydlig signal.
Sitemap-strategi: definiera vilka sidor som ska indexeras
Sitekartan ska presentera URL:er du prioriterar för Google. Vanligt misstag är att inkludera alla systemgenererade URL:er – men sitemap är inget avfall, utan ett kvalitetsfilter. URL:er som inte ska indexeras, omdirigerade adresser, noindex-sidor, parametrar, filter och 404 ska inte finnas i sitemap.
En bra sitemap kan delas upp efter innehållstyp: blogg, sida, kategori, produkt etc. Även om du inte når 50 000-URL-gränsen, ger modulär hantering bättre analys på stora sajter. Senaste uppdateringsdatum ska spegla verkliga förändringar; att markera alla URL:er som uppdaterade dagligen skapar ingen trovärdig signal. Vid ny domän – kontrollera DNS-inställningar för stabil Googlebot-åtkomst. domänregistrering och DNS-hantering [iç-link: ...]
Tekniska SEO-prioriteringar för att förbättra crawlbudget
Crawlbudget är hur många URL:er Googlebot väljer att genomsöka på din site under en viss tid. På små sajter är det sällan ett problem, men på projekt med tusentals URL:er kan felaktig URL-produktion och långsam server skada indexering.
Praktiska crawlbudget-tips
- Minska onödiga parametrar och ta bort dem från interna länkar.
- Öppna filter-URL:er selektivt om det finns sökintention, annars hantera med noindex eller canonical.
- Stärk internlänkningen; viktiga sidor ska inte vara djupare än tre klick från startsidan.
- Mät serverns svarstid regelbundet och matcha toppar med loggar.
- Kontrollera brutna interna länkar varje månad med crawlverktyg.
- Optimera bilder, CSS och JavaScript för att minska renderkostnad.
Erfarenhetsmässigt hjälper det Googlebot att genomsöka fler viktiga sidor om du bara rensar 404 och omdirigeringskedjor på stora sajter. Kvalitativa beskrivningar och relaterade produktlänkar på kategorisidor kan öka indexeringsgraden.
Steg-för-steg-plan för att lösa fel
Arbeta systematiskt med Search Console-fel enligt denna plan – det fungerar både för bloggar och företagsprojekt:
- Identifiera feltyp och antal URL:er som påverkas i sidrapporten.
- Prioritera sidor som genererar intäkter, leads eller trafik.
- Välj 5–10 exempel-URL:er per feltyp och kör live-test i URL-inspektionen.
- Kontrollera serverstatus, robots.txt, noindex, canonical, sitemap och internlänkar.
- Hitta grundorsaken och lös på mall- eller systemnivå, inte enskilda URL:er.
- Övervaka loggar och Search Console-rapporter i 7–28 dagar efter åtgärd.
- Om det lyckas – bekräfta i Search Console och använd samma kontroll på andra URL-grupper.
Viktigt: Search Console-data är fördröjd, inte realtidsuppdaterad. Ett åtgärdat fel kan synas kvar i rapporten några dagar eller veckor. Kombinera live-test, serverloggar och verkliga statuskoder för att bedöma läget.
När ska du misstänka hosting-relaterade problem?
Alla indexeringsproblem är inte hostingrelaterade, men vissa tecken pekar på infrastrukturen. Om svarstiden ökar i genomsökningsstatistik, 5xx-fel dyker upp vid vissa tider, CPU-gräns nås vid botbesök eller sajten är långsam under trafik – se över ditt hostingpaket. Stabil DNS, uppdaterad PHP, tillräcklig CPU/RAM, snabb disk, backup och säkerhet är grundläggande för teknisk SEO.
Exempel: Under kampanjer ökar organisk trafik tre gånger och Googlebot besöker samtidigt – svag infrastruktur kan ge 503-fel, vilket inte bara är användarförlust utan indexeringsförlust. Skalbar hosting, rätt cache-konfiguration och SSL-kontinuitet stödjer SEO direkt. företagshosting-paket [iç-link: ...]
Slutlig checklista – innan lansering
- Returnerar viktiga sidor statuskod 200?
- Blockerar robots.txt viktiga kataloger?
- Finns noindex endast på sidor som medvetet ska exkluderas?
- Pekar canonical-taggar på rätt huvud-URL?
- Består sitemap enbart av rena, indexerbara URL:er?
- Finns det enkla 301-omdirigeringar från HTTP till HTTPS och gamla URL:er till nya?
- Är 404-sidor borttagna från interna länkar och sitemap?
- Finns återkommande 5xx eller timeout för Googlebot i serverloggar?
Denna lista är grundläggande för teknisk SEO-underhåll. Kör en omfattande crawl varje månad, exportera Search Console-data och dokumentera ändringar – det hjälper dig att snabbt identifiera framtida indexeringsproblem.
Vanliga frågor
När syns resultat efter att Search Console-fel har åtgärdats?
Beroende på feltyp och sajtens crawl-frekvens tar det några dagar till några veckor. Live-test visar aktuell status; rapporten i Search Console kan vara fördröjd.
Är ”upptäckt, ej indexerad” alltid negativt?
Nej. Google kan välja att genomsöka nya eller lågprioriterade URL:er senare. Men om det gäller viktiga sidor – förbättra internlänkar, sitemap, sidhastighet, serverrespons och innehållskvalitet.
Jag tog bort noindex-taggen – varför indexeras sidan inte?
Google behöver genomsöka sidan igen. Kontrollera att sidan inte blockeras i robots.txt, att canonical pekar rätt, att den returnerar 200 och att innehållet är av hög kvalitet.
Måste jag alltid omdirigera 404-fel med 301?
Nej. URL:er utan alternativ, trafik eller länkvärde kan vara 404 eller 410. Viktiga URL:er med ersättning ska omdirigeras till relevant sida med 301.
Påverkar hostingval indexering?
Ja. Långsamma svarstider, resursbegränsningar, återkommande 5xx-fel och instabil SSL/DNS kan minska Googlebots crawl-effektivitet. Stabil och snabb hosting är avgörande för teknisk SEO.
Sammanfattningsvis: Genomsöknings- och indexeringsfel i Google Search Console ger värdefulla signaler för att förbättra sajtens tekniska hälsa. Identifiera först viktiga URL:er, verifiera fel med live-test och loggar, och kontrollera robots.txt, noindex, canonical, omdirigering, sitemap, innehållskvalitet och serverprestanda systematiskt. Vill du ha snabbare, säkrare och mer stabil infrastruktur – utforska Hostragons hosting-, domän- och SSL-lösningar för rätt grund till din sajt.