Teknisk SEO.

Vad ingår i teknisk SEO?

Teknisk SEO omfattar sådant som statuskoder, indexeringsdirektiv, kanoniska adresser, interna länkar, sidkartor och rendering. Det omfattar också användbar prestanda och strukturerad data. Arbetet börjar med hur webbplatsen faktiskt fungerar för en besökare och en sökmotor. En inställning i ett tillägg är inte samma sak som ett verifierat resultat.

Vi väljer representativa sidtyper innan granskningen börjar. En startsida kan fungera perfekt samtidigt som kategorier, filtrering eller äldre tjänstesidor är blockerade. Därför behövs exempel från hela strukturen. Vi beskriver också vilka affärssidor som är viktigast. Det gör att ett problem på en central kategori får företräde framför ett kosmetiskt fel på en gammal nyhet.

Leveransen är en prioriterad åtgärdsplan med observation, konsekvens, rekommendation och kontrollpunkt. Er utvecklare ska kunna förstå vad som behöver ändras utan att gissa. Om vi genomför ändringen kontrollerar vi den i den publicerade miljön, inte bara i utvecklingsversionen. Tekniska råd måste överleva vägen från analys till faktisk webbplats.

Crawlbarhet är inte samma sak som indexering

En sökmotor behöver först upptäcka adressen och sedan kunna hämta innehållet. Därefter avgör den om sidan ska finnas i indexet. En sida kan alltså vara tekniskt tillgänglig utan att bli indexerad. Vi skiljer de stegen åt för att inte behandla ett innehållsproblem som ett serverfel eller ett blockerat sökrobotbesök som ett textproblem.

Robots.txt styr vilka adresser en robot får hämta. Ett noindex-direktiv ber en sökmotor att inte indexera sidan. Om sidan samtidigt är blockerad i robots.txt kan roboten inte läsa noindex-direktivet. Vi granskar kombinationen och väljer rätt lösning för syftet. Privata sidor behöver dessutom åtkomstkontroll; robots.txt är aldrig ett skydd för hemlig information.

Google Search Console hjälper oss se indexeringsstatus och undersöka enskilda adresser. Vi jämför rapporten med sidans aktuella svar och interna länkar. En sitemap gör adresser lättare att upptäcka men garanterar inte indexering. Vi lägger bara in de sidor som verkligen ska vara sökbara och undviker omdirigeringar, feladresser och interna sökresultat i sidkartan.

Kanoniska adresser och intern struktur

En canonical visar vilken adress ni föredrar när flera sidor har liknande innehåll. Den är en signal, inte en absolut instruktion. Om interna länkar, sitemap och omdirigeringar pekar åt olika håll skapar ni motstridiga förutsättningar. Vi gör signalerna konsekventa så att sökmotorn kan förstå vilken sida som är den huvudsakliga.

Internlänkning förbinder struktur med prioritering. Viktiga tjänster ska inte vara möjliga att hitta enbart genom en sökruta eller ett klientskript. Vi granskar hur många steg som krävs för att nå en sida, om länkarna fungerar som vanliga HTML-länkar och om ankartexten beskriver destinationen. Besökaren ska kunna orientera sig utan att redan känna till webbplatsen.

Parametrar, utskriftsversioner och filter kan skapa onödigt många adresser. Vi skiljer användbara landningssidor från kombinationer som inte tillför ett eget värde. Lösningen kan vara en tydligare URL-struktur, justerade länkar eller förändrad indexering. Att lägga samma canonical på alla sidor utan att analysera deras innehåll kan i stället gömma värdefulla sidor.

Fördjupa nästa steg med seo-granskning & audit.

Core Web Vitals med verkliga förutsättningar

LCP beskriver när det största synliga innehållet laddas, INP hur snabbt sidan svarar på interaktioner och CLS oväntade förskjutningar i layouten. Vi använder fältdata när den finns och kompletterar med reproducerbara laboratorietester. Ett bra Lighthouse-resultat från en enskild körning ersätter inte förståelsen av hur verkliga besökare upplever sajten.

Vanliga åtgärder är rätt bildstorlekar, reserverat utrymme, lokalt laddade typsnitt och färre blockerande resurser. Vi granskar också tredjepartsskript som lägger till arbete i webbläsaren. En stor chattwidget eller flera spårningsverktyg kan påverka upplevelsen mer än en liten justering i CSS. Varje nytt tillägg behöver därför ett motiverat syfte.

Prestanda ska mätas på rätt sidtyper och skärmstorlekar. En produktlista med många bilder beter sig annorlunda än en ren textsida. Vi dokumenterar vad som mättes och med vilka begränsningar. Förbättringen ska inte göra menyn otillgänglig, gömma innehåll eller försämra formulär. Snabbhet och tillgänglighet behöver utvecklas tillsammans.

JavaScript-rendering och strukturerad data

Om centralt innehåll bara kommer fram efter att JavaScript körs ökar beroendet av en extra renderingsfas. Full serverrendering kan ge rubriker, text och länkar direkt i HTML-svaret. Vi kontrollerar ursprunglig källkod, inte enbart den färdiga vyn i webbläsaren. Synligt innehåll och metadata måste beskriva samma sida i båda fallen.

Schema-märkning hjälper maskiner att förstå entiteter och relationer. Vi väljer typer som passar innehållet, exempelvis Organization, Service, Product eller BreadcrumbList. Uppgifterna måste ha täckning på sidan. Vi lägger inte in betyg, recensioner eller produktuppgifter som inte finns och är verifierade. Strukturerad data är ingen ersättning för användbar information.

Vi testar JSON-LD som data och granskar referenser mellan objekt. En rätt formaterad sträng kan fortfarande beskriva fel företag eller peka på en gammal adress. Därför behöver namn, URL, logotyp och brödsmulor kontrolleras tillsammans. Alla publicerade sidor ska också ha en egen titel, metabeskrivning och självpekande canonical.

Fördjupa nästa steg med seo för wordpress.

Migrering utan att tappa vägen till kunderna

Vid byte av domän, publiceringssystem eller URL-struktur gör vi en inventering före flytten. Vi dokumenterar nuvarande adresser, viktiga inkommande länkar och sidor som driver relevant efterfrågan. Därefter mappar vi gamla adresser till verkligt motsvarande nya sidor. En omdirigering av allt till startsidan är sällan en bra lösning.

Vi använder permanenta omdirigeringar när flytten är permanent och undviker kedjor med flera steg. Interna länkar och sitemap uppdateras till slutadresserna. Testmiljön behöver hållas separat, medan den nya publika sajten inte får råka behålla noindex. Kontrollen görs före lansering och igen när sajten går att nå på den riktiga domänen.

Efter flytten följer vi statuskoder, indexering och utvecklingen för prioriterade sökningar. Variationer är inte automatiskt ett bevis på ett fel, men felaktiga adresser behöver fångas snabbt. Vi skiljer planerade förändringar från regressioner och dokumenterar nästa åtgärd. Migreringen är klar när den nya strukturen fungerar och gamla relevanta länkar fortfarande leder rätt.

Kontrollera ändringen innan den stängs

För en ändring av indexeringsdirektiv väljer vi exempel från varje berörd mall. Vi hämtar sidan utan att först öppna den i en inloggad webbläsare och granskar både status, HTML och relevanta HTTP-huvuden. Om ett cachelager finns kontrollerar vi också att den nya versionen faktiskt når publika besökare. Detta fångar skillnader som annars kan gömmas av utvecklingsmiljön eller en redan laddad session.

En mindre kontrollista kan omfatta slutadress, en huvudrubrik, självpekande canonical, läsbara länkar och rätt sitemap-innehåll. Den behöver anpassas till själva åtgärden. En prestandaändring kräver dessutom att viktiga funktioner används, inte bara att sidan öppnas. Vi dokumenterar vad som testats så att samma kontroll går att upprepa vid nästa större uppdatering.