Webanalyse case [2 af 3]: Hvordan fikser jeg mine fejlsider

I del 1 af denne webanalyse case gennemgik jeg, hvordan vi opdagede årsagen til de mange besøg på fejlsider (404) hos en af vores kunder. I denne fortsættelse gennemgår jeg, hvordan vi fik løst problemet ved at sende brugerne ind på de rigtige sider alligevel. I det sidste indlæg i case-rækken gennemgår jeg, hvordan du med Google Analytics automatisk kan få besked, når der opstår fejl på hjemmesiden.

Som tidligere nævnt var problemet, at langt de fleste brugere fik en fejl, fordi de forsøgte at tilgå sider, hvis url’er tidligere indeholdt oplysninger om det valgte sprog – men hvor informationen om sproget nyligt var blevet udeladt for at undgå duplicate content.

Kundens url før ændring:    www.kundensWebsite.com/en-IE/enEngelskWebside.aspx
Kundens url efter ændring: www.kundensWebsite.com/enEngelskWebside.aspx

Det væsentligste af problemerne var alle fejlene, som strukturændringen af url’erne medførte.

I samråd med kunden løste vi det ved, at vi på serverniveau (dvs. uden om deres CMS – af hensyn til kompleksitet) oprettede følgende generelle regler:

/en-IE/ -> www.kunde.com
/nl-NL/ -> www.kunde.nl
/en-GB/ -> www.kunde.co.uk
/de-DE/ -> www.kunde.de
/en-US/ -> www.kunde.com
/cs-CZ/ -> www.kunde.cz

Dvs. forsøgte en bruger at tilgå www.kunde.de/en-IE/nogetEngelskIndhold.aspx ville brugeren i stedet blive sendt til www.kunde.com.

Det ideelle havde selvfølgelig været, at sende brugeren over på den tilsvarende side i stedet for bare forsiden, men da siderne adskiller sig fra land til land, var der ingen garanti for, at der fandtes en tilsvarende side. Efter økonomiske og strategiske overvejelser blev denne løsning valgt som den mest passende i kundens situation.

Som det fremgår af grafikken opdagede vi også to andre tendenser til fejlsider:

1. At der kom mange besøg på fejlsider, fordi folk forsøgte at tilgå kundens forrige website (hvor siderne alle endte på “.asp”, mens siderne på de nye website ender på “.aspx”).
2. At andre eksterne hjemmesider sendte linkkærlighed, brugere og SEO-værdi til bestemte sider på kundens hjemmeside – sider som ikke længere findes fordi de enten er blevet fjernet eller omdøbt sidenhen.

Disse fejl kan kunden heldigvis selv fange ved i sit CMS at opsætte det, som i fagsprog hedder 301-redirect. En 301-redirect er i virkeligheden en måde, hvorpå man fortæller serveren, at hvis brugeren beder om at få vist indholdet på adresse A, så skal serveren i stedet vise indholdet på adresse B.

Lad os sige, at vi har flyttet siden “Medarbejdere” fra www.kunde.com/Om-os/Medarbejdere.aspx til www.kunde.com/Medarbejdere.aspx.

Hvis andre hjemmesider har linket til den tidligere placering, vil disse link nu ikke længere virke.

I Dynamicweb kan man heldigvis opsætte de nødvendige 301-redirects, så linkene alligevel virker:

1. 

   Naviger hen til "Management Center"

2. 

   Vælg "Direkte stier"

3. 

   Vælg "Tilføj"

4. 

   Opsæt din redirect

5. Afslut med at klikke på OK-knappen

Nu er der oprettet en redirect, så folk der forsøger at tilgå www.kunde.com/Om-os/Medarbejdere.aspx bliver sendt ind på www.kunde.com/Medarbejdere.aspx.

Det gode ved redirects er, at de virker for tid og evighed, når først de er sat op. Dvs. når kunden har sat dem op én gang, behøver de ikke gøre det igen.

Dog skal redirects vedligeholdes, hvis man igen skifter url-struktur. Dvs. hvis de url’er, redirect’en sender brugerne ind på, stopper med at virke efter ny strukturændring, skal man vedligeholde redirect’en så den fortsætter med at sende folk ind på url’er der virker.

Via redirects kunne vores kunde heldigvis fange de resterende besøg på fejlsiderne ved at omdirigere og dermed beholde brugerne og den gode SEO-værdi, som blev sendt ind på hjemmesiden.

Opsummeret betyder det altså, at det både lykkedes os at fjerne kundens voldsomme problem med duplicate contet OG at sikre en god oplevelse for de brugere, som forsøgte at benytte url’erne fra den gamle struktur. Som en sidegevinst opdagede kunden, at der var gode indkomne links, som pegede på døde sider hvilket gav mulighed for en quickwin både i forhold til brugervenlighed og ikke mindst også SEO ved at omdirrigere trafik fra disse links.

Alt dette skulle kun løses én gang, hvilket betyder, at kunden i fremtiden ikke behøver at bekymre sig – nu er det sat op, og det virker helt automatisk.

I det næste og sidste indlæg i denne case-række, vil jeg gennemgå, hvordan kunden kan forhindre at fejlsider opdages tilfældigt. Løsningen: at systematisere fejlfinding via Google Analytics.