En webbplats kan ha en vacker design, en grön cirkel i sitt SEO-plugin och ändå förlora besökare innan huvudinnehållet ens har laddats. Eller så indexerar Google en annan URL än den du förväntar dig. Eller så fungerar en beställning, men mätningen skickar den två gånger.
Därför börjar jag inte en teknisk granskning med att jaga hundra poäng i ett enda test. Först letar jag efter fel som hindrar affärer, indexering eller användning av webbplatsen. Först därefter putsar jag de små detaljerna.
1. Kontrollera att viktiga URL:er returnerar rätt status
Granska de viktigaste tjänstesidorna, artiklar som får trafik, kontaktsidan och konverteringsvägen. En viktig sida bör returnera 200. Innehåll som har flyttats permanent bör ha en enda direkt 301-omdirigering. En borttagen sida bör inte i tysthet hamna på startsidan.
Jag kontrollerar också HTTP och HTTPS, www- och icke-www-varianter, avslutande snedstreck och parametrar. Resultatet bör vara en enda kanonisk URL. Google beskriver en omdirigering som en stark signal för kanonisering och rekommenderar att den kombineras med en konsekvent canonical-tagg och webbplatskarta i sin dokumentation om kanoniska URL:er.
2. Kontrollera indexeringen ur den riktiga sidans perspektiv
Robots.txt, meta robots, canonical och webbplatskarta måste fungera tillsammans. Ett vanligt misstag är att indexera en sida som inte har någon plats i sökresultaten, samtidigt som viktigt innehåll blockeras. Använd URL-inspektion i Search Console för flera representativa URL:er. Där ser du vad Google känner till om sidan och kan testa liveversionen.
- Är den kanoniska URL:en den du vill använda?
- Är sidan tillgänglig utan inloggning eller blockering?
- Innehåller webbplatskartan bara indexerbara 200 URL:er?
- Undviker interna länkar omdirigeringar?
- Finns det viktiga föräldralösa sidor?
Google har en översikt över dessa områden i sin dokumentation om genomsökning och indexering.
3. Mät hastigheten hos människor, inte bara i labbet
PageSpeed Insights och Lighthouse är användbara diagnostikverktyg. Men ett labbtest är inte samma sak som riktiga besökares upplevelse. Dagens Core Web Vitals är LCP, INP och CLS; fältdata bygger på riktiga enheter och anslutningar. Den officiella dokumentationen om Web Vitals förklarar översikten och skillnaden mellan fält- och labbdata.
Jag skulle läsa prioriteringarna så här:
- LCP: när huvudinnehållet visas.
- INP: hur snabbt sidan reagerar på användning.
- CLS: om element hoppar runt under laddningen.
- TTFB och nätverk: om något över huvud taget börjar hända snabbt.
Google säger också uttryckligen att ett bra resultat inte garanterar topplaceringar. Den övergripande användbarheten är viktigare än att jaga ett enda tal. Se dokumentationen om sidupplevelse.
4. Hitta den verkliga orsaken bakom laddningen
I vattenfallsdiagrammet och DevTools letar jag efter lång svarstid från servern, blockerande CSS och JavaScript, för stora bilder, typsnitt, upprepade förfrågningar och tredjepartstjänster. Den gamla regeln att ”slå ihop alla filer” gäller inte längre överallt. Med moderna protokoll kan mängden oanvänd kod och blockering på huvudtråden spela större roll.
- Ladda huvudbilden i lämplig storlek och ett modernt format.
- Ange bildmått så att innehållet inte flyttas.
- Innehåll nedanför den första vyn kan använda inbyggd lazy loading.
- Ladda bara de typsnittsvikter och teckenuppsättningar som behövs.
- Ladda marknadsföringsskript asynkront och bara där de fyller en funktion.
- Komprimera textresurser och ange lång cachetid för versionshanterade filer.
En tredjepartstjänst kostar inte bara millisekunder. Varje pixel, chattwidget och värmekarta skapar ytterligare operativt ansvar och dataansvar. Om ingen använder rapporten, ta bort skriptet.
5. Gå igenom webbplatsen som kund med tangentbord och mobiltelefon
På mobilen går du igenom navigeringen, formuläret, cookiedialogen och beställningen. Förstora texten, stäng av bilderna och använd ett tangentbord. Rubrikerna bör bilda en begriplig struktur, ett formulär behöver etiketter och ett felmeddelande måste säga vad som ska åtgärdas.
Varje sida bör ha en huvuduppgift. Det betyder inte en knapp till varje pris, utan en tydlig hierarki. Hitta fler praktiska punkter i den grundläggande UX-checklistan.
6. Åtgärda resurs- och JavaScript-fel
Ett 404 för en bild, ett typsnitt eller ett skript är inte kosmetiskt. Det kan förstöra utseendet, mätningen eller funktionaliteten. Kontrollera fel i webbläsarkonsolen, misslyckade nätverksförfrågningar och upprepade 5xx-svar på servern. Testa kritiska flöden efter varje driftsättning.
7. Använd strukturerad data bara för sanningsenligt innehåll
Schema är inte ett sätt att tvinga fram stjärnbetyg. Det är en maskinläsbar beskrivning av det som faktiskt finns på sidan. Använd en typ som stöds och testa den i Rich Results Test. Google listar aktuella format och testverktyg som stöds i sin dokumentation om strukturerad data.
8. Mätningen får inte förstöra webbplatsen som den ska mäta
Ladda GA4, annonsplattformar och andra skript på ett icke-blockerande sätt. Namnge händelser efter beslut, inte efter varje klick. Kontrollera dubbletter, samtycke och om någon faktiskt använder datan. Hitta en praktisk grund i artiklarna om Google Tag Manager och Google Analytics 4.
9. Pengar och risk avgör ordningen på åtgärderna
- En trasig beställning, ett trasigt formulär eller en trasig inloggning.
- En viktig sida som inte är tillgänglig eller indexerbar.
- Ett säkerhetsproblem och föråldrade komponenter.
- Stora problem med mobil användbarhet och Core Web Vitals.
- Mätfel som leder till dåliga beslut.
- Först därefter mindre poäng och kosmetiska problem.
Teknisk SEO är startlinjen. Den vinner inte loppet på egen hand, men en trasig webbplats kan förlora det innan startskottet går. Om du behöver omvandla tekniska resultat till affärsprioriteringar kan du beskriva webbplatsen och beslutet du står inför.