Hoe nieuwsarchieven meestal ontsloten zijn: paginering

Je ziet ze vooral vaak op weblogs: nieuwsarchieven die al het oude nieuws keurig pagineren. Op elke pagina vind je een lijstje van tien nieuwskoppen, ieder met een link naar een aparte pagina met het volledige bericht. Met een bladerfunctie onderaan de pagina spring je van pagina 1 naar pagina 2, naar pagina 3, enzovoorts.

Deze manier van navigeren lijkt veel op de manier waarop Google zoekresultaten presenteert:

Of soms wordt de bladerfunctie simpelweg ingekort tot bijvoorbeeld:

Het bladeren door overzichten die over meerdere pagina’s zijn uitgesmeerd kom je kortom overal tegen op het web. Maar is een wijdverbreide methode ook automatisch een goede methode? Vaak wel, maar niet als het gaat om paginering.

Pagineren is een slechte ervaring voor bezoekers

Om de vergelijking met Google-zoekresultaten even verder door te trekken: als je zelf een zoekterm intikt in Google en je een lijst van gevonden pagina’s krijgt, hoeveel treffers bekijk je dan? De eerste 3, de eerste 10, de eerste 30? Als je een doorsnee gebruiker bent: waarschijnlijk hooguit de eerste 10, en vaak nog minder dan dat.

Uit onderzoek blijkt dat internetgebruikers steeds ongeduldiger worden en al lang niet meer de moeite nemen om na de eerste 10 treffers door te klikken naar het vervolg. Internet is een snel medium, internetgebruikers zijn ongeduldig en hebben een groeiende afkeer van lange overzichten. Een navigatiebalk met de mogelijkheid om naar de volgende pagina met 10 treffers te gaan, en weer een pagina met nog meer treffers, en weer een pagina: het is vaker een afhaakmoment dan een aanmoediging om door te gaan.

Pagineren is ook slecht voor Google

Al vaker heb ik het geschreven: een slechte ervaring voor menselijke bezoekers gaat opvallend vaak samen met een slechte ervaring voor zoekmachines. Zo ook hier. Internetgebruikers haken op zeker moment af, maar Google doet dat ook. Natuurlijk is Google prima in staat om al je tientallen overzichtspagina’s door te fietsen en vandaaruit de volledige berichten te vinden. Maar Google doet dat niet. Op veel sites zie je hetzelfde patroon: vanuit de homepage volgt Google een linkje of drie en de rest laat hij zitten – die zit te ver weggestopt.

Je kunt eenvoudig zelf de proef op de som nemen. Installeer bijvoorbeeld de Firefox-plugin SearchStatus. Als je na installatie gaat surfen, dan zie je rechts onderaan elke webpagina die je bezoekt de pagerank, een getal van 0 tot 10 waarmee Google de reputatie van die pagina classificeert (het groene balkje, niet het blauwe).

Duik nu eens diep in een willekeurig nieuwsarchief, bijvoorbeeld dat van Marketingfacts of Emerce. Bijna overal zie je hetzelfde beeld: nieuwsberichten met een pagerank van 0. Dat betekent dat Google zo’n pagina óf nog helemaal niet heeft ontdekt, óf wel heeft ontdekt maar er geen waarde aan hecht. Wat kun je daaraan doen?

Een XML-sitemap is niet voldoende

De standaardoplossing voor problemen met vindbaarheid in Google is om een XML-sitemap te maken met een volledige inhoudsopgave van je hele site. Zo’n sitemap is niet bedoeld voor menselijke bezoekers, maar alleen om zoeksystemen op de hoogte te houden van wijzigingen op je site.

Aan de hand van de XML-sitemap ziet Google voortaan precies welke pagina’s op je site nog ontbreken in zijn index. Veel contentmanagementsystemen genereren standaard XML-sitemaps, of hebben daar speciale plugins voor. Een kind kan de was doen.

Probleem opgelost? Niet helemaal. Natuurlijk wordt een website nooit slechter van een extra XML-sitemap. Maar een XML-sitemap heeft wel een belangrijke SEO-beperking: hij verbetert wel de vindbaarheid van dieperliggende pagina’s, maar niet de reputatie oftewel de pagerank. Webpagina’s krijgen pas reputatie als ze goede en duurzame links van andere pagina’s krijgen – vanaf de eigen website of vanaf andere sites.

Die duurzaamheid is een probleem bij chronologische paginering. Een recent nieuwsbericht is eerst vindbaar via overzichtspagina 1 (met nieuwsberichten 1 t/m 10), een paar dagen/weken later via overzichtspagina 2 (met nieuwsberichten 11 t/m 20), daarna overzichtspagina 3, enzovoorts. Naarmate het archief groeit, schuift dat bericht verder door en is het steeds een andere overzichtspagina (4, dan 5, dan 6, dan …) die ernaar linkt. De kans is groot dat dat bericht altijd op pagerank 0 blijft steken. Google houdt van duurzaam gestructureerde websites en niet van links die eerst op de ene en dan op de andere overzichtspagina staan.

Hoe het beter kan: een platte linkstructuur

Om oude nieuwsberichten wat pagerank te bezorgen, moeten we dus zorgen voor links vanaf vaste pagina’s, niet vanaf wisselende pagina’s. De simpelste oplossing: maak één lange overzichtspagina met links naar álle oude nieuwsberichten, ook al zijn het er meer dan duizend. In feite laat je dus gewoon de paginering weg. Hou je nog maar één enkele vaste pagina over.

Deze radicale oplossing lost in ieder geval het probleem op van de slechte Google-vindbaarheid. Als de homepage van je website rechtstreeks linkt naar deze overzichtspagina, dan zijn alle oude nieuwsberichten precies twee muiskliks verwijderd van de homepage. Zelfs zonder een XML-sitemap zal Google al je oude berichten vinden.

Wel blijft er nog een ander probleem: een overzichtspagina met honderden of zelfs meer dan duizend links is een slechte ervaring voor je bezoekers (plus een zware belasting voor je cms, dat hiervoor uitgebreide selecties moet uitvoeren). Maar ook daar valt prima iets aan te doen. Allereerst een redactionele ingreep: maak tussenkopjes, bijvoorbeeld om de maanden aan te geven. Dan kunnen bezoekers gerichter in een bepaalde periode zoeken. Bijvoorbeeld alleen de laatste drie maanden. Of alleen het voorjaar van 2005.

Zelfs met tussenkopjes blijft die overzichtspagina nog heel lang. Een tweede ingreep is meer technisch van aard: maak al die tussenkopjes in- en uitvouwbaar. Een voorbeeld is dit nieuwsoverzicht op Klimaatnieuws.nl:

Als je een specifieke maand zoekt, hoef je alleen maar die maand uit te vouwen (onderstaand plaatje is niet klikbaar, ga daarvoor naar Klimaatnieuws.nl):

En als je in een langere periode zoekt, kun je álle maanden uit het hele overzicht in één keer uitvouwen. Op internet zijn veel scripts te vinden voor dit soort uitvouwsystemen, zoek daarvoor op ‘folding menu’. Ze zijn zo gemaakt dat zoekmachines feitelijk alleen maar uitgevouwen maanden zien en dus ook alle nieuwsberichten probleemloos zullen vinden.

Hoe het nóg beter kan: inhoudelijk linken

Niet alle hyperlinks zijn gelijk voor Google. Een link naar een andere pagina met soortgelijke inhoud telt zwaarder dan een link naar een pagina over een heel ander onderwerp. Hoe meer relevante links, hoe beter je reputatie in Google.

Hoe groter je nieuwsarchief, hoe meer raakvlakken er ontstaan tussen al die nieuwsberichten. Daarom: zorg ervoor dat die naar elkaar linken. Niet alleen voor Google, maar ook voor bezoekers is dat prettig. Als die bezoekers vanuit een externe site rechtstreeks op een nieuwsbericht op jouw site uitkomen, dan maak je het ze makkelijk door ze direct te verwijzen naar soortgelijke berichten. Hoeven ze niet je hele nieuwsarchief door te spitten.

Doelgericht hyperlinks aanbrengen tussen nieuwsberichten is wel heel arbeidsintensief. Eigenlijk zou je dit al moeten doen tijdens het schrijven van een nieuwsbericht, niet pas achteraf. Gelukkig zijn er foefjes om een bestaand archief achteraf te verrijken met inhoudelijke links. Bij veel nieuwsberichten zie je bijvoorbeeld onderaan een rijtje gerelateerde berichten. Zoiets als:

In veel contentmanagementsystemen kunnen deze gerelateerde links automatisch worden gegenereerd. Bij WordPress heb ik goede ervaringen met de plugin YARPP (Yet Another Related Posts Plugin). Deze plugin beoordeelt op basis van titelwoorden, categorieën, trefwoorden en andere kenmerken in hoeverre twee nieuwsberichten met elkaar verwant zijn.

Er is een nadeel aan dit soort plugins: ze zijn slecht voor de performance van je site. In principe moet voor elk nieuwsbericht een ingewikkelde zoekselectie op de rest van het archief worden uitgevoerd. Dat hakt erin, uit eigen metingen op deze site bleek de gemiddelde laadtijd per nieuwspagina met 45% toe te nemen.

Ik raad daarom aan om zo’n plugin alleen toe te passen in combinatie met caching. Dat houdt in dat die ingewikkelde zoekselectie niet elke keer opnieuw wordt uitgevoerd, maar alleen op gezette tijden, bijvoorbeeld eens per uur, eens per dag of nog minder vaak. Hoe je caching moet toepassen? Dat hangt af van je contentmanagementsysteem. Vaak heeft zo’n systeem kant-en-klare caching-modules.

En nog een kleine tip, maar met grote gevolgen. Bij een plugin als YARPP kun je kiezen of de gerelateerde berichten onderaan een nieuwsbericht altijd ouder zijn, of ook van recenter datum kunnen zijn. Met andere woorden: mag een nieuwsbericht ook verwijzen naar andere berichten die later zijn gepubliceerd?

Mijn advies: kies altijd het laatste, want dan wordt de pagerank van Google gelijkmatiger over je nieuwsarchief uitgesmeerd. Kies je voor alleen linken naar oudere berichten, dan krijgen de alleroudste berichten uit je archief relatief de meeste pagerank, terwijl je je bezoekers misschien juist liever wat meer actuele nieuwsberichten zou laten lezen.

Dus: mocht de performance er niet onder lijden, dan heb je met het toevoegen van gerelateerde berichten een snelle manier om een nieuwsarchief inhoudelijk te verrijken. Daar worden zowel Google als bezoekers blij van.

Nog even recapituleren

Er zijn talloze manieren om een grote verzameling oude nieuwsberichten beter toegankelijk te maken voor bezoekers én beter vindbaar voor Google, maar paginering is zo ongeveer de allerslechtste.

Mijn twee favoriete methoden om het beter te doen heb ik hierboven beschreven:

• een simpel totaaloverzicht (waar je eventueel een in-/uitvouwmogelijkheid aan kunt toevoegen),
• inhoudelijke links aanbrengen (al of niet geautomatiseerd) tussen verwante berichten.

Natuurlijk zijn er nog meer manieren te bedenken voor een betere structuur. Gebruik je zelf een andere methode, dan ben je welkom om dat hieronder te melden!

Lagere pagerank

Het was ergens in november 2009 toen ik in Google Analytics merkte dat mijn wandelsite Tweevoeter plotseling een dipje liet zien in bezoekcijfers. Niet veel, hooguit zo’n 10 procent, maar wel duidelijk aanwezig. Van de ene op de andere dag 1 op de 10 bezoekers kwijt – en ze kwamen niet terug, niet na een paar dagen, niet na een week, ook niet na een maand.

Wat was hier aan de hand? Door eindeloos te segmenteren in Google Analytics bleek dat de terugloop vooral zat in het bezoek aan de voorpagina en het bezoek via Google. En de oorzaak daarvan was snel gevonden: de Google-pagerank van de voorpagina bleek gedaald van 5 naar 4. Een hele schok. Mijn site had al zeven jaar lang een pagerank van 5 gehad. Waarom opeens die daling?

Twee avonden lang liep ik alle bekende SEO-vuistregels na: zijn er geen belangrijke inkomende links weggevallen, kloppen de metatags, is de HTML wel valide, noem maar op. Zonder succes, het afgelopen halfjaar was er niets fundamenteels veranderd. Had ik soms een belangrijke nieuwe ontwikkeling gemist? Ook een extra rondje langs de bekendste SEO-blogs leverde geen nieuwe inzichten op.

Uitgaande links

Dan maar eens in de vakliteratuur duiken en een recent SEO-boek aanschaffen: SEO Warrior. Een gedegen boek, maar ook dit werk leek in eerste instantie weinig nieuws te bieden. Maar een terloopse opmerking ergens halverwege het boek gaf toch een aanknopingspunt: Google zou minpunten toekennen als een website veel uitgaande links heeft die niet (meer) werken, zo werd gesteld. Hé, dat is interessant, toch maar eens checken.

Tijd om een simpel maar krachtig programmaatje op Tweevoeter los te laten: Xenu’s Link Sleuth. Deze linkchecker loopt alle pagina’s van je site langs en controleert de uitgaande links. Het resultaat loog er niet om: Tweevoeter bevat zo’n 5200 pagina’s informatie met meer dan 6000 links naar andere websites. En daarvan bleken er maar liefst 1100 niet te werken.

Broken links repareren

Meer dan duizend ‘broken links’! Oef, werk aan de winkel. Het repareren van al deze verouderde links kostte bijna een maand. Elke avond een uurtje aan de slag: links verbeteren, links afvoeren en soms hele alinea’s herschrijven als essentiële links niet meer werkten.

Na deze operatie volgde het grote wachten. Waren de verouderde links inderdaad de oorzaak van de gedaalde pagerank? En zo ja, hoe lang zou het duren voordat Google mijn site zou rehabiliteren? Dat laatste bleek anderhalve maand te zijn. Toen liet Google Analytics van de ene op de andere dag weer een sprongetje zien, maar dan de goede kant op. En inderdaad, de pagerank was weer terug op 5. Het kan haast niet anders of die tijdelijke daling had te maken met die meer dan duizend kapotte links. Ik had mijn lesje geleerd.

Kortom

Dus… staat je website vol met uitgaande links? Vertrouw niet op je bezoekers dat ze zo netjes zijn om verouderde links aan je door te geven. Mijn ervaring is dat ze daarvoor simpelweg niet de moeite nemen.

Je zult dus zelf van tijd tot tijd je hele site moeten doorlopen, al of niet met behulp van een geautomatiseerde tool als Xenu. Geen bijster interessante klus, maar de meerwaarde is groot: niet alleen bezoekers waarderen je content meer als je die up-to-date houdt, maar ook Google doet dat.

Daarbij is het verraderlijke van Google dat je niet meteen gestraft wordt voor verouderde links. Het lijkt er dus op dat dat pas gebeurt als voor Google ‘de maat vol is’: van de ene op de andere dag krijg je een lagere pagerank en dus minder bezoekers.

En de gevolgen daarvan zijn nog weken tot maanden zichtbaar. Heb je eenmaal alle links weer gerepareerd, dan duurt het blijkbaar nog een tijd voordat het almachtige Google zijn sanctie weer ongedaan maakt. Ook voor het up-to-date houden van hyperlinks geldt dus het aloude devies: voorkomen is beter dan genezen.

voorbeeld van een Yahoo-pipe

Output valideert niet altijd

Yahoo Pipes gebruik ik onder meer om Twitter-accounts automatisch te voorzien van nieuwsberichten, zoals @climatenews, @openfeed, @internetprivacy en @fietsen. Een deel van die nieuwsberichten komt bij Google News vandaan. Dat gaat in grote lijnen zo:

• Doe een vernuftige zoekactie in Google News.
• Ergens onderaan de pagina met zoekresultaten vind je een onopvallende link naar de bijbehorende RSS-feed.
• Die RSS kun je weer in Yahoo Pipes samenvoegen met andere relevante feeds.
• Het resultaat koppel je met Twitterfeed (eveneens gratis) aan een Twitter-account.

Klinkt makkelijk, toch?

Wat ik echter gaandeweg heb doorgekregen is dat de output van Yahoo Pipes niet altijd valide is, als je Google News als een van de bronnen gebruikt. Dat zit ‘m vooral in het enorm complexe Description-veld, zoiets als:

<description>
<table border=”0″ cellpadding=”2″ cellspacing=”7″ style=”vertical-align:top;”><tr><td width=”80″ align=”center” valign=”top”><font style=”font-size:85%;font-family:arial,sans-serif”><a href=”http://news.google.com/news/url?sa=t&amp;fd=R&amp;usg=AFQjCNGSJyymp7CH52iDQ8gJCe4urSlKRQ &amp;url=http://www.pzc.nl/algemeen/buitenland/7864079/Bijna-1-miljoen-euro-voor-WikiLeaks.ece”><img src=”http://nt0.ggpht.com/news/tbn/XNe_X4KojhXvtM/0.jpg” alt=”" border=”1″ width=”80″ height=”53″ /><br /><font size=”-2″>PZC</font></a></font></td><td valign=”top” class=”j”><font style=”font-size:85%;font-family:arial,sans-serif”><br /><div style=”padding-top:0.8em;”><img alt=”" height=”1″ width=”1″ /></div><div class=”lh”><a href=”http://news.google.com/news/url?sa=t&amp;fd=R&amp;usg=AFQjCNGSJyymp7CH52iDQ8gJCe4urSlKRQ &amp;url=http://www.pzc.nl/algemeen/buitenland/7864079/Bijna-1-miljoen-euro-voor-WikiLeaks.ece”><b>Bijna 1 miljoen euro voor <b>WikiLeaks</b></b></a><br /><font size=”-1″><b><font color=”#6f6f6f”>PZC</font></b></font><br /><font size=”-1″>WASHINGTON (ANP) – De belangrijkste financiële tak van onthullingssite <b>WikiLeaks</b>, de in Duitsland gevestigde Wau Holland Foundation, heeft dit jaar ruim <b>…</b></font><br /><font size=”-1″><a href=”http://news.google.com/news/url?sa=t&amp;fd=R&amp;usg=AFQjCNH7x_XSIbuCV2JMU20AYe3xWZS38w &amp;url=http://www.nrc.nl/nieuws/2010/12/24/17863/”><b>WikiLeaks</b> ziet kosten verdubbelen</a><font size=”-1″ color=”#6f6f6f”><nobr>NRC Handelsblad</nobr></font></font><br /><font size=”-1″><a href=”http://news.google.com/news/url?sa=t&amp;fd=R&amp;usg=AFQjCNHX0rdS9YfBLrjAUj6MEYMobsNPRQ &amp;url=http://www.bndestem.nl/algemeen/economie/7858514/WikiLeaks-geeft-meer-geld-uit.ece”><b>WikiLeaks</b> geeft meer geld uit</a><font size=”-1″ color=”#6f6f6f”><nobr>BN/De Stem</nobr></font></font><br /><font size=”-1″ class=”p”></font><br /><font class=”p” size=”-1″><a class=”p” href=”http://news.google.nl/news/story?pz=1&amp;ned=nl_nl&amp;ncl=d6Di-E4d_v7NuZMXPZX_KsO42dD4M”><nobr><b>alle 76 nieuwsartikelen&nbsp;&raquo;</b></nobr></a></font></div></font></td></tr></table>
</description>

Het gevolg: Twittterfeed raakt de klus kwijt bij het inlezen van je feed en skipt de hele inhoud, waardoor je Twitter-account een paar dagen lang niet meer wordt  bijgewerkt – net zolang totdat dat ene probleembericht zo oud is geworden dat het uit je feed is verdwenen.

Hoe dit te verhelpen? De eenvoudigste oplossing is het Description-veld te legen, maar in Yahoo Pipes heb je geen operator om velden te legen. Wat ook niet blijkt te werken is de inhoud van een veld met de Regex-operator (^.*$) te vervangen door helemaal niets, of door een enkele spatie. Om een of andere reden werkt dit wel met tekstuele inhoud, niet met HTML-content.

Na wat experimenteren vond ik wel deze workaround: gebruik de Rename-operator om het veld item.description te hernoemen naar iets onzinnigs als item.nothing. In de uitvoer van Yahoo Pipes worden betekenisloze velden als item.nothing automatisch geskipt. En opeens valideert je feed weer wel en plaatst Twitterfeed de nieuwste berichten weer door naar je Twitter-account.

De V2-engine heeft bugs

Sinds zijn introductie in februari 2007 werkt Yahoo Pipes onder de motorkap met de zogenoemde V1-engine. Sinds juni 2010 is er een V2-engine, die betere performance en meer stabiliteit belooft. Maar de makers zeggen het zelf al:

there will be bugs, this isn’t ready for primetime

En dat klopt: als je overschakelt op de V2-engine, dan blijkt je pipe opeens andere uitvoer te genereren. Neem bijvoorbeeld deze reguliere expressie:

^.*http://(.*\.nl)/.*$     →     $1

Unix- en Linux-kenners zullen dit meteen herkennen: deze reguliere expressie extraheert .nl-domeinen. De link:

http://www.knmi.nl/cms/content/89547/knmi_annual_report_2009

wordt dan:

www.knmi.nl

Bij de V1-engine werkt dat inderdaad zo, prima. Maar de V2-engine denkt er anders over. Het heeft me twee uur puzzelen gekost voordat ik ontdekte dat die er gewoon niets mee doet:

www.knmi.nl/cms/content/89547/knmi_annual_report_2009

Terugswitchen naar V1 loste het probleem meteen op. Kortom: blijf lekker de V1-engine gebruiken.

Yahoo Pipes is traag

En dan bedoel ik ook echt tráág. Zolang je Yahoo Pipes gebruikt voor automatisch gevulde Twitter-accounts, dan merk je hier weinig van – Twitterfeed importeert je pipe achter de schermen. Maar als je een pipe op een webpagina plaatst (zie bijvoorbeeld het nieuwsoverzicht op de voorpagina van Klimaatnieuws.nl), dan kun je wel allerlei issues verwachten. De laadtijd van een complexe pipe kan 5 tot 10 seconden bedragen, die nog eens bovenop de laadtijd van de rest van de pagina komt. Op mijn eigen server merk ik dat het embedden van een Yahoo-pipe in een webpagina de load average soms flink omhoog jaagt.

Caching van webpagina’s kan dit probleem een stuk verlichten, maar hoe langer de levensduur van je cache, hoe meer je feed gaat achterlopen. En ook bij caching zul je altijd bezoekers blijven houden die incidenteel geconfronteerd worden met een niet-gecachte pagina en dus onaanvaardbaar lang moeten wachten.

Wat te doen om de beroerde laadtijd van Yahoo Pipes te verbeteren? Daarvoor bleek een simpele oplossing: geen hele webpagina’s cachen, maar alleen de feed zelf. Een cronjob op mijn server laadt elk half uur alle benodigde pipes in en slaat de uitvoer lokaal op. Alle sites op de server kunnen simpelweg volstaan met het embedden van de lokale kopieën. Sinds ik deze oplossing heb geïmplementeerd, is de gemiddelde laadtijd van alle websites op mijn server met 12 procent afgenomen.

Kortom

Yahoo Pipes is en blijft een geweldige tool om webdata te verwerken en nieuwe RSS-feeds en mashups samen te stellen. Maar bijna vier jaar na de introductie krijg ik de indruk dat Pipes nog steeds niet helemaal uit het experimentele stadium is gekomen. Zodra je deze service voor professionele doeleinden gebruikt, dan is er maar één devies: testen, testen en nog eens testen – zowel qua output als qua performance. En hier en daar een wat minder elegante maar wel doelgerichte tweak kan een enorme winst opleveren.

Dan maar een zoekscript downloaden en op je eigen server installeren? Ik had er verschillende uitgeprobeerd, maar het indexeren van tienduizenden pagina’s vormt een flinke belasting van je processor en het opslaan van die index kost bovendien veel diskruimte. Ook de interfaces vond ik niet handig in elkaar zitten.

Dus besluit ik toch maar eens Google Custom Search te proberen. Dat scheelt diskruimte en ach, Google bezoekt mijn site toch al, dus vormt deze dienst in feite geen extra belasting. Om kort te gaan: de lokale zoeker van Google draait inmiddels tot volle tevredenheid. Niet alleen fijn voor de bezoekers, maar vooral voor mezelf als beheerder – ik kom pagina’s en berichten tegen die ik al lang vergeten was en ook ben ik veel beter in staat bezoekers gericht door te verwijzen naar bepaalde hoekjes van de site. Mooi is ook dat je de Google-zoekmogelijkheid tot op zekere hoogte in je eigen layout kunt gieten, alleen lettertype en -grootte zijn niet te beïnvloeden. En Google houdt niet op bij 500 pagina’s, de grens van Atomz.

Google Custom Search draait ook zelfstandig, dus niet gekoppeld aan een eigen site. Je kunt een verzameling websites opgeven die Google voor je doorzoekt. En als je geen waslijst van honderden websites wilt opgeven, heeft Google een heel simpel alternatief: als je een webpagina kunt vinden waar al je favoriete websites worden gelinkt, dan kun je tegen Google zeggen dat je alle websites op die ene pagina wilt doorzoeken en Google zoekt het allemaal uit.

Een voorbeeldje is dit zoeksysteem voor Nederlands nieuws. Deze zoeker was in één minuut gemaakt, namelijk door simpelweg kranten.startpagina.nl en kranten.startkabel.nl als linklijsten op te geven. Deze twee pagina’s bevatten zo’n beetje alle Nederlandse nieuwssites. Het resultaat: een zoeksysteem voor oude nieuwsberichten. In feite een soort Google News, maar dan eentje die niet alleen de laatste 30 dagen doorzoekt. Zoek bijvoorbeeld op wilders koran en je ziet wat deze politicus de afgelopen jaren allemaal over de Koran heeft geroepen – voor zover de media dat hebben opgetekend.

Nog een voorbeeld is een zoeksysteem voor natuur en milieu, eveneens gevoed met een aantal startpagina’s. Is dat handig? Ja, dat is handig, want als je met de ‘gewone’ Google op bos zoekt, krijg je veel ruis: de Boeddhistische Omroep Stichting (BOS), Wouter Bos, een internetbedrijf, een incassobureau en Stef Bos. Maar de gespecialiseerde natuurzoeker toont veel betere resultaten, alleen Wouter Bos en het Bos en Lommerplein horen er niet thuis. Een aardig alternatief dus als je kinderen een spreekbeurt aan het voorbereiden zijn en je hen wat doelgerichter wilt laten zoeken, zonder het ze gelijk weer ál te gemakkelijk te maken.

Toch maar een Flash-licentie aanschaffen? Na enig zoeken blijkt dat niet nodig. Op Download.com zijn diverse programma’s te vinden om diashows met overvloei-effecten te maken. Ik heb er een aantal uitgeprobeerd. Kort en goed: wat mij betreft de beste is FlashSlider.

Het werkt reuze simpel: geef breedte, hoogte en snelheid (in fps, frames per seconde) op. Selecteer daarna via een Verkenner-venstertje de dia’s. Vervolgens stel je in wat voor overvloei-effect je wilt hebben, hoeveel seconden de plaatjes worden getoond en hoe lang het overvloeien duurt. Klik daarna op de knop Afspelen om het resultaat te bekijken. Tevreden? Klik op de knop Voorstelling publiceren en verzin een bestandsnaam, die je vervolgens in je webpagina kunt verwerken.

Tot aan 24 frames per seconde is FlashSlider gratis, voor hogere snelheden moet je je voor een paar tientjes registreren. Webdesign hoeft niet duur te zijn.

Google Analytics is een walhalla voor wie een website beheert en van cijfers houdt. Vroeger vonden we Nedstat al heel mooi en informatief, maar zonder te overdrijven kun je rustig stellen dat Google Analytics honderd keer meer informatie biedt: welke pagina’s en paginaclusters worden het meest bezocht, hoe komen bezoekers binnen, hoe lang blijven ze op de site, welke pagina’s bezoeken ze daarbij, wat zijn de belangrijkste afhaakpagina’s, en nog véél meer informatie. En dit alles over elke gewenste periode. De resultaten worden getoond in tabellen (te downloaden als Excel-spreadsheet), staaf- en taartdiagrammen. Kortom: Google Analytics is een Efteling voor wiskundigen.

Bijna wekelijks neem ik wel even de tijd om de Google Analytics-grafiekjes te bekijken. En vrijwel altijd stuit ik wel op een verrassend nieuw inzicht in een van mijn websites. Een voorbeeld betreft mijn wandelsite Tweevoeter.nl. In november 2005 was ik om technische redenen genoodzaakt om alle pagina-adressen van deze site te voorzien van de extensie .php. Binnen enkele weken had Google alle nieuwe adressen verwerkt.

Operatie geslaagd? Helaas, een paar honderd andere websites bleven linken naar verouderde pagina’s. De belangrijkste mailde ik met het verzoek hun link aan te passen, maar daar werd maar mondjesmaat gehoor aan gegeven. Drie maanden later gaf Google Analytics aan dat nog steeds 20 procent van alle bezoekers op een niet-bestaande pagina terechtkwam. Dat is veel.

Volgende ingreep: een error 404-pagina. Voor wie deze term niet kent: een error 404 is de fout die je krijgt als je een niet-bestaand adres intikt, bijvoorbeeld van een pagina die inmiddels verhuisd is. Door de error 404 op te maken in de vormgeving van je site, inclusief alle navigatiemenu’s, kunnen bezoekers vanuit de niet-bestaande pagina doorklikken naar andere delen van je site en op zoek gaan naar de gewenste informatie.

Operatie alsnog geslaagd? Helaas. Einde 2006, een jaar na de adreswijzigingsoperatie, viel me bij mijn wekelijkse rondje Google Analytics iets op. De gemiddelde klikdiepte (het aantal bezochte pagina’s per bezoeker) voor de hele site lag op 2,8. Dat is niet veel. Toen ik vervolgens de relatie legde tussen ingangspagina en klikdiepte, dan bleek de error 404-pagina met afstand onderaan te staan met een gemiddelde klikdiepte van slechts 1,2. Omgerekend: minimaal 80 procent van de bezoekers die een niet-bestaande Tweevoeter-pagina bezochten, besloot direct af te haken; hooguit 20 procent (en waarschijnlijk nog een stuk minder) deed nog een poging de informatie elders op de site te vinden.

Conclusie: zelfs een opgemaakte error 404-pagina met een nette foutmelding is voor de meeste bezoekers een afknapper. Om de klikdiepte wat op te schroeven zit er maar één ding op: alle 404-errors wegwerken, zodat bezoekers alleen op pagina’s terechtkomen met relevante inhoud. Om dat voor elkaar te krijgen heb ik eerst in beeld moeten krijgen welke niet-bestaande pagina’s het meest werden opgevraagd. Ik heb daarop een scriptje gemaakt dat mij een e-mail stuurde zodra iemand een 404-error kreeg. De eerste dag kreeg ik zo’n 1500 e-mails. De belangrijkste niet-bestaande pagina’s heb ik daaruit gevist. Voor elke pagina heb ik een zogeheten ‘redirect’ aan mijn .htaccess-bestand toegevoegd, bijvoorbeeld:


RedirectMatch permanent ^/drenthe/$ http://www.tweevoeter.nl/drenthe.php


Deze regel betekent dat elke bezoeker van het adres www.tweevoeter.nl/drenthe/ automatisch wordt doorgeschakeld naar het nieuwe adres www.tweevoeter.nl/drenthe.php. Zo heb ik elke niet-bestaande pagina gekoppeld aan het nieuwe adres. Met snel resultaaat: binnen een dag was het aantal mailtjes gezakt tot nog maar een paar honderd. En een week later nog maar 50. Je vraagt je misschien af: waarom heb je deze redirects niet meteen in 2005 ingebouwd? Dat had een praktische reden: de site draaide toen nog op een Windows-server in een shared hosting-omgeving. Nu staat de site op een eigen virtuele Linux-server en dan heb je veel meer mogelijkheden om de webserver te beïnvloeden.

Inmiddels bevat mijn .htaccess-bestand een stuk of 500 redirects. Dat is erg veel en het zal ook de webserver iets vertragen, maar 404-errors komen vrijwel niet meer voor. En het belangrijkste: volgens Google Analytics is de klikdiepte gestegen tot 3,3, dus een verhoging van 0,5. Dit verschil lijkt weinig indrukwekkend, maar het betekent wel dat je met hetzelfde aantal bezoekers bijna 20 procent meer pageviews genereert en de advertentie-inkomsten navenant stijgen. En dat met hooguit een halve dag werk. Was elke halve werkdag maar zo lucratief…

Overigens ben ik nog steeds niet van de 404-errors verlost, ik krijg nog altijd zo’n 20 tot 30 mailtjes per dag. Maar dit heeft andere oorzaken. Aan de adressen te zien zijn dit meestal geen verdwaalde bezoekers, maar pogingen van hackers om uit te zoeken welke toepassingen op mijn site zijn geïnstalleerd. Verder zijn er ook wel eens bezoekers van vlees en bloed die behoorlijk wat af blijken te knoeien op je site. Maar dat is weer een verhaal apart…

Deze keuze heeft een lange voorgeschiedenis. In de jaren 90 was WS_FTP min of meer de standaard. Om redenen die ik ben vergeten, ruilde ik het al snel in voor LeechFTP, dat simultane verbindingen ondersteunde en waarvan ik de interface prettiger vond.

Toen LeechFTP een zachte dood leek te sterven, werd SmartFTP mijn nieuwe favoriet. Prima programma, maar niet gratis en ook niet altijd even betrouwbaar: bij grote uploads – bijvoorbeeld 50 MB verdeeld over meer dan 1000 bestanden – bleef het uploaden wel eens om onverklaarbare redenen hangen. Het open-source programma FileZilla bleek op dit laatste punt betrouwbaarder, dus een overstap was alweer snel gemaakt.

Ook FileZilla bleek zijn manco’s te hebben. Standaard Windows-functionaliteit als ‘sleur & pleur’ was gebrekkig geïmplementeerd: om bestanden te uploaden kun je ze wel verslepen van de Verkenner naar FileZilla, maar omgekeerd kun je geen bestanden downloaden door ze in omgekeerde richting te verslepen. En ook bestanden op de server editen vind ik niet handig: een rechtsklik op het bestand en dan de optie View / Edit kiezen. Bij SmartFTP hoefde je daarvoor alleen maar op F7 te drukken.

Maar een jaar geleden heb ik voor het eerst kennisgemaakt met WinSCP. Dit programma is speciaal bedoeld voor bestanden up- en downloaden met behulp van het Secure Copy-protocol (SCP), zeg maar via een beveiligde verbinding. WinSCP vind ik qua gebruiksvriendelijkheid een verademing: het is gratis, betrouwbaar en het doet alles goed wat FileZilla en SmartFTP naar mijn smaak minder handig doen. Bijvoorbeeld een bestand editen: gewoon dubbelklikken en de editor wordt opgestart.

Tot voor kort was het nadeel van WinSCP dat het alleen geschikt was voor beveiligde verbindingen, maar gisteren hoorde ik op een cursus tot mijn grote genoegen dat dat niet meer het geval is. Versie 4 van WinSCP ondersteunt ook ‘gewoon’ FTP. En WinSCP heeft nog veel meer handigheidjes – zo kun je direct vanuit dit programma overschakelen naar PuTTY om speciale commando’s op de server uit te voeren (bijvoorbeeld tar) die vanuit een Verkenner-achtige omgeving niet mogelijk zijn.

Ik ben helemaal om: WinSCP is voorlopig mijn eerste keus. Met de nadruk op ‘voorlopig’, want over een paar jaar is er vast weer een beter alternatief…

Uiteindelijk hebben we gekozen voor betalen via de telefonische betaaldienst Mollie, die bijvoorbeeld ook gebruikt wordt door Nieuwsbank.nl. De betaling is in hooguit twee minuten geregeld: je belt een 0900-nummer, je toetst een zescijferige code in en je krijgt meteen toegang tot de route, die je vervolgens kunt uitprinten. De kosten worden automatisch verrekend via je telefoonrekening. Je hebt geen creditcard of abonnement nodig en de transactie verloopt geheel anoniem.

Een ideale betaalmethode? De praktijk zal het leren.

Zijn belangrijkste truc pas ik al regelmatig toe, vooral als ik voor opdrachtgevers op locatie werk: lees en beantwoord je e-mails nog maar één keer per dag. Als anderen iets dringends te melden hebben en ze krijgen niet direct antwoord, dan gaan ze vanzelf wel bellen. Je moet natuurlijk wel telefonisch bereikbaar zijn, anders loop je het risico dat je een dringende boodschap mist – en dat heb ik ook wel eens meegemaakt. Voor journalisten zal deze tip dus niet werken, want ze willen natuurlijk geen primeurtjes mislopen.

Naast discipline zijn er denk ik nog veel meer foefjes om efficiënter met e-mail om te gaan, vooral op het technische vlak. Binnenkort zal ik mijn persoonlijke ervaringen posten.

Ik schreef dat je WordPress niet alleen voor weblogs kunt gebruiken, maar ook als een simpel contentmanagementsysteem voor een bescheiden zakelijke website. Is het inderdaad zo simpel, vroeg die opdrachtgever zich af?

Mijn eerste test is te bekijken op www.klog.nl. Het enige wat ik nog niet voor elkaar heb, is de volgorde van de statische pagina’s rechts. Waarschijnlijk zie ik hierbij iets heel simpels over het hoofd.

De volgende stap: een theme downloaden en kijken hoe deze testsite met voornamelijk statische pagina’s er dan uit komt te zien. Wordt vervolgd!