Kategoriarkiv: Tips

När man inte vill synas

KikareNär man pratar om sökmotoroptimering handlar det som oftast att öka sin synlighet, att ranka så bra som möjligt i sökmotorer. Det finns dock tillfällen när man inte vill få sina sidor indexerade och sökbara, något som kan vara minst lika krångligt, även för stora börsnoterade bolag med miljardomsättning.

Robots.txt

Genom att skapa en textfil, robots.txt, och placera den i roten på din domän kan du ange regler över vilka sidor olika sökmotorers spindlar får besöka. Om en spindel inte får besöka din sida kan den heller inte se vilken information som finns på sidan. Exakt hur dessa regler ser ut tar jag inte upp här, men Google har en bra guide.
Ungefär här anser sig 99% klara trots att man missar en viktig sak:
Bara för att sökmotorn inte kan se vilken information sidan har innebär inte det per automatik att sidan exkluderas ur sökindexet.

<meta name=”robots” content=”noindex”>

Det finns andra sätt för sökmotorer att upptäcka sidor, till exempel om en annan sida länkar till din sida som är blockerad enligt robots.txt. Som jag skrev ovan innebär detta bara att sökmotorn inte ”får” läsa sidan innehåll, de kan mycket väl ändå visa sidan i deras sökresultat, dock ofta med en titel som är webbadressen och en beskrivning som talar om att att en beskrivning inte tillgänglig på grund av webbplatsens robots.txt.

Genom att placera en speciell meta-tagg på de sidor du inte vill ska indexeras, talar du om för sökmotorn att den ska strunta i dessa trots att andra sidor länkar till den.

<meta name=”robots” content=”noindex”>

Ovanstående tagg ska placeras i webbsidans head-tagg och talar om för sökmotorer att inte indexera sidan.

Tänk på att inte blockera sidan med robots.txt, då kan sökmotorn per definition inte se sidans html-kod och missar därav din meta-tagg!

X-Robots-Tag HTTP header

Ett likvärdigt sätt till meta-taggen för att blockera indexering är att ange en extra http header, X-Robots-Tag: noindex. Detta kan vara enklare i vissa lägen då man enkelt kan skriva regler på servern vilka sidor som ska få denna extra header. Likaså när det handlar om pdf-dokument, bilder med mera är det ändå omöjligt att ange meta-taggen. Mer tekniska detaljer på vilka format som är giltiga direktiv kan hittas hos Google.

Så vill du undvika publicera dina kunders beställningar, personnummer och supportärenden (där du t.o.m. kan skicka in meddelanden som personen), se till att dölja dina sidor på rätt sätt. Att bara ange dina regler i robots.txt räcker helt enkelt inte.

Företaget länkarna handlar om ovan har kontaktats för över 1 vecka sedan både via e-post och kundtjänst-chatt som vidarebefordrat till ansvariga, dock utan svar.

Varför försvinner sökorden?

Med tanke på den dramatiska ökningen av andelen (not provided) i Google Analytics och kringliggande diskussioner tänkte jag dra en mer teknisk aspekt om varför detta uppstår. Har tidigare skrivit ett inlägg om (not provided) men här kommer ännu ett.

https
Google när den besöks krypterat via tls

När man besöker en webbsida görs vanligen all överföring av data mellan server och webbläsare via http. På sidor som har ssl/tls kan denna trafik dock transporteras krypterat i protokollet https vilket är just det Google på senare tid allt oftare använder.

(not provided) visas i Google Analytics då man inte kan avläsa vad användaren sökte på, detta då data saknas i ett fält som heter http referer. Så varför saknas denna data allt oftare, är gänget på Google Analytics så elaka att de manuellt plockar bort denna information och ersätter med (not provided)? Troligen inte, det är en direkt följd av tekniska begränsningar i ssl/tls samt ett val som teamet som driver söktjänsten gjort.

Problem HTTPS

Om man kommer från en sida som har https och landar på en sida som kör okrypterat, d.v.s. http, då skickas ingen http referer med oavsett hur gärna du vill, detta då reglerna för hur https fungerar är sådana. Varken Google Analytics eller någon annan leverantör av statistik kan visa sökorden för besökare som går från krypterad till okrypterad sida.

Problem inloggad användare

Om en användare är inloggad på Google väljer Google aktivt att blocka bort information från http referer, de visar endast att du kom från t.ex. google.se, men inga sökord eller annan information skickas med. Precis som i fallet ovan är både gänget på Analytics såsom alla andra leverantörer helt körda att visa några sökord.

Lösning problem HTTPS

Om du har en krypterad sida, antingen med ssl eller tls skickas http referer och både Google Analytics och övriga leverantörer kan visa vad användaren sökte på. Du får helt enkelt kryptera din sida så får du data precis som vanligt.

Lösning problem inloggad användare

Det finns ingen lösning, du är körd oavsett verktyg, detta eftersom Google plockar bort all data förutom domänen besökaren kom från.

Aktiviteter från applikationer snart i ditt sökresultat

Att Google trycker lite extra för sina egna tjänster och sociala signaler borde inte komma som någon nyhet för de som följer förändringar inom seo-branschen. Jag har tidigare skrivit om Search, plus Your World  som tar upp allt om hur du skapar din företagssida på Google+, hur du märker upp innehåll med författarskap med mera, om du inte känner till dessa grunder gör du bäst i att först läsa det inlägget som tar upp allt grundligt.

Inom kort kommer nästa nyhet från Google+ att lanseras och synas i sökresultatet på Google, aktiviteter från applikationer. Till en början lanseras det för några utvalda film- och musik-applikationer i USA men kommer gradvis att rullas ut till fler. Någon tidsplan när det även dyker upp i Svenska sökresultat har inte angetts, men troligen dröjer det månader om inte längre, hur som är det ändå en bra anledning att implementera tekniken eller åtminstone känna till den så arbetet går snabbare när det väl rullats ut även i Sverige.

Fandango applikationsaktiviteter
Till höger syns de nya aktiviteterna från sina följare vis sökning efter existerande applikation, klicka på bilden för större version.

Till en början lär sökresultat inte påverkas nämnvärt då förändringen blir att man bara får ännu mer yta till höger men exakt hur det påverkar människors sök och klick är alltför tidigt att sia om då informationen om förändringen är ganska knapphändig i skrivande stund.

Implementering av aktiviteter kan dock förhöja användarens upplevelse, ofta kan man hitta bra saker bland ens följare så en helt dum ide är det inte av Google. Det blir till en början väldigt snarlikt det Facebook har i sina sociala boxar.

Om du har en webbsida som redan idag stödjer inloggning med Facebook, Twitter och andra tjänster blir det en enkel sak att även lägga in Google+ så är du förberedd när ännu fler sociala signaler påverkar morgondagens sökresultat.

Google Developers har mer teknisk information om hur du implementerar inloggning samt aktiviteter. Även om länkar än idag har allra störst betydelse, känns det kul att alltfler saker påverkar sökresultat, särskilt när det blir lite tekniskt mer utmanande saker än att kötta länkar…

Hjälp med sökmotoroptimerings-verktyg

Håller på och bygger ett analys-plugin för webbsidor till WordPress och skulle gärna vilja ha era tips och råd. Det jag försöker skramla ihop är vilken data man vill se samt regler och dess vikt som man bör analysera på sidan.

PHP-kod
Hämtning av webbsidan DOM för seo-analys 🙂

Jag har aldrig kodat ett plugin till WordPress tidigare men eftersom jag är systemutvecklare ser jag detta som ett utmärkt tillfälle att kunna bidra med min programmeringskunskap inom området sökmotoroptimering samt lära mig en hel del på ett vettigt projekt. Förhoppningsvis har både erfarna samt mindre erfarna personer nytta av plugin:et.

Exempel på data:
Viktat poäng baserat på alla regler
Antal interaktioner på Facebook, Twitter, Google+
Hur ligger jag till gentemot övriga testade sidor

Några exempel på regler:
Regel: Sökord återfinns i sidans titel
Vikt: Viktigt

Regel: Sökord i <h1>-tagg
Vikt: Viktigt

Regel: Bilder på sidan
Vikt: Ganska viktigt

Regel: Sidans laddningstid (Denna består redan idag av 28 olika analyser).
Vikt: Låg

Om verktyget blir tillräckligt bra ser jag ingen anledning att inte dela med mig utav plugin:et så att alla med WordPress kan installera det på sina webbsidor.

Om någon dessutom är haj på utveckling av plugin får ni gärna hojta till så kan jag rådfråga om behov finns. Alltid skönt slippa trampa i alla uppenbara fallgropar även om man lär sig även på detta.

 

Uppdatering 2014-04-09
Uppdaterat logiken i page speed då API-svaret förändrats, nu kan man alltså åter analysera sina sidor.

Uppdatering 2013-06-12
Arbetet har fortskridit, tar dock lite tid då jag gör detta på min fritid och ett dygn har tyvärr endast 24h. Det finns ett fungerande seo-plugin som kan testas fritt. Saker som verktyget kontrollerar är onpage, sociala medier samt faktorer som påverkar sidans laddningstid.
Det som kvarstår är mest att komma på bra och nyttiga onpage-tester, så om någon har bra tips får ni mer än gärna delge detta.
Saker som är implementerade för onpage-tester: titel, h1, bilder, antal ord, sökordsfrekvens, meta-description. Senast nytt är att du nu kan välja om testet ska optimeras för desktop eller mobil-anändare.

Bemästra din sidbläddring

En vanlig företeelse på webbsidor idag är någon form av sidbläddring. Det kan handla om kommentarer till en bloggpost såsom denna, eller en serie slides, en lång forum-tråd som delas upp på flera sidor med mera. Gemensamt är dock att alla sidor hör ihop och man vill signalera detta.

Det finns 3 sätt att lösa detta på varav det första inte kräver någon kunskap alls, du överlåter helt enkelt allt åt sökmotorn och förlitar dig på att den förstår att sidorna hör ihop. Detta sätt är absolut inte smartast, men ej heller sämst, något jag tar upp i exemplet längst.

Sidbläddring hos Google
Sidbläddring hos Google, ett vanligt förekommande fall att ange sidnummer.

2. Visa allt

Den första lösningen går ut på att du har en sida som kan visa allt innehåll från alla övriga sidor som ingår i gruppen. I fallet med kommentarer till ett blogginlägg skulle det således innebära att alla kommentarer visas på en och samma sida. För en forumtråd skapar man en sida som kan visa samtliga inlägg i tråden och så vidare. Det fungerar i vissa fall, i andra fall är det helt värdelöst. Här gäller sunt förnuft.

Att påpeka för sökmotorn att sidan som visar samtliga 1000 foruminlägg från tråden ska visas istället för en delmängd är inte alltför smart, dels blir laddtiden troligen lång, sidan blir enormt stor och besökaren hittar ändå inte vad som söks för att just det specifika inlägget drunknar i övriga 999 inlägg.

3. Link-taggen

html 4.01En smartare lösning är att använda <link>-taggen som introducerades i HTML 4.01 och ange relationen mellan sidorna. En relation anges genom attributet rel och sedan anges källan som vanligt i attributet href. I vårt fall är relationerna next samt prev det som är utav intresse, de talar helt enkelt om vilken nästa samt föregående sida är i hänsyn till sidan man har länken på.

Antag att vi har en grupp sidor som presenterar en vanlig Power Point-slide om hundar.
Den har 4 sidor och användaren har kommit till sidan 2, i HTML-sidans <head>-tagg lägger vi in vår speciella <link>-tagg för att ange relationen mellan sidorna så sökmotorerna enkelt kan förstå detta och slipper gissa. Följande kod borde synas i huvudet förutsatt man befinner sig på sidan 2.
<link href="http://www.example.com/presentation-hundar-1-av-4" rel="prev" />
<link href="http://www.example.com/presentation-hundar-3-av-4" rel="next" />

På första samt sista sidan kan du inte lägga in båda dessa taggar, det finns ingen sida före sidan 1 och det finns såklart ingen sida efter vår sista sida. Befinner du dig på sista sidan har du bara en relation till sidan efter (next)  och för sista sidan finns bara en föregående sida (prev).

Se upp

Som jag berättade i början av inlägget var en av lösningarna för sidbläddring helt enkelt att förlita sid på sökmotorerna och inte implementera någon speciell teknik alls. Jag har själv ett exempel på en sida som jag äger och utvecklar där jag lite klantigt nog blockerade sökmotorerna från att indexera mer än 1:a sidan. I mitt specifika fall hade det dock inte hjälp att göra den enkla lösningen, alternativ 1.

Sedan flera år har jag lagt in stöd på en av mina större sidor för att minimera duplikat innehåll genom att ange kanonisk sida. Det är ett kraftfyllt verktyg för att tala om för sökmotorn vilken av alla eventuella snarlika sidor som gäller. Min sida använder dels olika kampanj-länkar för att spåra när trafik kommer via mina mobil-appar, speciella nyheter o.s.v  men sedan länkar även besökarna till sidan. För att slippa få länkkraften utspridd samlar jag den enkelt till sidan som är rätt, trots alla extra parametrar som ibland anges på länkarna. Mer om just den problematiken finn i inlägget om kanonisk sida här ovan.

När jag sedan skulle införa tekniken för sidbläddring valde jag att jobba med relationer och ange dessa med <link>-taggar. På min webbsida där jag lyckades ha kvar mitt klantiga fel 8 månader kan besökarna skriva kommentarer till objekt. Tidigare visade jag bara de 30 senaste, nu ville jag dock att man även skulle komma åt alla äldre inlägg varav jag införde sidbläddringen.

Allt verkade frid och fröjd, min kod beräknade antal sidor rätt, den skrev ut relationerna helt korrekt och jag la upp förändringen på skarpa driftmiljön. 8 månader senare, jag hade fortfarande inte sett några tendenser till fel men jag ramlade över en artikel som tog upp vanliga misstag när man använde kanoniska sidor, något jag använder mig utav.

Det var då det slog mig, jag har kvar samma kanoniska sida oavsett om man stod på 1:a sidan eller ej. Min webbadress för varje objekt är enligt formen:
www.example.com/objekt/

När jag införde sidbläddring la jag på en parameter som talar om vilken sida man är på bland alla kommentarer, befinner man sig på sidan 3 blir adressen således:
www.example.com/objekt/?sida=3

För den som förstått allt resonemang ovan samt vet vilka tekniker jag använder kan säkert redan förstå mitt fatala misstag. Jag uppdaterade ju aldrig koden som skriver ut min kanoniska sidan.
Om vi återgår till sidan och håller oss till sidan 3, då såg min kanoniska sida ut enligt följande felaktiva format.
<link rel=”canonical” href=www.example.com/objekt/” />

Korrekt vore såklart att även ha kvar parametern för sidbläddring, rätt kod blir således:
<link rel=”canonical” href=www.example.com/objekt/?sida=3″ />

Så vad tror du misstaget medförde?
Sökmotorerna indexerade helt enkelt bara objekt-sidan och de 30 senaste kommentarerna som visas på den sidan. Även om jag anger med <link>-taggen att det finns fler sidor och dessutom har vanliga <a>-taggar anger jag ju på övriga sidor att sidan ej ska visas utan att objektets startsida bara ska visas. Jag har rullat ut min fix i skrivande stund och det blir spännande se hur många av alla nya sidor som kommer att indexeras.

Hur har ni sett att sökmotorer jobbar och presenterar sidor som hör ihop med sidbläddring?

Förhindra duplikat innehåll med en kanonisk sida

Duplikat innehåll kan lätt uppstå och kan orsaka problem hos sökmotorer, det ska dock påpekas att de är ganska smarta nuförtiden. Med det sagt förhindrar det inte oss ifrån att använda de tekniker som finns tillgängliga för att påtala för sökmotorerna vilken sida det egentligen är som gäller bland flera snarlika.

Enkelt uttryckt är duplikat innehåll, eller duplicate content, som det heter på engelska en bieffekt utav att flera olika länkar presenterar samma sida och innehåll. Vi kan ta Göteborgs-Posten som ett typexempel som har detta problemet.

Duplicate content hos GP.se
Senast felaktigt indexerade filen skedde bara för 1 dag sedan

På varje sida hos GP.se finns det funktioner för att dela till Facebook och Twitter. För att enkelt mäta effekten av hur många besökare de erhåller läggs det därför på en kampanj-parameter på länken. Följande 3 länkar går alla till samma innehåll, men det är bara den översta som borde väljas att indexeras av sökmotorer, de andra skapas enbart när man delar sidan via sociala medier och e-post.

http://www.gp.se/nyheter/1.1081975-luras-med-falska-apple-sms
http://www.gp.se/nyheter/1.1081975-luras-med-falska-apple-sms?ref=fb
http://www.gp.se/dela/1.1081975-luras-med-falska-apple-sms

Båda de två typerna av länkar har indexerats av Google, det handlar i skrivande stund om 5700 sidor som blivit felaktigt indexerade och där man genom en enda kodrad kan rätta till felet.

rel=”canonical”

Genom att skapa en kanonisk sida talar man om vilken av av alla sidor som är den föredragna. Det finns i dagsläget två olika sätt att skapa en kanonisk sida.

Lägg till rel=”canonical” i html-kodens <head>
Genom att lägga in en rad html-kod i de sidor som inte är huvudsidan, påtalar du för sökmotorerna att du föredrar sidan du länkar till. I vårt exempel med Göteborgs-Posten ska de således lägga in följande i sidans huvud. Det skadar inte att även ha koden på den prioriterade sidan även om det är onödigt.
<link rel=”canonical” href=”http://www.gp.se/nyheter/1.1081975-luras-med-falska-apple-sms” />

Svara med rel=”canonical” i HTTP-huvudet
Denna variant är mer teknisk och kräver tillgång till din webbserver, den passar bra för indexerade filer som ej använder sig utan HTML, till exempel PDF-dokument. I HTTP-huvudet skickar du med länken till din föredragna variant av filen, precis som i exemplet ovan. Våra exempelsidor bör således svara med följande extra header i HTTP-huvudet.
Link: <http://www.gp.se/nyheter/1.1081975-luras-med-falska-apple-sms>; rel="canonical"

Ovanstående header kan skapas på flertalet sätt, ett exempel skrivet i PHP ser ut enligt:
<?php
header("Link: <http://www.gp.se/nyheter/1.1081975-luras-med-falska-apple-sms>; rel=canonical");
?>

Värt att tänka på är att rel=”canonical” ses som ett förslag till sökmotorer och är inget de måste följa, av erfarenhet har jag dock sett att de ofta litar på detta tips.

Om du flyttar innehåll och vill skicka vidare besökaren direkt till en annan adress är en kanonisk sida inte rätt väg, då ska du kika på 301-redirect som är ännu en header som kan anges i HTTP-huvudet. Återigen, om sidan använder PHP kan man t.ex. skriva följande i koden:

<?php
header ('HTTP/1.1 301 Moved Permanently');
header ('Location: http://www.exempel.se/ny-sida');
die();
?>

Sökmotoroptimera din Ajax-sida

HashbangDet finns många anledningar till varför man skapar en sida som använder sig utav Ajax. Om du fortfarande vill få alla dina sidor indexerade gäller det dock att du kodar på rätt sätt. I dagsläget finns det två olika tekniker, hashbangs (#!) samt pushState varav den senare är att föredra.

Jag kommer inte ta upp alla fördelar Ajax-baserade webbsidor för med sig utan inlägget kommer endast fokusera på hur du måste göra för att fortfarande få fullgott stöd av indexering av sökmotorer.

Hashbangs (#!)

De flesta har nog sett implementationen av hashbangs på Twitter, det är när adressen innehåller de roliga tecknen (#!). Twitter har dock gått över till både permalänkar och nu senast den nyare varianten pushState vilket jag beskriver längre ned.

Hash-fragment
Allt efter # i en webbadress hör till hash-fragmentet och används oftast för att visa en specifik del på sidan. Vid Ajax-tillämpningar använder man dock denna del för att påvisa olika tillstånd av webbsidan.

Antag du besöker www.example.com/ajax#state=contacts, Ajax-logiken kommer då att extrahera all data ur fragmentet och visa rätt innehåll, i vårt fall troligen en sida med kontaktinfo.
Vad är då fördelen med att skapa dessa länkar med fragment? Jo, fragment hör inte till http-anropet och även om du byter tillstånd, det vill säga ändrar ditt fragment skickas ingen ny data fram och tillbaks till servern med automatik och du spar den tid det i vanliga fall skulle ha tagit att hämta all data.

Eftersom inget anrop görs per automatik för du bygga in hela denna logiken i din Ajax-lösning. Du kan till exempel bara skicka över all data som behöver förändras i lämpligt format (json) och slipper skicka med onödig overhead och filer.

_escaped_fragment_
För att sökmotorer ska kunna indexera din sida måste de dock göra lite extra bearbetning, de byter helt enkelt ut din hashbang mot _escaped_fragment_.
www.example.com/ajax#state=contacts blir www.example.com/ajax?_escaped_fragment_=state=contacts

Tack vare denna översättning av webbadressen kan sökmotorer fortfarande indexera din sida då adressen blir en gilltig url.

Sökmotorerna hämtar alltid sidan som innehar _escaped_fragment_, du måste således hantera alla dessa sidor och returnera en fullgod sida så som du vill att den ska se ut. Förslagsvis exakt så som motsvarande sidan med hashbangs ser ut, i annat fall bryter du mot riktlinjer och visar olika innehåll för användare och sökmotor.

I sökresultatet visar sökmotorerna alltid webbadressen med hashbangs, så dina fina länkar smutsat inte ned i onödan trots all översättnings som har gjorts.

Eftersom Twitter stödjer hashbangs för gamla länkar skull kan vi testa detta på min Twitterprofil.
Hashbangshttps://twitter.com/#!/stefanjanson
Escaped fragment för sökmotorerhttps://twitter.com/?_escaped_fragment_=/stefanjanson
Permalänkhttps://twitter.com/stefanjanson

I exemplet med Twitter måste de två första implementeras, den sista har de lagt till i efterhand och har inget med hashbangs att göra. På din webbsida och eventuell webbplatskarta ska den fina varianten av webbadressen användas. Länkar innehållande _escaped_fragment_ indexeras och följs ej.

Det värsta du kan göra är att returnera en felsida när example.com?_escaped_fragment= anropas, då kommer inget på sidan att indexeras…

 pushState()

En nyare och mer rekommenderad metod för att skapa Ajax-sidor som är anpassade för sökmotorer är att använda pushState() som hör till HTML5. Med denna metod kan man lägga till inlägg i webbläsarens historik-data genom att anropa history.pushState([data för sida], [sidans titel], [webbadress]). Exempel:

var stateObjekt = { minNyckel: "lite data..." };
history.pushState(stateObjekt , "sida 2", "ny-sida.html");

Objektet man kan skicka med till sidan är ett Javascript-objekt som erhålles när popstate-event avfyras. När användaren navigerar tillbaka till ursprungssidan saknas dock detta obekt då man ej skapat något, därför anropar man replaceState() vid första sidan. Hela kedjan blir enligt flödesschemat.

History API
Diagramet visar hur replaceState, pushState samt onPopState anropas

Precis som vid förändring av tillstånd i fallet med hashbangs sker inget http-anrop till servern utan det krävs egen logik för att hämta nödvändig data som ska presenteras. Antar att ni börjar förstå vitsen med Ajax-sidor, nämligen att man gör anropet själv för att hämta data.

Några fördelar med pushState gentemot hashbangs:

  • Du kan byta synlig url till vilken du vill så länge domänen är samma
  • Du kan skicka med ett eget objekt som erhållet vid alla sidbyten
  • Du kan skicka in samma url och det skapas ändå en ny post i historiken

Denna länk ändrar webbadressen m.h.a. pushState men du är fortfarande kvar på samma sida

Progressive enhancement

I båda fallen är det viktigt att koda enligt progressive enhancement. Väldigt kort betyder det att sidan även ska fungera för äldre webbläsare som ej stödjer all denna teknik och man bara adderar olika lager. Du kan till exempel bygga hela sidan som vanligt och sedan med javascript lyssna när någon klickar på en intern länk och då använda pushState() för att minifiera all dataöverföring och på så sätt förhöja besökarens upplevelse. Bara din fantasi sätter gränsen 🙂 Lite kodexempel baserat på jQuery som skickar dig i rätt riktning:

$('a').click(function(e) {
var url = $(this).attr("href");

//Anropa vår ajax-gateway som skapar minimal data
$.getJSON(”ajax-gateway.php”, {getPage: url},function (data) {
//Gör magiskt underverk med vår data
});

window.history.pushState(‘object’, ‘Sidans titel’, url);

//Stoppa vanliga klicket
e.preventDefault();
}

Det var ganska kort och väldigt tekniskt inlägg om två tekniker för att sökmotorer ska kunna indexera din webbsida om den baseras på Ajax. Inget för otekniska SEO-konsulter, rådfråga gärna en erfaren webbutvecklare 😉

Läs gärna min intervju med Västtrafik där de använder hashbangs.

Ta vara på gamla produktsidor

Alla som bedriver butiker online känner säker igen sig. En produkt ska inte längre säljas, vad ska jag nu göra? Det uppenbara är att helt enkelt radera sidan, det bidrar dock med en hel hög negativa aspekter både för dig seo-mässigt och för besökarens användarupplevelse.

Att en produkt tas bort kan ha många anledning, i detta inlägg ska jag dock förklara hur du på ett bra sätt bör gå tillväga med din gamla produktsida.

404 hittades ej
En dåligt utformat 404-sida ger inget bra intryck

1. Behåll sidan

Grundprincipen är att du aldrig ska ta bort en sida. Ofta har du lagt ned energi på att få sidan ranka, det du måste göra är dock att informera besökaren om att produkten har utgått och att den ej kan beställas längre. Om produkten ersatts med annan produkt, eller liknande produkt finns så informerar man lämpligen besökaren om detta och länkar till dessa produkter.

2. 301 redirect

Om du verkligen måste ta bort sidan, se till att skicka besökaren till den ersatta produkten alternativt en snarlik produkt. Om dessa två fall ej är möjligt skicka vidare besökaren till produktkategorin. Det finns två stora vinster med detta förfarande, dels slipper du brutna länkar in till din sida men framför allt slipper besökaren hamna på en felsida och du kan fånga upp intresset för en snarlik produkt.
I varje fall där du skickar vidare besökaren med 301 redirect bör du informera besökaren om varför man ej hamnade på sidan man förväntade sig.

Så hur vet du om besökaren kommer till en produktsida/kategorisida genom ovan nämnda redirect?
Det finns 3 olika sätt att lösa det på, vilket du väljer beror till stor del vad som är tekniskt möjligt med just din webbutik.

1. Skicka med en parameter
När du gör din redirect, se till att slänga på en extra parameter som talar om att besökaren kommer från en borttagen sida, det kan förslagsvis vara produktens id från databasen.
www.example.com/category/name -> www.example.com/name?removedproductid=123

Eftersom du lägger på en extra parameter måste du se till att målsidan är en kanonisk sida, i vårt exempel ska således följande kod finnas i sidhuvudet på kategorisidan för att undivka duplikat innehåll.
<link rel="canonical" href="www.example.com/category/name"/>

2. Använd sessioner / cookies

När besökaren kommer till en produkt kan du sätta en sessionvariabel innehållandes produktens id. Kategorisidan kan då se att variabeln är satt, ta bort denna samt informera användaren.

3. Användarvänlig 404-sida

Om du inte ser en annan utväg eller om ovanstående inte passar för just din borttagna sida, skapa då en användarvänlig 404-sida. Bara för att en webbsida har 404 satt i http-huvudet betyder inte det automatiskt att det måste stå stor och fult ”404 – Sidan hittades ej”.
Tvärtom, du kan designa upp denna sida precis hur du vill, du kan till och med presentera information baserat på vilken sida som tagits bort, vilken länk man kom via eller kanske vad klockan är. Bara din fantasi sätter gränserna.

Vad du än gör, skapa inte en tråkig 404-sida som är standard på de flesta webbservrar om du vet med dig att sidor kommer tas bort på regelbunden basis.

Produktkyrkogård

Ett roligt sätt att ta vara på alla gamla produkter som behövt raderas är att samla dom under en produktkyrkogård. Dels kan det skapa lite extra länkar till er webbsida, sedan kan nostalgiska besökare läsa om alla utgångna produkter, du kan till och med lägga till lite extra data om när produkten funnits. Ett tappert försök har Ben&Jerry gjort med deras kyrkogård, något jag fick syn på efter ett inlägg av Sökmotorkonsult och som de verkade gilla.

Helt bra exempel är det dock inte seo-mässigt.
Dels fungerar inte de gamla länkarna, kyrkogården är dessutom helt baserad på flash. Vitsen är ju att de gamla sidorna ska vara kvar och fungerande. Mobil-varianten av deras sida har samma brister förutom att den inte är skapad i flash. Som en vis man sagt till mig. Aldrig, aldrig ta bort en sida.

Google varnar för Djurgården Fotboll

Ibland kan saker spåra ut, ungefär som när Djurgårdens Fotboll oskyldigt råkat ut för spam via pingback och länkar till alla möjliga sidor som de säkerligen inte vill förknippas med. Det har gått så långt att Google skriver ut varningar till att besöka vissa av deras sidor.

Google varnar för spam
Google varnar: ”Denna webbplats kan vara osäker att besöka” 470 sidor matchar sökförfrågan…

Så vad är det som hänt DIF och hur har de kunnat förhindra att detta ens uppstod från början?
Med all sannolikhet har kommentarer varit omodererade, och kanske fortfarande är detta. Bara för att man använder ett externt system för kommentarer innebär inte det per automatik att det inbyggda i WordPress inaktiverats. Människor av den mindre formen av snälla har helt enkelt skickat fejkade pingbacks till diverse blogginlägg. Dessa har publicerats och på så sätt skapat en länk till målsidan.

Även om länken är nofollow, så kan vi tydligt se att det gjort stor skada genom att varningsmeddelande presenteras för Google-besökarna och att ord som man ej vill förknippas med står rakt i koden.

Genom att inaktivera javascript kan vi enklare se all spam som finns till ett blogginlägg hos dif.se och det handlar om hundratalet spam-länkar enbart till ett inlägg.

Pingback-spam
Länkarna syns tydligt när javascript är inaktiverat och Discuss ej visas

Driver man en webbsida måste man täppa till alla tänkbara sårbarheter, även de mer oskuldsfulla kommentarerna till bloggar. I detta fallet hade det undvikits om pingbacks inte tilläts automatiskt, för jag är tveksam till att Dig själva släppt igenom dessa hundratals länkar på en enda bloggpost. Inställningar för allt relaterat till kommentarer och pingbacks hittas under Inställningar -> Diskussion.

Använder man WordPress är tillägget Akismet en guldgruva mot spam, det följer dessutom med som standard. För privatpersoner är det gratis att använda och ju fler kommentarer du taggar upp felaktigt klassificerade desto bättre blir Akismet.

Webmaster tools

Google erbjuder ett förträffligt verktyg helt gratis, Verktyg för webbansvariga. Jag ska bara nämna en av alla funktioner detta verktyg medför till validerade webbplatser, meddelanden. När Google upptäcker något skumt med sidan skickar de ut ett meddelande, det kan t.ex. handla om att sidan verkar ligga nere, den har fått många nya 404-sidor, sidan verkar ha blivit hackas med mera.
Med all sannolikhet hade Google skickat ut en varning angående ovanstående spam-problematik och Djurgärden Fotboll hade upptäckt deras problem för länge sedan.

Varningsmeddelanden
Tack vare varningsmeddelandet upptäckte jag att min sida blivit hackad och åtgärdade problemet snabbt.

Det är inte bara gamla inlägg som är drabbade, gör vi en sökning och sorterar på datum visas det senaste från 23 januari 2013. Så ett gott råd till DIF och alla med bloggar därute, se upp med era kommentarer om de är aktiva.

Färska resultat också drabbadeJag har givetvis kontaktat Djurgårdens Fotboll och inväntar svar, förhoppningsvis åtgärdas detta snabbt och Google tar bort alla varningsmeddelanden.

Ett annat bra tips till webbutvecklaren hos DIF är att använda float:left på twitter-rutan så att den inte blockerar hela rutan sociala medier. Som det är nu kan man inte klicka på senaste blogginlägg varken i Chrome eller Firefox…

#svSEO på Twitter

Om du har Twitter kan du följa diskussioner om sökmotoroptimering och kringliggande områden under taggen #svSEO.

Det är ett trevligt gäng där erfarenheter utbyts och fastän man inte har samma åsikter får man åtminstone konstruktiv kritik, t.ex. mitt försök till att skriva om länkbomber där fakta baserades på officiella uttalanden från Google. Ibland är det dock bra att ha popcorn hemma.

#svSEO hugger till med feedback
Läser mer än gärna andras inlägg om Google-bomber eftersom mitt verkade vara helt fel…
En nedtumme
Tur jag inte har nedtummar på min sida, tror inte ens en integer hade räckt.

Jag har verkligen inget emot någon person varken de kan seo eller ej, men om man ska ge kritik får den gärna vara konstruktiv, hur ska vi annars lära oss av varandra och bli ännu bättre inom detta område. Att bara skriva nonsens, håller ej med och så vidare kan alla göra, skriv då ett inlägg där ni berättar om hur det fungerar så tar jag åt mig av er erfarenhet. Det kanske är uppenbart för er, men inte för mig. Har även svårt när folk anklagar en utan att man får en chans att förklara sig. Det är lätt att misstolka varandra på Internet, särskilt när det handlar om 140 tecken korta inlägg, låt då människor få veta vad de gjort fel så man åtminstone kan få förklara sig och bemöta kritiken.

Bara för att jag inte jobbar aktivt med SEO innebär det inte att jag är bakom flötet, analysverktyg och den biten är jag helt förlorad inom, men att kunna läsa artiklar och skriva ihop något som enbart baserats på detta har jag gjort i åtskilliga år, det kan även folk utan vetskap inom området göra. Sedan om det inte helt är rätt får ni skulle Google för, det var de som var källorna till inlägget och ingen annan bemödade sig med att referera till annan fakta som påvisade Google:s fel angående länkbomber.

Imorgon blir det ytterligare en intervju, denna gången ett stort spelföretag. Stay tuned!