WordPress SEO: kontrollera det sajten faktiskt levererar

Varför WordPress-standardinstallationen inte är en garanti

WordPress levereras med rimliga grundinställningar, men plattformen gör inga antaganden om hur du kombinerar tema, plugins och cachelagring. Resultatet av den kombinationen avgör vad en sökmotor faktiskt ser – inte vad du ser när du är inloggad i wp-admin. Det är en distinktion som är lätt att missa och dyr att ignorera.

En välkänd SEO-plugin kan visa gröna bockar i sitt eget gränssnitt och ändå leverera fel HTML om temat har en aktiv wp_head-hook som skriver egna metataggar. En cache-plugin kan servera en version av sidan från timmar sedan, innan du sparade dina ändringar. Publiceringsläget kan vara satt till noindex på hela sajten sedan staging-perioden, ett klassiskt misstag som ger vitt utseende i frontend men blockerad crawling i bakgrunden.

Det här är inte abstrakta risker. De är konkreta tekniska tillstånd som kräver konkret verifiering. Den enda pålitliga metoden är att hämta rå sidkälla – via webbläsarens källvisning eller ett kommandoradsverktyg – och läsa vad som faktiskt levereras. Plugin-dashboardens visning är aldrig bevis; sidkällan är beviset.

Den här artikeln ger dig ett strukturerat kontrollprotokoll för fem sidtyper som finns på nästan varje WordPress-sajt: bloggpost, tjänstesida, arkiv, intern sökresultatsida och kontaktsida. För varje typ beskriver vi vad du ska leta efter, hur du diagnostiserar avvikelser och vilket beslut som följer av varje fynd. Målet är att du ska ha en färdig kontrolljournal när du är klar, inte en lista med saker att göra senare.

Grundförberedelse: backup, staging och rollback innan du rör något

Innan du ändrar en enda inställning i en produktionssajt behöver du tre saker på plats: en verifierad backup, en fungerande stagingmiljö och en dokumenterad rollback-rutin. Ordningen är inte förhandlingsbar.

En backup är bara ett backup om du har bekräftat att den går att återställa. Exportera databasen och filerna, återställ dem i en testmiljö och verifiera att sajten fungerar. Många backup-plugins ger dig en ZIP-fil du aldrig har öppnat och aldrig har återställt. Det är inte ett backup; det är en känsla av trygghet.

Stagingmiljön ska vara en identisk kopia av produktionssajten, inklusive samma tema, samma plugins i samma versioner och samma databas. Det räcker inte med en ren WordPress-installation med samma tema – plugin-kombinationerna är precis det som skapar de tekniska tillstånd du ska diagnostisera. Om din webbhotellsplattform erbjuder en inbyggd stagingfunktion, använd den. Om inte, är en separat installation på en subdomain med lösenordsskydd ett acceptabelt alternativ, förutsatt att du bekräftar att den lösenordsskyddet inte läcker igenom till robots.txt eller sitemap.

Rollback-rutinen är proceduren du följer om en ändring ger fel resultat: vilka steg, i vilken ordning, och vem som utför dem. Skriv ner den. En muntlig rutin glöms bort i det ögonblick något går fel på riktigt.

Ägarskap per metadatafält: ett plugin, en funktion

Det vanligaste källan till tekniska SEO-problem i WordPress är inte ett trasigt plugin – det är att två eller fler funktioner skriver samma metadatafält med olika värden. Resultatet är duplicerade taggar i HTML:en, och det är inte självklart vilket värde som vinner.

Dubbla metataggar kan komma från flera tillägg eller från både tema och tillägg. Det är ett tillstånd som uppstår gradvis: du installerar ett SEO-plugin, temat har en inbyggd SEO-funktion som du inte inaktiverar, och plötsligt levererar sidkällan två <link rel="canonical">-taggar med olika URL:er. Ingen av dem är nödvändigtvis fel i sig – men de är i konflikt med varandra, och det är sämre än att ha en enda korrekt tagg.

Principen är enkel: välj en ägare per fält. Om ditt SEO-plugin hanterar canonical, titel och robots-meta, ska temats SEO-funktioner vara inaktiverade. Om du använder temats egna title-generation, ska pluginets title-funktion vara avstängd. Det spelar ingen roll vilket du väljer – det spelar roll att du väljer ett och inaktiverar det andra.

Verifieringen sker alltid i sidkällan. Sök på <link rel="canonical" och räkna antalet förekomster. Sök på <meta name="robots" och kontrollera att det bara finns ett direktiv. Sök på <title> och bekräfta att det bara finns en tagg. Om du hittar mer än en förekomst av något av dessa fält, spåra ursprunget innan du ändrar något. Vår guide om canonical, robots och indexering går igenom de specifika direktiven och deras semantik om du behöver fördjupning där.

För att spåra ursprunget: inaktivera plugins ett i taget på staging, ladda om sidkällan och notera vilken tagg som försvinner. Det är ett metodiskt arbete, men det är det enda sättet att veta säkert. Plugin-inställningspanelen berättar inte vad temat gör; sidkällan berättar vad båda gör tillsammans.

Kontrollera publiceringsläge och crawling-tillgänglighet

WordPress har ett val för sökmotorsynlighet under läsinställningarna. Kontrollera alltid vad den installerade versionen, temat och tilläggen faktiskt levererar. WordPress tog bort det automatiska globala Disallow-värdet från sin standardfunktion redan i version 5.3; robotstaggar och åtkomst är separata frågor. WordPress funktion för robots.txt visar standardbeteendet. En testmiljö med känsliga uppgifter behöver faktisk åtkomstkontroll, inte enbart noindex.

Kontrollera denna inställning explicit som det första steget i varje revision. Hämta sedan robots.txt direkt – https://din-domän.se/robots.txt – och läs den. Om du ser Disallow: / och inte vet varför, stoppa upp och spåra varifrån det kommer. Det kan vara WordPress grundinställning, ett cache-plugin, ett säkerhetsplugin eller ett manuellt redigerat robots.txt-fält i ditt SEO-plugin.

Kontrollera därefter att sidtyper du vill indexera faktiskt levererar index, follow eller helt saknar robots-meta (vilket är standardbeteendet för indexering). Sidtyper du inte vill indexera – arkiv du duplicerar innehåll på, interna sökresultat, mediebilagor – ska explicit leverera noindex. Bekräfta detta i sidkällan för representativa URL:er från varje sidtyp, inte bara för startsidan.

Lösenordsskyddade sidor är ett specialfall. WordPress lägger automatiskt till noindex på lösenordsskyddade sidor, vilket är korrekt beteende. Men om du har ett lösenordsskyddat staging-område som du av misstag pekar mot med en canonical, kan du skicka indexeringssignaler till en URL som inte är tillgänglig. Kontrollera canonical-värden mot tillgänglig URL – de ska stämma överens.

Bloggpost och tjänstesida: kontrollista för individuella sidor

Individuella innehållssidor – oavsett om de är klassiska blogginlägg eller tjänstesidor byggda med ett sidbyggarverktyg – har en gemensam uppsättning tekniska element att kontrollera. Gå igenom följande för en representativ URL av varje typ:

1. Hämta sidkällan med Ctrl+U i webbläsaren eller med curl -s https://din-domän.se/din-sida/ | head -100 i terminalen.
2. Sök på <title>. Bekräfta att det bara finns en tagg, att innehållet matchar det du skrivit i SEO-pluginet och att det inte innehåller defaultvärdet "Just another WordPress site" eller liknande.
3. Sök på canonical. Bekräfta att det bara finns en tagg och att URL:en är den kanoniska versionen av sidan inklusive eller exklusive avslutande snedstreck, konsekvent med resten av sajten.
4. Sök på meta name="robots". Bekräfta att direktivet är index, follow eller att taggen saknas (vilket ger samma effekt).
5. Sök på din H1-rubrik eller ett unikt textstycke från brödtexten. Om texten inte finns i sidkällan renderas den med JavaScript och är inte synlig i rå HTML. Det är ett separat problem som beskrivs i vår guide om JavaScript SEO och läsbar HTML.
6. Kontrollera att eventuell strukturerad data finns i sidkällan som <script type="application/ld+json">. Om du lägger till strukturerad data via ett plugin, bekräfta att schemat faktiskt renderas. Vår genomgång av strukturerad data och korrekt beskrivning ger vägledning för vad som bör och inte bör markeras upp.
7. Kontrollera OG-taggar (og:title, og:description, og:url) om sajten delas på sociala plattformar. Samma ägarprincip gäller: en källa per fält.
8. Spara fynden i en kontrolljournal med kolumnerna: URL, sidtyp, kontrollerat fält, förväntat värde, faktiskt värde, avvikelse, åtgärd, verifierad.

För tjänstesidor byggda med Elementor, Divi eller liknande sidbyggarverktyg: kontrollera explicit att brödtexten finns i sidkällan och inte är beroende av en JavaScript-komponent för rendering. Sidbyggarverktyg varierar kraftigt i hur de serialiserar innehåll i HTML.

Arkiv, kategorier och sökresultatsidor: den förbisedda indexeringsfrågan

WordPress genererar automatiskt arkivsidor för kategorier, taggar, författare, datum och egna taxonomier. Det genererar också en intern sökresultatsida för varje sökning som görs via sajtsökningen. Dessa sidtyper är sällan meningsfullt indexerbara och är ofta källan till duplicerat eller tunt innehåll.

Kategorisidor kan vara värdefulla om de har eget redaktionellt innehåll och tydlig inriktning. Mer ofta är de en automatiskt genererad lista av inlägg som delar ett ämnesord, utan något unikt innehåll. Taggsidor är nästan alltid tunnare än kategorisidor. Datumbaserade arkiv är i princip aldrig meningsfullt indexerbara. Kontrollera vad ditt SEO-plugin levererar för dessa sidtyper och bekräfta i sidkällan.

Sökresultatsidor är ett särskilt tydligt fall. WordPress genererar URL:er av typen ?s=sökterm för varje intern sökning. Dessa sidor bör leverera noindex – de är per definition dynamiska, oförutsägbara och duplicerar innehåll på ett osystematiskt sätt. Bekräfta att detta direktiv finns i sidkällan för en testad sökterm.

Mediebilagor är ett annat förbisett område. WordPress skapar per default egna URL:er för varje uppladdad bild eller fil, med en sida som nästan enbart innehåller en bild och lite automatgenererad metadata. Dessa sidor kan indexeras om du inte aktivt förhindrar det. De flesta SEO-plugins har en inställning för att redirecta mediebilagor till deras ursprungliga inlägg – bekräfta att denna redirect fungerar som förväntat med ett verktyg som curl och läs statuskoden i svaret.

Frågan om duplicerat innehåll i dessa sidtyper och hur du väljer rätt åtgärd beskrivs mer ingående i vår guide om duplicerat innehåll och rätt URL-val.

Bilder, alt-text och cachens roll i verifiering

Alt-text för bilder är ett grundläggande tillgänglighets- och innehållskrav. WordPress lagrar alt-text i mediebiblioteket som ett fält kopplat till bildfilen, men alt-texten kan också skrivas direkt i blockredigeraren eller via sidbyggarverktygets egna bildblock. Kontrollera i sidkällan att alt-attributet finns på meningsbärande bilder och att det är beskrivande, inte tomt och inte stuffat med nyckelord.

Bildernas filformat och komprimering påverkar sidhastighet, men det är ett optimeringsbeslut som kräver mätning av det faktiska resultatet, inte ett generellt krav. Det som alltid ska kontrolleras är att bilderna faktiskt levereras med korrekt HTTP-statuskod – en trasig bildreferens ger en 404 i sidkällan och skapar en onödig crawling-kostnad.

Cache är en av de vanligaste orsakerna till att verifieringen misslyckas på ett förvirrande sätt. Du ändrar en inställning, laddar om sidan, ser ingen förändring och drar slutsatsen att inställningen inte fungerar. Det enda sättet att utesluta cachen som orsak är att tömma den explicit och sedan verifiera sidkällan på nytt. Töm cache på flera nivåer: WordPress-pluginets cache, serverns opcode-cache om du har tillgång till den, och eventuell CDN-cache. Lägg till ett cache-tömningssteg som obligatorisk del av varje kontrolliteration.

En praktisk metod för att se om cachen serverar en gammal version: lägg till en unik parameter i URL:en som cache-pluginet troligen inte cachar, exempelvis ?nocache=1, och jämför sidkällan med och utan parametern. Om de skiljer sig, serverar cachen en gammal version av den vanliga URL:en.

WordPress SEO: kontrollera det sajten faktiskt levererar
https://rangel.se/guider/seo-for-wordpress/

LÄSARUPPGIFT
Genomför en strukturerad HTML-kontroll av fem sidtyper på din WordPress-sajt – bloggpost, tjänstesida, arkiv, sökresultat och kontaktsida – och dokumentera exakt vilket plugin eller temafunktion som äger varje metadatafält.

Granska det WordPress faktiskt levererar
[ ] Säkra staging och återställning
Underlag att dokumentera: Dokumentera backup, testmiljö, åtkomst och vilken fungerande version som kan återställas.
Mitt underlag:
Ansvarig / nästa steg:

[ ] Kontrollera fältägare och HTML
Underlag att dokumentera: Spara sidkälla för representativa sidtyper; ange vilken funktion som genererar metadata.
Mitt underlag:
Ansvarig / nästa steg:

[ ] Testa kundvägen efter ändring
Underlag att dokumentera: Rensa relevant cache och kontrollera huvudtext, navigation och kontaktformulär igen.
Mitt underlag:
Ansvarig / nästa steg:

Markeringarna är dina egna arbetsnoteringar, inte en granskning av RANGEL eller ett kvalitets-/rankingbetyg.

Kontaktsidan: formulärfunktion och teknisk korrekthet

Kontaktsidan är en sidtyp som ofta behandlas som en eftertanke i SEO-arbetet. Den ska indexeras, den ska ha en meningsfull titel och canonical, och dess formulär ska faktiskt fungera. Alla tre delarna kräver explicit kontroll.

Formulärtestning ska ske i ett inkognitofönster utan aktiva inloggningscookies och utan att vara inloggad i WordPress. Formulär som bygger på WordPress nonce-system för CSRF-skydd kan misslyckas om noncet har cachelagrats av ett cache-plugin. Fyll i formuläret med testdata och bekräfta att du får en bekräftelsesida eller ett bekräftelsemeddelande och att e-postmeddelandet faktiskt levereras till inkorgen.

Om formuläret inte fungerar: kontrollera att cache-pluginet undantar kontaktsidans URL från caching, eller att formuläret levereras via en specifik mekanism som hanterar nonces dynamiskt. Kontrollera också att din WordPress-installation kan skicka e-post. Den vanligaste orsaken till att kontaktformulär misslyckas i WordPress är inte ett trasigt plugin – det är att WordPress standardfunktion för att skicka e-post (PHP mail()) blockeras av webbhotellet. En SMTP-konfiguration via ett plugin löser detta i de flesta fall.

Kontrollera kontaktsidans sidkälla på samma sätt som övriga sidor: titel, canonical, robots-meta och att eventuell brödtext finns i HTML:en. Kontaktsidor är ofta enkla nog att de inte har problem med JavaScript-rendering, men bekräfta det.

Sitemap: vad levereras kontra vad som bör levereras

WordPress SEO-plugins genererar vanligtvis en XML-sitemap automatiskt. Kontrollera att sitemapen faktiskt är tillgänglig på den URL du förväntar dig – ofta /sitemap.xml, /sitemap_index.xml eller en anpassad URL angiven i plugin-inställningarna. Hämta den och läs den.

Kontrollera att sitemapen innehåller de URL:er du vill att den ska innehålla: publicerade inlägg och sidor med status "Publicerad", inte utkast eller lösenordsskyddade sidor. Kontrollera att sitemapen inte innehåller URL:er du inte vill att den ska innehålla: arkivsidor, sökresultatsidor, mediebilagor om du inte explicit vill inkludera dem.

Kontrollera att sitemapen är registrerad i Google Search Console. Det är ett separat steg från att skapa sitemapen – att skapa den gör den tillgänglig, att registrera den ger Google ett explicit tips om vilka URL:er du prioriterar. Observera att en registrerad sitemap inte garanterar indexering av de URL:er den innehåller; den är en inlämningssignal, inte ett indexeringskrav.

Om sitemapen ger 404-fel: kontrollera att permalink-strukturen i WordPress är inställd på något annat än "Vanlig" (den numeriska strukturen). En del sitemap-funktioner kräver att snygga permalänkar är aktiverade. Gå till Inställningar → Permalänkar och klicka Spara utan att ändra något – det regenererar rewrite-reglerna i .htaccess.

RANGELs kontrolljournal: beslut per sidtyp och metadatafält

Följande beslutstabell beskriver hur vi på RANGEL strukturerar den initiala tekniska kontrollen för en WordPress-sajt. Varje rad representerar ett kombinerat fynd av sidtyp och metadatafält, med de diagnostiska frågor som styr beslutet och de åtgärdsalternativ som är möjliga. Det är ett analytiskt ramverk, inte en automatisk checklista – beslutskolumnen kräver att du vet vad du vill att sidan ska göra.

Tabellen beskriver beslut och diagnostiska bevis – inte uppskattade tidsåtgångar eller förväntade effekter. Effekterna av tekniska åtgärder beror på sajtens specifika historia, dess nuvarande indexeringsstatus och hur länge ett felaktigt tillstånd har funnits. Det är inte möjligt att i förväg precisera vad en enskild åtgärd ger för mätbart resultat, och vi gör inga sådana påståenden.

Illustrativt typfall: e-handelssite med plugin-konflikt och felaktig sitemap

Följande är ett illustrativt hypotetiskt exempel konstruerat för att visa hur diagnostikprocessen fungerar i praktiken. Det baseras inte på en verklig klient eller verkliga mätdata.

Tänk dig en hypotetisk e-handelssite, vi kallar den Fabriken AB (illustrativt), som driver en WordPress-sajt med WooCommerce. Sajten har ett tema som innehåller inbyggda SEO-metafunktioner och ett SEO-plugin installerat parallellt. Inga av temats SEO-funktioner har inaktiverats vid plugin-installationen.

Kontrolljournal för bloggpost: Sidkällan visar två <link rel="canonical">-taggar. Den första pekar på https://fabriken.se/blogg/inlagg-1/ och genereras av SEO-pluginet. Den andra pekar på https://fabriken.se/?p=42 och genereras av temats wp_head-hook. Dessa är i konflikt. Diagnos: temat har en aktiv canonical-funktion som inte inaktiverades vid plugin-installationen. Beslut: inaktivera temats canonical-funktion i temainställningarna eller via en rad i functions.php på staging. Verifiering: hämta sidkällan efter cache-tömning och bekräfta att bara en canonical-tagg finns och att den pekar på den snygga permalänk-URL:en.

Kontrolljournal för sitemapen: Sitemap-URL:en är konfigurerad i SEO-pluginet som /sitemap_index.xml, men hämtning returnerar 404. Diagnos: permalink-strukturen är inställd på "Vanlig" (numerisk). Plugin-sitemapen kräver att rewrite-regler är aktiva. Beslut: gå till Inställningar → Permalänkar, välj en namedbaserad struktur och spara. Kontrollera att .htaccess har uppdaterats. Verifiera sitemapen på nytt. Transparent antagande: i detta exempel antas att webbhotellet tillåter .htaccess-reglering, vilket inte gäller alla konfigurationer.

Kontrolljournal för kategorisida: Kategorin "Nyheter" har 47 inlägg listade utan redaktionellt inledningstext. Sidkällan visar meta name="robots" content="index, follow". Diagnos: kategorisidan är indexerbar men har inget unikt innehåll utöver inläggslistningen. Beslut: antingen sätt noindex på kategorin via SEO-plugin, eller lägg till ett meningsfullt redaktionellt stycke i kategoriinställningarna i WordPress. Det är ett redaktionellt beslut, inte ett tekniskt, och kräver att webbplatsägaren tar ställning till om kategorin ska ha indexerbar status.

Det är tre materielt olika beslut från samma kontrolliteration: en plugin-ägarkonflikt, ett konfigurationsfel i permalink-struktur och ett redaktionellt val om indexeringsstatus. Alla tre kräver olika kompetens och olika åtgärder. Det är just denna differentiering som gör en strukturerad kontrolljournal värdefull framför en generisk checklista.

Om du vill granska din WordPress-sajts levererade HTML-struktur på ett systematiskt sätt kan du använda webbläsarens källvisning eller ett kommandoradsverktyg som curl för att identifiera vilka fält som faktiskt finns i sidkällan.

Interna länkar och sidstruktur som teknisk faktor

Intern länkning är en teknisk faktor i den meningen att den påverkar hur crawlers navigerar sajten och hur sidauktoritet potentiellt fördelas internt. Men det är också ett redaktionellt och strukturellt beslut: vilka sidor ska nås från vilka, och med vilka ankartexter.

I WordPress-sammanhang är den vanligaste tekniska bristen i intern länkning inte avsaknad av länkar – det är trasiga interna länkar, alltså länkar som pekar på URL:er som returnerar 404 eller 301. Trasiga interna länkar uppstår när du byter permalink-struktur, tar bort sidor eller ändrar kategorisluggar utan att uppdatera interna länkarna som pekar dit.

Kontrollera trasiga interna länkar med ett crawlverktyg som läser sidkällan och följer URL:er. Det behöver inte vara ett avancerat verktyg; Screaming Frog i sin gratisnivå täcker upp till 500 URL:er. Exportera listan med 404-felkoder och filtrera på intern källa. Åtgärda antingen genom att uppdatera länken i innehållet eller, om URL:en är permanent borttagen, genom att lägga en 301-redirect. Redirectlogik för WordPress beskrivs i detalj i vår guide om SEO-migrering och säker lansering; redirectkedjor och hur HTTP-hanteringen fungerar rent protokollmässigt kan du läsa mer om i MDN:s dokumentation om redirections i HTTP som ett komplement.

Ankartext i interna länkar bör vara beskrivande och varierande. WordPress blockredigerare gör det enkelt att lägga till interna länkar med fritt formulerad ankartext. Det primära syftet med intern länkning är att ge läsaren en begriplig väg genom webbplatsen, vilket vi diskuterar mer i vår genomgång av interna länkar och webbplatsstruktur.

Teknisk SEO-hjälp: när du ska eskalera och vad du kan förvänta dig

Den kontroll vi beskrivit i den här artikeln är något du kan genomföra själv om du är bekväm med att läsa HTML-källkod och navigera WordPress-administration. Det kräver inte avancerad teknisk kompetens – det kräver metodiskhet och tid.

Det finns situationer där en extern teknisk SEO-specialist är rätt resurs. Den tydligaste är om sajten nyligen genomgått en migrering – ny domän, ny plattform eller ny URL-struktur – och du ser tecken på att tidigare URL:er inte redirectas korrekt. Redirectkedjor och canonicalkonflikter i samband med migrering kräver systematisk kartläggning som är svår att hantera utan verktyg och erfarenhet. En annan situation är om sajten är starkt JavaScript-beroende för att rendera innehåll och du inte kan bekräfta i sidkällan att texten finns i HTML:en – det är ett arkitekturproblem, inte ett plugin-konfigurationsproblem, och det kräver en annan typ av analys. Vår SEO-checklista för blockerande problem hjälper dig avgöra vad som är kritiskt nog att prioritera.

Om du vill ha en extern bedömning av sajtens tekniska status erbjuder RANGEL teknisk SEO-genomlysning. Det är en analys av faktiska tekniska tillstånd – levererad HTML, crawl-tillgänglighet, indexeringsstatus och intern struktur – inte en generisk checklista med generella rekommendationer. Du hittar mer information och kan skicka en förfrågan via RANGELs tekniska SEO-tjänst. Observera att en förfrågan via formuläret registrerar din intresseanmälan och inleder en dialog, inte ett automatiskt köp eller en bindande order.

För den som vill fördjupa sig i hur strukturerad data kan beskriva specifika innehållstyper på ett korrekt sätt är Schema.org:s specifikation för Article en referens värd att ha till hands vid implementering av JSON-LD i WordPress. Det är en teknisk specifikation, inte en rankingmanual, och ska läsas som det.

Avslutningsvis: skilj ett korrekt konfigurerat tema från automatisk SEO-effekt. Ett snyggt tema som renderar snabbt och har korrekt HTML-struktur är en teknisk förutsättning, inte en garanti för organisk synlighet. Det tekniska arbetet vi beskrivit i den här artikeln handlar om att säkerställa att sajten inte aktivt hindrar sin egen crawling och indexering. Det är ett nödvändigt grundläge – men det är inte detsamma som att ha relevant, välstrukturerat innehåll som svarar på vad din målgrupp faktiskt söker efter. Båda delarna krävs. Den här artikeln hanterar den tekniska delen; innehållsarbetet är ett parallellt och lika viktigt spår.