Teknisk SEO-analys

Oavsett hur bra en sajt är sett till innehållet, så finns det så gott som alltid tekniska problem som hindrar synligheten. Och även om så gott som alla sajter vi stöter på har blivit bättre, tillkommer det ständigt nya tekniska problem ju mer Google, moderna browsers och webbtekniken i stort förändras.

Vi använder flera olika verktyg för att sammanställa en teknisk audit av alla sajter som vi börjar arbeta med. Alla dessa börjar med att spindla sajterna som Googlebot, för att vi ska se samma saker som Google ser.

Checklistan för lägsta acceptabla tekniska nivå växer ständigt ju mer Google förändras. På senare år har SSL-protokoll och sajternas hastighet tillkommit som viktiga aspekter, men det har hittills inte hänt att vi har fått stryka något från den tekniska checklistan.

Det finns så mycket som kan gå fel på en sajt, ofta kan halvdana fixar ställa till det än värre. Därför utmynnar vår tekniska analys alltid i en prioriterad åtgärdslista.

Därtill brukar det vara nödvändigt att göra om den tekniska SEO-analysen efter större releaser, eftersom gamla fel har en tendens att komma tillbaka och nya tillkomma varje gång ny funktionalitet byggs in på en sajt.

Den tekniska analysen vägs även in i vår analys av webbplatsen, eftersom den hjälper oss att förstå olika sidtypers möjligheter eller svårigheter när det kommer till att fånga de bästa positionerna för viktiga sökfraser.

Utan att hänga ut någon, vill vi gärna ge några exempel på tekniska fel som kan ställa till det ordentligt för en sidas synlighet.

Felaktigt self canonical

En avart av felet att inte använda rel canonical är att göra det felaktigt. Det är nästan vanligare än att inte använda den alls. Exemplen på fel är många:

• Katastrof-läge: Bara skriva ut det som råkar finnas i url-fältet i canonical – alltså lägga på eventuella parametrar om de finns i url:en, vilket ju direkt motverkar syftet med hela övningen.
• Genomgående skriva ut url:en med avslutande slash, trots att sajten länkar utan till de egna sidorna – eller tvärtom.
• Skriva ut url:en utan https, trots att sajten faktiskt har säker SSL.
• Skriva ut samma url på samtliga sidor på sajten.

Ja, ni förstår…

Self canonical

Det är fortfarande väldigt vanligt att sajter inte använder sig av möjligheten att kommunicera den önskade urlen till en sida. Det är enkelt gjort. För en sida som via sajtens interna länkar nås med url:en https://www.exempel.se/katalog/sida ska canonical-koden se ut så här:

<link rel=”canonical” href=”https://www.exempel.se/katalog/sida” />

Anledningen till att det är viktigt, och särskilt för sajter som annonserar mycket eller har många samarbeten med andra sajter, är att Google alltför ofta indexerar varianter av URLar som innehåller olika parametrar. Googles egna UTM-parametrar brukar kunna filtreras bort av Google, men om url:en bara innehåller en extra parameter så blir det ofta fel. Och med tillräckligt många sådana ”alternativa” url:ar till en sida är det lätt hänt att Google går vilse och börjar visa parameter-versionen av url:arna i sökresultaten – men aldrig på den plats de förtjänar, eftersom sajten själv inte stöttar den version av sidan som Google har bestämt är den bästa.

En korrekt self canonical undanröjer även problem som kan uppstå mellan www- och non-www-versioner av en sajt, och de alltför vanliga problemen att sidor svarar likadant med och utan avslutande slash i url:en.

Bädda in alltför många – och stora – CSS och javascript på varje sida på sajten

Javascript-tunga sajter och vissa centraliserade CMS har ofta egenheten att spruta ur sig väl många javascript-filer och CSS-filer. Detta är förstås dåligt även för användarupplevelsen eftersom det slöar ner sajterna (vilket i sig är ett problem, som dessutom blir värre i maj 2021, när Google tar in Core Web Vitals som en egen rankningsgrundande faktor).

Men vad värre är – om en sida vill lägga in för många olika resurser som påverkar sidans utseende, så kommer Google-bot inte att kunna rendera sidan korrekt.

Gränsen är lite flytande, men när den är nådd, så slutar Google helt plötsligt att läsa in resurserna i sin rendering vilket visar sig som väldigt märkliga sidor i Search Console – och resulterar i sämre placeringar än sajten borde ha. Ibland väldigt mycket sämre.

Felaktig hantering av 404 och redirects gjorda på fel sätt

Tar ni ofta bort sidor från sajten? Det är något vi bestämt avråder ifrån, i alla fall utan att göra en genomtänkt 301-redirect till en sida med någotsånär motsvarande innehåll.

Men det händer, och när vi ser sajter som tar bort sidor, eller helt enkelt byter ut URLen till en sida bara för att rubriken eller title-texten ändras, eller för att färgen på produkten förändras, eller för att produkten är tillfälligt slut, så hoppas vi att sidan åtminstone ger en korrekt 404. Ett vanligt förekommande fel är att sidan som tas bort istället redirectar med 302 till en sida som i sig svarar med 404 eller kanske t.o.m. med 200 OK, (vilket alltså innebär att sidan finns och svarar som den ska), men sedan inte innehåller någon som helst text. Ja, då blir vi lite ledsna. En vettig, fungerande, och inte alltför betungande funktion för att skapa 301-redirects är ofta bökig att utveckla och implementera, men det lönar sig i längden.

Och när ni gör era redirects, se till att de görs via rätt protokoll. Det finns fantastiska möjligheter till felkällor här där sidan https://www.exempel.se/katalog/foo ska redirectas till https://www.exempel.se/katalog/bar. Vi har sett exempel på redirect-loopar via http, via non-www-versionen av sajten eller en kombination av båda. Vanligare ändå är att sidan redirectas med 302, vilket inte skickar rätt signaler till Google. Ett annat vanligt fel är att eventuella parametrar inte tas med i redirecten, vilket gör AdWords-folket ledsna när deras annonser (som inte borde ha pekat fel, men tydligen gjorde det), inte spåras på rätt sätt.

Sökresultat istället för kategorier eller taggar

För stora sajter – och särskilt inom media och retail – är det ofta viktigt att optimera kategorisidor framför enskilda artikel- eller produktsidor. Detta eftersom artiklar och produkter har kort livslängd. En genväg till kategorisering kan vara att arbeta med sökresultatsidor – särskilt om man använder moderna tekniker som Elastic Search som snabbt och elegant kan skapa innehållsrika sidor.

Men genvägar är ofta snåriga och problemen man stöter på med sökresultat är många. För även om de definierade resultatsidorna är bra, så skapar man snabbt en uppsjö oväntade resultatsidor, baserade på vad kunden söker efter – och kunden söker sällan som man tänkt sig. Hen stavar fel, hen söker efter märkliga saker som inte ens borde finnas på sajten. Ett exempel på det senare är Amazons svenska lansering när de porrelaterade sökningarna eller sökningar efter felöversättningar av det engelska ordet rape som borde översatts till raps,  blev så många att de uppmärksammades av riksmedia.

Det som händer är att man skapar vad som brukar kallas ”tunt innehåll” på sajten. Det är sidor som inte har något eget innehåll, utan enbart listar länkar till andra sidor. Det vill man undvika på alla sätt, och därför ser vi hellre att man helt avindexerar sökresultatsidor genom att förbjuda Googlebot att ens besöka sådana.

Det finns så mycket mer

Det finns oändligt med möjligheter att försvåra för Google att ge sajten de positioner den förtjänar. Hör av dig till oss om du vill att vi gör en teknisk analys, där vi kan hjälpa till med att hitta de vanligaste felen