Duplikatinnhold: Case Study av Crestock.com

Av: , May 12, 2007

Det har vært mye snakk om duplikatinnhold og de problemene dette skaper for mange nettsted. Her er et konkret eksempel og mine tiltak for å få bukt med problemet.

Som de fleste sikkert har fått med seg er et av nettstedene jeg arbeider med Crestock Stock Photos, en bildebank som etterhvert begynner å få en ganske anstendig mengde bilder. Rundt 100.000 så langt faktisk. Og de er knallbra.

SÃ¥ langt har mitt hovedfokus vært Ã¥ drive trafikk og god, gammeldags PR – arrangere heftige konkurranser og skrevet bloggposter som har gitt dem en ganske anstendig trafikkvekst siden jeg begynte med dem i midten av november i fjor: fra 40.000 unike besøkende per mÃ¥ned til ca 230.000 unike besøkende nÃ¥ i april.

Ved Ã¥ kjøre hardt pÃ¥ slike trafikkskapende tiltak har jeg oppnÃ¥dd bÃ¥de svært mange besøkende via linker fra andre nettsted, og i tillegg har disse linkene resultert i en meget fin økning i søkemotortrafikk – fra 13.800 i november til 110.000 i april:

NÃ¥ som nettstedet begynner Ã¥ fÃ¥ bra med organisk trafikk fant jeg ut det var pÃ¥ tide Ã¥ se pÃ¥ problemer med duplikatinnhold – og det kan du trygt si det er mer enn nok av.

For å fortelle litt om nettstedets oppbygning først

Hvert bilde har en egen side: /images/[bilde-id]-[bildenavn].aspx. Hvert bilde har tagger som beskriver bildet, og disse er linket til tagsider: /image-keyword/[tag].aspx som lister opp alle bildene som har denne taggen.

Et av de største problemene ligger i at mange av tag-sidene har gjerne 50 til over 100 sider med bilder som har denne taggen i seg, eksempelvis “food“. Hver “arkiv-side” har variabelen “?page=[tall]” i seg.

Om du ser pÃ¥ “arkiv-sidene” ser du fort at alle disse har identisk tittel som hoved-tag siden, og med sÃ¥ forsvinnende lite rent tekstuelt innhold som det er pÃ¥ hver av disse sidene sier det seg selv at problemene med duplikatinnhold og stikkordkannibalisering blir formidable.

Tilsvarende problemer finnes på andre områder på nettstedet også, men jeg tror dette eksempelet illustrerer bra selve kjernen i problematikken.

Ettersom i hvertfall Google og Yahoo nå faktisk støtter dynamiske variabler har jeg lagt inn en blokkering som bør ta seg av dette problemet:

Disallow: /*?page=*

robots.txt

Grunnen til at jeg har blokkert for indeksering av RSS feeds er pÃ¥ grunn av statistikksystemet Unica NetInsight som vi nylig har implementert hvor vi identifiserer nye RSS abonnenter via en unik ID som legges pÃ¥ RSS-feed URL’en.

Hadde jeg tillatt indeksering av disse, ville det generert en ny URL hver gang en søkerobot kom pÃ¥ besøk. En mulig fix pÃ¥ dette kunne selvsagt vært IP delivery (IP basert cloaking), hvor IP’er som identifiseres som en søkemotor fÃ¥r servert de “rene” RSS-feedene, mens normale besøkende fÃ¥r tildelt disse unike ID’ene.

Men desverre er slike avanserte cloaking-løsninger ikke helt gratis, og jeg tror nok kanskje at det ville kostet mer enn det smaker – i hvertfall for øyeblikket. Dette er jo forresten et bra eksempel pÃ¥ hvor cloaking helt klart ikke benyttes som en black hat teknikk, men løser et problem pÃ¥ en lovlig mÃ¥te.

Det skal bli spennende Ã¥ se hva som skjer nÃ¥r søkemotorene, og spesielt Google brgynner Ã¥ reindeksere nettstedet, men tidligere erfaringer, bÃ¥de for megselv og andre har vist trafikkøkninger fra søk fra 100% til 400%…


3 kommentarer

Av Geir , October 18, 2009



Av Sverre Bech-Sjøthun , October 19, 2009





Legg inn en kommentar

Din email adresse vil aldri bli publisert eller misbrukt - Bortsett fra om du legger igjen kommentarspam.
Da blir vi sinte

Nødvendige felt er merket med *

*

*





Du burde følge oss på

RSS Feed Twitter

Mailoppdatering

(dette med spam gidder vi virkelig ikke, så du kan ta det helt med ro)