WordPress SEO

Guru op de sofa : een technisch-psychologisch reisverslag

Een maand geleden zag ik mijzelf opeens m’n seoguru-site op de schop nemen. Dat was wel even schrikken. Een tijdje al was duidelijk dat er een aantal stappen voorwaarts gezet moesten worden, maar dat het blijkbaar opeens nú moest gebeuren had ik niet verwacht. Want wat gebeurde er? Ik weet niet meer hoe of waarom, maar ik kwam ergens een WordPress theme onder de naam “Graphene” tegen. Een theme bij WordPress verzorgt in essentie de vormgeving van de site. Het zag er mooi uit en het bleek een open source project te zijn: verschillende ontwikkelaars zijn al verschillende jaren bezig om er een mooie en slimme theme van te maken. WordPress zelf is al open source, en blijkbaar heb je ook open source themes. Interessant. Omdat alles bij WordPress zo verschrikkelijk eenvoudig is kan je met een paar drukken op de knop zo’n theme installeren. En het mooie is dat je ook eenvoudig weer kan terugschakelen, indien de vormgeving niet naar de zin is. Hetzelfde geldt voor plugins. Dit zijn functionaliteiten die je aan de site kan toevoegen, zoals een broodkruimelpad, om maar wat te noemen. Je zoekt je geschikte theme of plugin, downloadt en activeert die via je WordPress administratie paneel en klaar is Kees. Niet goed? Deactiveren en over tot de orde van de dag! Maar zo simpel was het deze keer niet…

Nadat ik de Graphene theme had gedownload en geactiveerd, zag het er eigenlijk meteen al heel aardig uit en begon ik de zaken die er nog niet goed uitzagen meteen al wat bij te schaven. In de site was trouwens slechts één onderdeel in WordPress ondergebracht, namelijk het onderdeel achter de menuoptie “SEO blog”, nu ook nog zichtbaar linksboven in het menu. De homepage en alle andere menu-onderdelen waren met de hand gebouwd. Voor het seo forum gebruikte ik externe software, namelijk van vBulletin. Zou ik ook de homepage en alle andere onderdelen onder WordPress kunnen plaatsen? De WordPress installatie was echter in de seo-blog subdirectory aanwezig. Dat bleek inderdaad mogelijk, zoals ik las op de WordPress site onder het kopje “Using a pre-existing subdirectory install”. Maar ja, als je dergelijke stappen begint te zetten, en je config- en index.php files begint te wijzigen, dan is er al meer nodig dan alleen een druk op de knop om de boel weer naar de oude situatie terug te krijgen. Maar gelukkig ging deze stap goed en was ook opeens de homepage een WordPress pagina geworden.

Dit was al een fijn resultaat, want als ik bijvoorbeeld nieuwe trainingsdata aan de site wil toevoegen (wat elke maand gebeurt), moest ik dat steeds op verschillende plekken doen. Nu hoefde dat al op één plek minder. Het gekke was natuurlijk wel dat nu alleen de homepage en de “SEO blog” in de nieuwe vormgeving, en de rest in de oude vormgeving, te zien was. Op dat moment is het zaak –zo hield ik mijzelf voor- je eigen site, ondanks de toch aanzienlijke hoeveelheid dagelijkse bezoekers, even niet al te serieus te nemen. Maar, hoe zit het eigenlijk met de SEO kwaliteit van deze WordPress theme? M’n goede posities op vele seo gerelateerde zoekwoorden zie ik niet graag om zeep geholpen door mijn ondoorgrondelijke impulsen. Het was inmiddels een dag later en jawel, de voor seo zo belangrijke title van de homepage bleek helemaal leeg:

Niet fijn. Misschien moet ik toch maar terug naar de oude site, dit slaat nergens op. Bovendien heb ik op dit moment helemaal geen tijd voor dit soort gefriemel. Laat ik in ieder geval de  title snel even invullen. En, zoals een goed programmeur betaamt, een backup maken van database en bestanden… De rest van de voor wordpress SEO belangrijke zaken bleken in de basis behoorlijk goed te staan, dus dat was bemoedigend. De “All In One SEO Plugin”, die al geïnstalleerd stond t.b.v. de oude blog, bleef zijn werk goed doen, nog steeds resulterend in dezelfde statische, beschrijvende URL’s. En ook de “Robots Meta” plugin van Joost de Valk bleef fier overeind, waardoor de pagina’s die ik op bijvoorbeeld “noindex” had gezet, niet opeens alsnog in de zoekresultaten terecht kwamen. Het was een wankel evenwicht, maar besloot niet terug te deinzen voor de techniek en met goede moed de weg vooruit te blijven bewandelen.

Allereerst besloot ik de sectie waar ik mijn boek onder de aandacht breng, ook te gaan ombouwen naar WordPress. Die was de meest eenvoudige, daar die uit slechts twee pagina’s bestond. De hoofdpagina was seo-boek.html, met daarachter een pagina boek-bestellen.html, waar ik eigenlijk al nooit zo blij mee was. /seo-boek/ en vervolgens iets van /seo-boek/bestellen/ is voor SEO beter omdat je hiermee ook via de URL’s een veel duidelijkere structuur neerzet. Bovendien kan je directories naar de toekomst toe verder in de diepte uitwerken, wat de opzet veel dynamischer maakt. Dus dit was een mooi moment om dat meteen goed te doen, dus heb ik twee –wat ze bij WordPress noemen- “Pages” gemaakt en toegevoegd. Uiteraard ook meteen via de .htaccess 301-redirect’s gelegd van de oude naar de nieuwe URL’s. Dit is voor SEO erg belangrijk omdat de kracht die je op de oude pagina’s hebt opgebouwd (voor het grootste deel) wordt doorgegeven aan de nieuwe. Een 301-redirect staat voor “een definitieve verhuizing”, vertel ik mijn studenten al jaren. Wat? Een definitieve verhuizing? Dat betekent dat de weg terug naar mijn oude opzet nu definitief is afgesloten…

De invulformulieren op de site heb ik –jaren geleden alweer- zelf geprogrammeerd in de programmeertaal Perl. De software bestaat hieruit dat ik mooie formulieren kan bouwen in html, daar variabelen aan kan toekennen, die kan parsen en koppelen aan een mysql database. Aan die tabellen in de database heb ik weer andere functionaliteiten gekoppeld, zoals het kunnen versturen van nieuwsbrieven, etc. Bij de oude site riep ik gewoon de bestelpagina aan (d.w.z. het perl-script) die in de vormgeving van de site een pagina toonde met het invulformulier. Ik dacht die functionaliteit er nu ook snel even in te kunnen hangen, maar daar verkeek ik mij op iets dat me drie dagen kostte om op een deugdelijke manier op te lossen. Het oude script genereerde complete pagina’s onder zijn eigen URL, terwijl ik nu juist alles onder WordPress wilde brengen. Ok, dan gooi ik de hele ombouw eruit en toon ik de output van het script in een iframe binnen mijn nieuwe WordPress bestelpagina. Dat blijkt dus helemaal mis te gaan, omdat iframes geen variabele hoogte kennen. Op forums wordt veelvuldig gesproken over een oplossing via “jQuery iframe sizing”, maar geloof me, dat is een hopeloze weg. Het beetje geloof dat ik nog in de iframe had, is nu definitief verdwenen.

Gelukkig hebben we een veel modernere techniek om de uit externe scripts gegenereerde html binnen een bepaalde pagina te tonen, en dat is Ajax. Maar dat is wel iets meer werk, hoewel uiteindelijk toch ook overzienbaar en vooral veel eleganter. Ik realiseerde me echter opeens dat het misschien nóg wel veel slimmer was om te kijken of er mooie plugins bestaan waarmee formulieren kunnen worden gemaakt, en jawel die zijn er. De mooiste die ik tegenkwam was “Contact Form 7”, waarmee via een tweede plugin, namelijk “Contact Form to DB Extension”, een koppeling kon worden gemaakt met de mysql database. Precies wat ik wil. Nu bleek dat die koppeling erg beperkt was: het bleek niet mogelijk een koppeling te maken met mijn bestaande tabellen. De Extension genereert eigen tabellen, met een eigen (in mijn optiek zeer primitieve) structuur. Dit was geen optie. Dus dan toch maar Ajax, hetgeen voor een Amsterdammer bepaald geen scheldwoord is.

Ajax is feitelijk “gewoon” javascript, dat asynchroon (dus parallel aan andere processen, hetgeen snelheidswinst kan opleveren) bepaalde delen van de pagina kan verfrissen. De URL en de ombouw blijven na de uitvoering van een ajax- instructie dus onveranderd. De data-uitwisseling tussen de client (d.w.z. de browser) en de server vindt plaats via de zogenaamde “XMLHttpRequest”. De code die ik toen op mijn WordPress-bestelpagina kon plaatsen blinkt uit in eenvoud. De kern ervan is de volgende regel:

<div id=”result”></div>

Een leeg divje, dus met alleen een id, die ik de naam “result” heb gegeven. De inhoud van de div gaat dynamisch gevuld worden via Ajax! Maar hoe dan? Door op die pagina ook de volgende code op te nemen:

<script type=”text/javascript”>

xmlhttpPost(“/cgi-bin/seo-boek.cgi”); </script>

Deze javascriptcode, die wordt meteen uitgevoerd wordt bij het laden van de pagina, roept de xmlhttpPost aan met als argument mijn perl script, die de output moet leveren t.b.v. de invulling van het divje.

De xmlhttpPost functie is een veelgebruikte functie die we overal van het internet kunnen plukken (bijvoorbeeld hier). Het moet nog wel even in de head-sectie van de pagina worden geplaatst, danwel direct danwel via een extern .js bestand. Nu kan ik de functie wel in een bestaand .js bestand plaatsen van mijn theme, maar probleem is dat die wordt overschreven door een nieuwe versie als ik een Graphene upgrade uitvoer. Om dergelijke problemen te voorkomen blijkt WordPress een mooie oplossing ingebouwd te hebben, namelijk zogenaamde “childthemes”. Je kan in je childtheme (wat gewoon een directory naast je theme-directory is) code opnemen die uitgevoerd wordt voordat het corresponderende bestand van de hoofdtheme wordt uitgevoerd. Daar zou dus ook mijn javascript-code kunnen worden toegevoegd. Een andere manier is om in de headsectie van de WordPress-pagina’s standaard een aanroep van een nieuw .js-bestand op te nemen waar dan de eigen javascript-code in wordt geplaatst. Nadeel van beide methodes is dat het bestand dan op iedere pagina wordt geladen, ook als er helemaal geen invulformulier aanwezig is, en die code dus helemaal niet nodig is. Dat zou de snelheid van de site verslechteren en de site daarmee een ietsje zoekmachine onvriendelijker maken. Ik zocht (was niet eenvoudig) maar vond een plugin waarmee we pér pagina code kunnen toevoegen aan de head-sectie van Pages en Posts, namelijk Header en Footer. Inmiddels begrijp ik dat dit ook via zogenaamde hooks in WordPress kan. Hooks zijn de heilige knoppen binnen WordPress: op vele plekken in zowel de core WordPress bestanden als ook de (goed geprogrammeerde) theme bestanden kunnen we code aanhaken om zodoende het standaardproces te beïnvloeden. Plugins maken hier veelvuldig gebruik van. Maar dit terzijde, de Header en Footer plugin was reeds geïnstalleerd en voldeed prima, want hiermee kon ik de koppeling tussen de WordPress bestelpagina en mijn bestaande scripts dus eindelijk gaan maken.

Dat leek allemaal voortreffelijk te verlopen, behalve dat die mooie XMLHttpRequest niet overweg bleek te kunnen met html-tables, terwijl die wel die basis vormen voor mijn bestelformulier. Die moesten dus nog even worden omgezet naar divjes… In tegenstelling tot wat nog wel eens wordt geroepen zijn “table-less” pagina’s echt niet beter voor SEO dan pagina’s mét tables. Dat maakte deze omzetting dus een wat irritante bezigheid. Maar goed, ik ben het maar aangegaan, maar was alles bij elkaar inmiddels wel weer een dag verder… Die volgende dag hadden mijn huisgenoten (in tegenstelling tot de dagen ervoor) een vrolijke aan me: het formulier werkte perfect (zie de bestelpagina van mijn seo boek, probeer maar eens…). Hoewel… De hele bestelling vindt nu onder één URL plaats. Hoe kan ik dan in Google Analytics een conversiedoel koppelen aan één specifieke bedank-URL? Alles vindt door die mooie Ajax-oplossing immers plaats onder één URL: het lege bestelformulier, de eventuele verzuchtingen dat niet alle velden correct zijn ingevuld en ook mijn diepe dankbetuigingen voor de geslaagde bestelling. Godzijdank ben ik niet de eerst die met Ajax werkt: Google heeft voor dit probleem een prachtige oplossing bedacht. In Javascript kan je op de volgende manier als het ware een bedankpagina simuleren, en dié koppelen aan een conversiedoel:

_gaq.push([‘_trackPageview’, ‘/boek-besteld’]);

Nu werkt het echt perfect. Deze belangrijke psychologische doorbraak viel helaas samen met het besef dat ik met de omarming van WordPress op een heel ander spoor van programmeren terecht was gekomen. Het voordeel van dit spoor is het feit dat je heel eenvoudig gebruik kan maken van het werk dat grote communities van programmeurs gratis en voor niets voor je uitvoeren. Het nadeel is dat je afhankelijk van hen aan het worden bent. Als je iets wilt realiseren dat nét iets afwijkt van de voorgedefinieerde paden dan moet je je in code verdiepen die niet van jezelf is. En bovendien: wát te doen als ze op een goed moment (en 100% begrijpelijk) stoppen met het onderhouden van hun theme of plugin, en die daardoor niet meer compatible blijft met (de nieuwste versies van) WordPress zelf? Waar ik voorheen de controle had over iedere regel code, ben ik die nu voor een belangrijk deel kwijt. Het levert tijdwinst op, maar op een andere manier kost het ook weer veel tijd. Voor SEO is het daarbij zeker niet noodzakelijk om met dergelijke ontwikkelingen mee te gaan. In dit verband is het bijvoorbeeld een fabel dat Google WordPress-sites beter zou beoordelen dan gelijkwaardige andere sites. Wel is het zo dat in WordPress een aantal voor SEO basale zaken goed zijn geregeld, of via aanvullende plugins alsnog goed kunnen worden geregeld. Maar met een eenvoudige Dreamweaver-site, of eenvoudig CMS, kan dat óok heel goed. Maar laat ik hier niet te lang over nadenken, want de site ligt nog op de operatietafel en ik kan (en wil) toch niet meer terug…

Tijdens dergelijke operaties ben je continu aan het zoeken op het web. Af en toe zag ik mijn eigen seoguru-site als hoogste ranken op mijn eigen zoekvragen… Maar normaal gesproken waren het anderen die toch zeer interessante zaken wisten te melden. Ook Google zelf. Ik las bijvoorbeeld dat de integratie van mijn site met mijn Google Plus profielpagina sterker kon worden door wederzijds te linken: door 1) op de profielpagina (via “Profiel bewerken”) aan te geven dat ik “Bijdrager” ben aan www.seoguru.nl en 2) in de homepage van de site een link op te nemen naar de profielpagina. De  volgende link moet daartoe in de head-sectie van de pagina worden opgenomen:

<link href=”https://plus.google.com/105039657769046310513” rel=”publisher” />

De href bevat de verwijzing naar mijn profielpagina. Zaken uit de profielpagina (zoals bijvoorbeeld een foto) kunnen dan op de volgende manier in de zoekresultaten worden getoond (gegenereerd door Google’s Rich Snippets Testing Tool):

Nu is het niet zo interessant mijn hoofd in de resultaten te zien, maar het maakt wel dat het zoekresultaat meer opvalt en de CTR daardoor hoger zal uitpakken. Via de “Allow REL= and HTML in Author Bios”-plugin heb ik rel=”publisher” link opgenomen.

We zullen het komend jaar overigens steeds vaker de hoofden van mensen in de zoekresultaten zien verschijnen. Met de introductie van Google Plus en de integratie ervan binnen de reguliere, organische zoekresultaten is er een verschuiving aan het plaatsvinden van sites-met-autoriteit naar mensen-met-autoriteit, technisch gezegd: van PageRank naar een soort SocialRank. Tot op heden is het zo dat verwijzingen vanaf andere sites ons autoriteit opleveren. Het wordt nu echter steeds belangrijker dat niet alleen sites, maar vooral ook mensen zich met jou (en je site) gaan bezighouden: dat ze je over je praten, je opnemen in hun Google Plus circles, linkjes opnemen in hun tweets, etc. Het wordt nu nóg meer zaak om als mens of bedrijf (Google Plus pagina’s kunnen ook door bedrijven worden aangemaakt, lees hier meer) autoriteit te worden (of blijven) op het gebied waarop je je producten of diensten aanbiedt. Concreet betekent dit dat we manieren moeten gaan bedenken om mensen te motiveren zich te gaan aanmelden voor onze circles. Nog niet in google.nl, maar wel al in google.com, kunnen we het effect op de zoekresultaten zien van het opnemen van personen in onze circles. Ga maar eens kijken…

Er zijn echter meer mogelijkheden om de zoekresultaten te verrijken met zaken die met name de CTR verhogen. Google heeft over de laatste jaren verschillende methodes omarmd om content van semantiek, ofwel betekenis, te voorzien. Van die methodes lijkt microdata (schema.org) het nu te gaan winnen. Dit is een belangrijke ontwikkeling, die een aantal jaar in de steigers heeft gestaan (in goed Grieks “beta”  genaamd), maar nu toch echt een vlucht aan het nemen is. Een opvallend voorbeeld zijn de sterretjes die we steeds vaker in de zoekresultaten zien:

Voor WordPress blijkt een mooie plugin te bestaan om dit eenvoudig voor elkaar te krijgen, namelijk GD Star Rating. Dit is een belachelijk uitgebreide plugin om bezoekers de mogelijkheid te geven iets heel simpels te doen, namelijk een beoordeling toe te kennen aan de inhoud van de betreffende pagina. Onderaan dit artikel kunt u dat ook doen, dank… Als u niet wilt scrollen: het ziet er als volgt uit.

Daar de ratings op html niveau in microdata zijn weergegeven, kan Google ze overnemen in de zoekresultaten. Toch wel leuk. De plugin voorziet er echter ook meteen in om beoordelingen te verwijderen of achter de schermen zélf beoordelingen toe te voegen. Er kan dus enorm mee gespamd worden, wat precies de reden is dat ik niet verwacht dat deze koppeling van microdata reviews en de Google snippets lang stand zal houden. Maar goed, voor nu is het leuk.

De rest van de site omzettingen verliep vanaf dit moment voorspoedig. De diensten en de trainingspagina’s, inclusief alle mogelijke offerteaanvraag- en inschrijfformulieren kon ik nu in een handomdraai realiseren. En er kon meteen een mooie URL-structuur worden gerealiseerd. Bij WordPress verloopt dit via parent- en childpages. Op de parentpage vermeld ik bijvoorbeeld een overzicht van mijn SEO trainingen, en op de childpages ónder die parentpage de uitwerkingen van die trainingen. De URL van de parentpage wordt dan /seo-training/ en bijvoorbeeld de incompany training: /seo-training/incompany/. Perfect! En de breadcrumbs lopen daar automatisch gelijk mee op. Tot slot verliep ook de omzetting van het overzicht met seo logohouders (de aanbevolen bureaus, in het menu) ook zonder noemenswaardige problemen. Done!

Voor de volledigheid van dit technisch/psychologische WordPress SEO reisoverzicht wil ik nog noemen welke plugins ik gedurende de afgelopen weken nog meer heb geïnstalleerd en waarom.

Allereerst is dat Breadcrumb NavXT, dat mooie broodkruimelpaden op de pagina’s opneemt. Voor SEO is dit belangrijk, omdat het voor Google dan duidelijker wordt hoe de structuur van de site in elkaar zit. Ook vanuit PageRank gedacht zijn breadcrumbs interessant: door de terugverwijzingen stuwen de pagina’s PageRank naar de hogere gebieden van de site, m.a.w. naar dié pagina’s die normaal gesproken ook de meeste kracht nodig hebben omdat ze zich richten op de meer algemene dus meer competieve zoekwoorden.

Verder heb ik Canonical URL’s geïnstalleerd. Via deze plugin kan eenvoudig een rel=”canonical” worden toegevoegd aan die pagina waarvan de inhoud een kopie is van een andere. Op veel fora en blogs leeft nog steeds het hardnekkige misverstand dat “dubbele content” tot penalties kan leiden. Dat is echter niet zo: dubbele content is onderdeel van de natuur van het Internet. Het enige punt is dat dubbele content binnen de eigen site maakt dat de kracht van de content over meerdere pagina’s wordt verdeeld, en daarmee wordt verzwakt. Door gebruik te maken van de rel=”canonical” worden de krachten gebundeld in één (canonieke) URL, waardoor de scoringspotentie van de betreffende content wordt vergroot.

Omdat ik niet op iedere pagina dezelfde side widgets wilde hebben (dat zijn die blokjes rechts op de pagina’s) wilde ik de mogelijkheid hebben die in principe per pagina te activeren of deactiveren. Via de Display widgets plugin bleek dat heel eenvoudig te realiseren.

Om de laatste posts uit mijn seo forum via een widget op de verschillende WordPress pagina’s te kunnen tonen heb ik de vBulletin Latest Threads plugin geïnstalleerd. Die werkt prima, hoewel alleen dié widget niet via de voorgenoemde plugin op pagina niveau uitgeschakeld kan worden. Het seo forum is trouwens het enige deel binnen de site dat nog niet over is naar de nieuwe vormgeving. Ik wil deze overgang echter combineren met een upgrade van de vbulletin software, zodat ik ook daar veel meer van allerlei social media functionaliteiten gebruik kan gaan maken. Maar dat alles moet even doordacht gaan gebeuren…

Een belangrijke plugin is WP Super Cache. Door al die interessante WordPress uitbreidingen moet de server behoorlijk aan de bak om de pagina’s te genereren op het moment dat iemand een pagina bezoekt. Pagina’s worden on the fly gegenereerd vanuit de wordpress core files+theme+widgets+plugins+database. En dat is nogal wat. De WP Super Cache plugin zorgt er voor dat de dynamisch gegenereerde pagina’s op de server worden opgeslagen in een statisch .html bestand. Dat levert vanzelfsprekend een enorme tijdswinst op. Er zit een uitgebreid administratie menu achter deze plugin om e.e.a. te finetunen.

En -last but not least- moest er een backup plugin worden geïnstalleerd. Daar het forum op dezelfde mysql database werkt als de blog, kan de hele site (op de bestanden na, die hebben een afzonderlijke backup voorziening) in principe via één plugin-actie worden gebackupped. Na wat experimenten met verschillende plugins (ze werkten niet allemaal), heb ik uiteindelijk een heel eenvoudige geïnstalleerd die zijn werk prima doet, namelijk WordPress Database Backup.

Bent u er nog? Ik wil u danken voor het aanhoren van mijn relaas. Het is een heel verhaal geworden, maar mogelijk heeft u er zelf ook iets aan gehad. Ik ben in ieder geval blij dit alles even met u te hebben mogen delen.

Nog één dingetje. Ik durf er bijna niet over te beginnen, maar er is één puntje waar ik nog mee zit. Een piepklein puntje. Ik vind de vormgeving van de site bij nadere beschouwing eigenlijk helemaal niet zo mooi…

Suggesties???

[important]Nagekomen bericht: sinds medio 2013 is Marketingmed m’n hofleverancier geworden op het gebied van serieuze en kwalitatief hoogwaardige wordpress tips. Doe er uw voordeel mee…[/important]