MaxCDN blundert met SEO advies voor CDN

Al weer enige tijd geleden las ik het artikel How To Improve Your SEO With Robots.txt and Canonical Headers, waar Ivan Dabic van MaxCDN je probeert te helpen met SEO advies voor als je een Content Delivery Network gebruikt. Je mag toch verwachten een grote partij als MaxCDN de kennis in huis heeft om juist advies te geven. Niks is minder waar, MaxCDN blundert met SEO advies!

Het artikel bleek al geruime tijd te bestaan, de oudste reactie dateert alweer van twee jaar geleden:

Great post Ivan!!

Net als die eerste reactie kun je er nog vele ‘bedankjes’ vinden. Laat je door dit soort reacties niet in de war brengen, en blijf zelf kritisch. Mijn bevindingen waren namelijk dat het advies op vele vlakken totaal niet klopt. Om dit aan de kaak te stellen en tevens mijn bevindingen te laten checken door andere ‘collegae’, heb ik een topic geopend in het Webmaster Central Help Forum: MaxCDN giving WRONG advice about indexing images placed on CDN.

Ik moet zeggen, Ivan was er als de kippen bij om ook in te haken op de discussie aldaar, en inmiddels heeft hij het artikel aangepast. Om te leren van het foutieve advies, heb ik dit voor je bewaard:

MaxCDN blundert met SEO advies voor CDN

De blunders van MaxCDN

1. Duplicate content penalty

search engines can penalize sites for “duplicate content”

Het klopt dat het gebruik van een CDN duplicate content kan veroorzaken, en dat een canonical link element hiervoor een oplossing biedt. Mocht je het duplicate content probleem om welke reden dan ook niet oplossen, is het niet zo dat je daarvoor een duplicate content penalty van Google zult krijgen. Ik heb dit reeds uitgebreid behandeld in een eerder artikel: Duplicate content en SEO.

2. Verkeerde canonieke URL voor afbeeldingen

Crawlers see your site the way you do, including loading content from CDNs. This can cause problems because you want the original paths to appear in search results, not the paths on the CDN

Dit is deels waar, maar niet voor de URL’s van afbeeldingen! En laten ze nou net het voorbeeld van canonicals uitwerken met een afbeelding als uitgangspunt bij punt 3, Test your responses. Hoe het wel moet heb ik reeds behandeld in een eerder artikel: Afbeeldingen via CDN, duplicate content oplossingen! Vergeet ook niet de afbeeldinglinks in je XML Sitemap aan te passen. Hoe dit moet voor de WordPress SEO plugin van Yoast leg ik dit uit in het artikel Wijzigen afbeeldinglink in sitemap WordPress SEO.

3. HTTP header canonical voor afbeeldingen

Fout 2 zoals hierboven beschreven betekent dat MaxCDN in de HTML van een webpagina linkt naar een afbeelding via de CDN URL http://cdn.domain.com/path/to/file.jpg, maar deze geindexeerd wil hebben in Google via de oorspronkelijk URL http://domain.com/path/to/file.jpg.

Hoewel dat dus al niet juist is, gaat de oplossing die ze aandragen om dit realiseren ook niet helpen!

Als content via twee of meerdere URL’s beschikbaar is kun je Google de gewenste URL die geindexeerd moet worden doorgegeven via een canonical. Voor een HTML document kan dit via het canonical link element. Voor andere bestanden, zoals PDF documenten, kun je een canonieke link opgeven in je HTTP header.

MaxCDN adviseert in hun artikel om de HTTP header ook te gebruiken voor afbeeldingen, maar die oplossing heeft helemaal geen effect. In het artikel van Google over Canonieke URL’s:

Google ondersteunt deze linkheaderelementen momenteel alleen voor Google Zoeken.

Dit zal dus niet gaan werken voor Google Afbeeldingen, ook wel Image Search genoemd.

4. Canonical onzichtbaar maken voor Google door blokkade robots.txt

Op het moment dat je een canonieke URL aan Google doorgeeft via een canonical link element of de HTTP header, moet het bestand wel leesbaar/toegankelijk zijn voor de crawler van Google. Hoe moet Google anders weten welke URL jij als canonieke URL hebt opgegeven?

Hier maakt MaxCDN het helaas nog bonter in hun advies. Ze maken wel gebruik van een canonical, maar blokeren vervolgens de crawler van Google via een robots.txt bestand voor alle bestanden die via de CDN URL’s beschikbaar zijn:

Update your robots.txt Your origin server has its own robots.txt, available at the root of the site. On the CDN, change your custom robots.txt settings (under the “SEO” tab in the control panel) and decide what content to allow. Once canonical URLs are setup, you can save bandwidth by blocking all crawlers from the CDN itself:

User-agent: *
Disallow: /

Make sure this “block everything” robots.txt goes on your CDN, not your origin server.

Duplicate content moet gewoon door Google gecrawled kunnen worden, de canonical zal in de meeste gevallen door Google gerespecteerd worden waarmee je dus het duplicate content probleem hebt opgelost.

Dit is hetzelfde principe wat ik uitleg in mijn artikel over crawlen, indexeren en robots.txt voor WordPress:

Robots meta tags and X-Robots-Tag HTTP headers are discovered when a URL is crawled. If a page is disallowed from crawling through the robots.txt file, then any information about indexing or serving directives will not be found and will therefore be ignored. If indexing or serving directives must be followed, the URLs containing those directives cannot be disallowed from crawling.

Heeft Ivan geleerd van mijn topic in het Google Webmaster Central Help Forum? Je kunt het lezen in het verbeterde artikel. Het onderdeel waar het om gaat noemt Ivan nu ‘Setting Up a “Crawler Friendly” CDN’. Heeft hij het nu bij het juiste eind?

Algemene voorwaarden deponeren bij KvK, ik niet!

Bij het laten opstellen van Algemene Voorwaarden via VeiligDoen wordt gevraagd of je je Algemene Voorwaarden gaat deponeren bij de KvK. Baat het niet, dan schaadt het niet was mijn idee hierbij.

In mijn Algemene Voorwaarden van WS Internet Services is dan ook keurig opgenomen:

Vindplaats

Deze Algemene Voorwaarden zijn gedeponeerd bij de KvK te Almere onder nummer 55419038.

Van toepassing is steeds de laatst gedeponeerde versie c.q. de versie zoals die gold ten tijde van het totstandkoming van de rechtsbetrekking met WS Internet Services.

Algemene voorwaarden deponeren niet verplicht

De Algemene Voorwaarden deponeren bij de KvK is niet verplicht. De KvK legt uit dat het echter handig kan zijn in hun artikel Algemene voorwaarden deponeren:

  • als u uw voorwaarden niet aan uw klant kunt overhandigen, bijvoorbeeld bij telefonische verkoop, dan kan hij ze toch opvragen en inzien;
  • als bewijs, om te voorkomen dat er discussie ontstaat welke voorwaarden van toepassing waren op het moment dat de overeenkomst tot stand kwam.

Dit is echter niet op mij en de meeste ondernemers van toepassing.

Zoals je in het artikel Moet u uw voorwaarden deponeren bij de KVK? van ICTRecht kunt lezen zijn de Algemene Voorwaarden gewoon van kracht wanneer u ze voor of bij het sluiten van het contract (de aanvaarding) aan de wederpartij beschikbaar heeft gesteld.

Dit levert in de praktijk dan ook nooit problemen op:

Een PDF is immers altijd wel bij een e-mailtje te voegen, en op een website kan akkoord met de algemene voorwaarden altijd gevraagd worden.

Kosten deponeren algemene voorwaarden KvK

Tweede reden om de Algemene Voorwaarden niet te deponeren, is simpelweg dat het ook nog eens geld kost. Het deponeren kost op moment van schrijven € 18,- per jaar. Dit is niet veel. Maar omdat het tevens niet verplicht is maak ik deze kosten liever niet.

De ‘Vindplaats’ is bij mij dus geschrapt uit de Algemene Voorwaarden

Afbeeldingen via CDN, duplicate content oplossingen!

De noodzaak van dit artikel is omdat ik lange tijd Google heb verward met duplicate content op mijn website RuzzleOnline.nl. De afbeeldingen zijn door het gebruik van een Content Delivery Network (CDN) via twee URL’s bereikbaar geworden, en hier ben ik wat betreft zoekmachine optimalisatie niet goed mee omgegaan. Hoewel het activeren van een CDN tegenwoordig met één druk op de knop geregeld is, is dit dus een goed voorbeeld dat je altijd kritisch moet zijn en de gevolgen voor SEO volledig moet begrijpen. Bezint eer ge begint.

CDN veroorzaakt duplicate content

Niet elke CDN veroorzaakt duplicate content. MaxCDN, het Content Delivery Network in kwestie, is echter een zogeheten ‘origin pull CDN‘. De afbeeldingen upload je altijd naar je eigen webserver, de origin pull CDN maakt daarvan een kopie en plaats die op al hun servers. Dit heet ook wel caching. Dit veroorzaak duplicate content, omdat de afbeeldingen vervolgens via twee URL’s te benaderen zijn:

  • de standaard URL: http://ruzzleonline.nl/images/androidapp.png;
  • de CDN URL: http://cdn.ruzzleonline.nl/images/androidapp.png.

De CDN URL kun je via je eigen DNS provider bepalen door het toevoegen van een CNAME record en deze te laten verwijzen naar de servers van je CDN. In de HTML code van je website wordt er dus niet meer gelinkt naar de afbeeldingen die op je eigen server staan, maar naar de afbeeldingen die op het CDN staan. Onderstaande afbeelding toont deze CDN URL in mijn HTML:

CDN afbeeldinglink in HTML broncode
CDN afbeeldinglink in HTML broncode

 

Oplossing 1: gebruik een ander soort CDN

Het makkelijkste is natuurlijk dat de afbeeldingen maar te benaderen zijn via één URL. Op die manier kan er immers geen sprake zijn van duplicate content. Dit wordt ook aangegeven door Google in het artikel 1000 Words About Images.

Q: Is it a problem if my images can be found on multiple domains or subdomains I own — for example, CDNs or related sites?
A: Generally, the best practice is to have only one copy of any type of content. If you’re duplicating your images across multiple hostnames, our algorithms may pick one copy as the canonical copy of the image, which may not be your preferred version. This can also lead to slower crawling and indexing of your images.

Met een origin pull CDN is dit naar mijn weten niet mogelijk. Ik verwacht dat dit wel het geval is met een push CDN, maar ik moet mij nog verder verdiepen in de verschillende soorten Content Delivery Networks. Het artikel Content Delivery Network (CDN)- Distribute your site across the web lijkt mij dan zeer de moeite waard.

Er is echter ook nog een verschil tussen de traditionele CDN’s en bedrijven die werken als een ‘distributed proxy’, zie CDN Images in Sitemap:

A radically different approach would be to replace CDN providers and go with CloudFlare instead of Amazon (for images at least). Since it works as a distributed proxy between your origin server(s) and clients machines, not by moving files from slow to fast servers as done by standard CDNs, your URLs don’t change.

Bedrijven als CloudFlare zijn geen traditionele CDN’s, maar bieden dit aan als één van hun vele features. CloudFlare legt het principe distributed proxy uit in hun artikel What is CloudFlare.

Traditional CDNs can be accurately described as massively distributed hosting, where CloudFlare is more accurately described as a caching reverse proxy. What this means is that, unlike traditional CDNs, CloudFlare handles all requests to a website.

Het kan natuurlijk nooit kwaad de klantenservice van een bedrijf te testen, en dat is exact wat ik gedaan heb bij CloudFlare.

Q: Can you explain a little bit more how it is possible I still serve my images from my same URL’s while you also are a CDN?
A: CloudFlare is your DNS provider, you configure the DNS for our internal traffic (CloudFlare to server), we configure DNS for external traffic (client to CloudFlare.) We configure it to where DNS will point to a CloudFlare proxy server (nginx) and decide what to cache by default and by what you choose with pagerules:

So if something is cacheable we save it to our nginx servers, if not (such as html) we just pass it through. So the next request for the cache content will hit nginx and then send it back to the client instead of asking for it from your origin.

Een nog uitgebreidere uitleg vind je hier: How does CloudFlare work.

Ook Incapsula werkt op deze wijze. De bezoekers van je website, of eigenlijk hun webbrowser, vragen bestanden niet meer rechtstreeks op bij je eigen server, maar komen eerst terecht bij de servers van CloudFlare of Incapsula. De gecachte afbeeldingen (en overige bestanden) worden op die manier vanaf de servers van CloudFlare of Incapsula teruggestuurd naar de webbrowser van de bezoekers, in plaats van je eigen server te belasten. Het enige wat nodig is om van deze CDN feature gebruik te maken, is dat CloudFlare of Incapsula fungeert als je DNS provider, zodat de bezoekers eerst doorgestuurd/gefilterd kunnen worden door hun servers.

Naast de bovenstaande link met uitgebreide uitleg over hoe CloudFlare werkt, legt Incapsula het ook goed uit in hun FAQ.

Your DNS records direct your visitors to your web server IP. In order to start routing traffic through Incapsula and enjoy our security and acceleration services, your DNS records should instruct visitors to send requests to the Incapsula servers. By making two simple DNS changes, your traffic will first be filtered by Incapsula and then forwarded to your web server. There will be no down time during the transition.

Oplossing 2: de juiste canonieke URL voor afbeeldingen

De realiteit is echter dat mijn afbeeldingen wél via twee URL’s te benaderen zijn nu ik gebruik maak van MaxCDN. Gelukkig zijn er veel methodes om Google te vertellen welke van de twee URL’s je nou geindexeerd wilt hebben. De URL die je geindexeerd wilt hebben is de zogeheten canonieke URL. Daarmee los je het duplicate content probleem op.

Los je het duplicate probleem niet op, dan is er verder ook niets aan de hand. Zoals reeds eerder werd benoemd in dit artikel is het gevolg dan wel dat Google zelf bepaald welke van de twee URL’s de canonieke URL is die geindexeerd gaat worden. Dit staat ook in het Google helpartikel Canonieke URL’s gebruiken:

Hoewel we u aanraden een van deze methoden te gebruiken, is geen van de methoden vereist. Als u geen canonieke URL aangeeft, identificeren we de versie of URL die volgens ons het beste is.

Je zult je misschien afvragen, of je Google nou het beste de CDN URL of de standaard URL voor je afbeeldingen kan laten indexeren. Het antwoord is simpel. In mijn eerdere artikel over duplicate content had ik reeds onderstaande YouTube video ingevoegd, waar Matt Cutts uitlegt dat als er sprake is van duplicate content je zelf consistent moet zijn en altijd de gewenste URL’s moet gebruiken in je website.

Pick one “canonical” URL and ensure you  link consistently within your site.

Het feit dat in alle HTML nu verwezen wordt naar de CDN URL’s, is een signaal aan Google dat dit de gewenste URL is die Google moet gaan indexeren!

Oplossing 3: gebruik XML-sitemap om voorkeurs-URL’s voor dezelfde inhoud op te geven

In hetzelfde Google helpartikel over Canonieke URL’s gebruiken, wordt aangegeven dat ook het gebruik van een sitemap Google helpt te bepalen welke versie van de duplicate content je geindexeerd wilt hebben:

We kunnen niet garanderen dat we de URL’s gebruiken die u via een sitemap verzendt, maar het verzenden van een sitemap is een goede manier om Google te laten weten welke pagina’s op uw site u het belangrijkst vindt.

In de sitemap neem je ook links op naar je afbeeldingen, en dat is precies waar ik onoplettend ben geweest! Mijn website is gebouwd met WordPress en daar gebruik ik de SEO plugin WordPress SEO by Yoast. Deze geneert mijn XML-sitemap, maar die verwees nog steeds naar de afbeeldingen op mijn eigen server!

Afbeelding URL WordPress SEO XML Sitemap
Afbeelding URL WordPress SEO XML Sitemap

Ik gaf Google dus lange tijd ‘mixed signals’. In mijn HTML verwees ik naar de CDN URL’s, terwijl mijn sitemap verwees naar de originele URL’s. Mijn sitemap wordt gegenereerd door de WordPress SEO plugin. In mijn artikel Wijzigen afbeeldinglink in sitemap WordPress SEO leg ik uit hoe je dit kunt aanpassen.

Je kunt altijd linken naar de CDN URL’s van je afbeeldingen, waar die ook gehost worden, zoals aangegeven in het artikel 1000 Words About Images:

Q: I’m using a CDN to host my images; how can I still use an Image Sitemap?
A: Cross-domain restrictions apply only to the Sitemaps’ tag. In Image Sitemaps, the tag is allowed to point to a URL on another domain, so using a CDN for your images is fine. We also encourage you to verify the CDN’s domain name in Webmaster Tools so that we can inform you of any crawl errors that we might find.

En in mijn situatie ga ik dus ook http://cdn.ruzzleonline.nl verifiëren in Google Webmaster Tools!

Wijzigen afbeeldinglink in sitemap WordPress SEO

In dit artikel beschrijf ik hoe je de afbeeldinglinks in de XML Sitemap van de WordPress SEO plugin veranderd. Meest gebruikelijke scenario om dit te doen is als je een CDN (Content Delivery Network) gebruikt en de afbeeldingen dus via een CDN URL geladen worden.

Standaard wordt de oorspronkelijke afbeeldingslink gebruik voor de sitemap:

Afbeelding URL WordPress SEO XML Sitemap
Afbeelding URL WordPress SEO XML Sitemap

Met het gebruik van een CDN voor mijn afbeeldingen, wordt er in mijn HTML gelinkt naar de CDN URL’s van de afbeeldingen:

CDN afbeeldinglink in HTML broncode
CDN afbeeldinglink in HTML broncode

De oplossing is de oorspronkelijk URL aan te passen naar de CDN URL via de wpseo_xml_sitemap_img_src filter, te vinden in WordPress SEO API docs.

Onderstaande code, ontleent aan de CDN Images in Sitemap hulpvraag op WordPress.org, moet je plaatsen in het functions.php van je WordPress thema.

function wpseo_cdn_filter( $uri ) {
	return str_replace( 'http://example.com', 'http://cdn.example.com', $uri );
}
add_filter( 'wpseo_xml_sitemap_img_src', 'wpseo_cdn_filter' );

Onjuist gebruik van pre & code element en white-space CSS

In mijn eerdere artikel Code Snippets en Syntax Highlighting in WordPress met correcte HTML heb ik al uitgebreid aandacht besteedt hoe je blokken met code (of normale tekst) exact kunt weergeven op je website zoals je het ook in je code editor gestructureerd hebt, dit met behulp van het pre element.

Alles binnen het pre element wordt namelijk exact weergegeven, inclusief witregels, tabs en spaties die je veelvuldig gebruikt in code snippets. De code is immers niet goed leesbaar als alles achter elkaar staat.

Het pre element is niet specifiek voor code, maar kan bijvoorbeeld ook gebruikt worden voor een gedicht waarbij de witregels, tabs en spaties belangrijk zijn om aan de websitebezoeker te tonen.

Als je niet weet dat het pre element bestaat, dan gaan er gegarandeerd zaken mis. Zo ook bij de ontwikkelaars van de Toolset Bootstrap theme. Dit is een thema waar alle CSS van Twitter Bootstrap 2.3.2 wordt gebruikt, dit gecombineerd met de onwetendheid over het pre en code element hebben de ontwikkelaars er toe gebracht eigen CSS toe te voegen aan hun thema dat alleen maar voor meer problemen zorgde in plaats van oplossingen!

CSS alternatief voor het pre element, white-space!

Met white-space hebben we het natuurlijk over de witruimte, en zoals inmiddels duidelijk kan het belangrijk zijn om dit aan de bezoeker van je website te tonen, bijvoorbeeld bij een blok met code of bij een tekst zoals een gedicht. Het gebruik van het pre element is hiermee afdoende, en veel meer dan dit hebben we eigenlijk niet nodig.

Ondanks dat veel code plaatsen achter elkaar in een code element de code compleet onleesbaar maakt, en je daarvoor dus het pre elementen moet gebruiken, heeft Toolset toch getest wat er dan gebeurd. Toolset kwam erachter dat de CSS van Twitter Bootstrap 2.3.2 hier zorgt voor een probleem, zichtbaar op onderstaande afbeelding.

White-space no-wrap probleem code element
De white-space no-wrap value uit de CSS van Twitter Bootstrap 2.3.2 zorgt voor een probleem bij veel tekst in het code element

Het klopt dat de CSS van Twitter Bootstrap 2.3.2 hiervan de oorzaak is. Normaliter zou dit nooit gebeuren bij het code element. Als je veel tekst plaats in het code element loopt dit normaliter door op de volgende regel: het is namelijk een inline element! Onderstaande afbeelding toont dus het gebruikelijk gedrag van het code element.

Code inline element
Het code element is een inline element en dus gaat tekst gewoon verder op een volgende regel

Hoe kan het dat dit niet meer werkt bij Twitter Bootstrap 2.3.2? Dit is omdat ze in hun CSS gebruik maken van white-space: nowrap (lees meer over de werking van nowrap). De reden dat Twitter Bootstrap 2.3.2 de inline werking van het code element teniet doet is simpel. Zij hebben het code element voorzien van een background en een border. Als het stukje code dan aan het einde van de zin afgebroken wordt, ziet het er simpelweg niet meer uit:

Disable inline behaviour code element
Inline behaviour van het code element zorgt met Twitter Bootstrap 2.3.2 CSS voor een niet zo’n fraai aangezicht

Door de CSS white-space: nowrap toe te voegen, staat het stukje code in zijn geheel op één regel:

Code element white-space no-wrap

Bijgevolg van dit is dat als er grote lappen code in het code element gestopt worden, zoals Toolset Bootstrap getest heeft, dit voor een probleem zorgt omdat alles geforceerd op één lijn blijft en dus buiten de kaders van je pagina terecht kan komen. Dat is natuurlijk niet erg galant, maar zolang je het code element ook daadwerkelijk gebruikt voor kleine stukjes code in je tekst, en het pre element voor grote blokken met code, zal het probleem zich echter ook niet voordoen. De CSS van Twitter Bootstrap 2.3.2 zal dus niet snel voor problemen zorgen bij een juiste toepassing van het code en pre element.

Omdat dit besef nog niet bij Toolset aanwezig was, gingen ze het (niet bestaande) probleem oplossen, zodat de white-space: no-wrap CSS van Twitter Bootstrap 2.3.2 weer ongedaan gemaakt werd:

/* Fix for code line breaks */
code {
white-space: pre !important;           /* CSS 2.0 */
white-space: pre-wrap !important;      /* CSS 2.1 */
white-space: pre-line !important;      /* CSS 3.0 */
white-space: -pre-wrap !important;     /* Opera 4-6 */
white-space: -o-pre-wrap !important;   /* Opera 7 */
white-space: -moz-pre-wrap !important; /* Mozilla */
white-space: -hp-pre-wrap !important;  /* HP Printers */
word-wrap: break-word !important;      /* IE 5+ */
}

Deze fix ging totaal niet samen met goed gebruik van het pre element en zorgde alleen maar voor meer problemen. Wat betreft het code element stond alles wel weer binnen de kaders van de pagina, maar door de background en border zit dat er dus niet uit! Dit is exact waarom Twitter Bootstrap 2.3.2 juist de white-space: nowrap had toegevoegd.

pre-code

In het forumtopic CSS needs improvement heb ik dit voorgelegd en is hun CSS fix op mijn aanraden ook verwijderd uit Toolset Bootstrap versie 1.1 :-).

Natuurlijk hebben ze een punt dat als mensen tóch veel code plakken in het code element ze willen voorkomen dat deze helemaal lang word en buiten de kaders van de pagina komt. Daarom hebben ze een nieuwe fix toegevoegd:

/* Fix for code line breaks */
.entry-content code {
max-width: 100%;
}

Dit werkt als evenmin zoals je hier ziet:

[afbeelding nog toevoegen]

https://wp-types.com/forums/topic/code-line-breaks-fix-not-working/

Ik vraag me sowieso af of het verstandig CSS toe te passen op een class die aanwezig is vanwege hAtom microformat.

Meer informatie white-space:

http://css-tricks.com/almanac/properties/w/whitespace/

http://code.stephenmorley.org/html-and-css/white-space-handling/

Demografische en interesserapporten en WordPress (Analytics.js)

Het zal velen die Google Analytics gebruiken niet ontgaan zijn dat ‘Universal Analytics’ de nieuwe standaard is geworden. Maakte de tracking code van Google Analytics voorheen gebruik van ga.js, in de nieuwe standaard is dit analytics.js. De upgrade bestaat simpelweg uit de nieuwe Google Analytics tracking code in WordPress implementeren.

Waarom upgraden naar Analytics.js?

Ik quote:

Wanneer u de upgrade uitvoert, blijft u toegang houden tot uw historische gegevens in dezelfde rapporten die u momenteel gebruikt, maar beschikt u ook over het volgende:

  • Aangepaste dimensies en statistieken
  • Nieuwe trackingcode
  • Meer rapportagefuncties

Universal Analytics moet binnenkort worden gebruikt voor alle Google Analytics-property’s. Property’s die niet worden overgezet, worden in de toekomst automatisch overgezet naar Universal Analytics.

Zie ook hier de voordelen van upgraden naar Universal Analytics. Op die pagina vind je ook een tijdlijn, en dit maakt duidelijk dat ze nu ook bezig zijn met het automatisch omzetten van ga.js naar analytics.js, mocht je de upgrade zelf nog niet uitgevoerd hebben.

Dat voordelen beloven veel goeds… dacht ik! Ik kwam er echter achter dat de Demografische en interesserapporten in Google Analytics niet werkten met deze nieuwe trackingscode, zie mijn bericht van 15 februari 2014.

Het moge duidelijk zijn, ik was me ervan bewust dat om de Demografische en interesse rapporten in te schakelen, ik eenmalig een wijziging in de tracking code moest aanbrengen. De documentatie ging echter nog steeds uit van het oude tracking systeem via ga.js, en daarmee was het dus onmogelijk om dit in orde te maken voor mijn website die reeds de upgrade had gedaan naar analytics.js.

Nu is het echter wel ondersteund, en ik leg je hieronder stap voor stap uit hoe je de Demografische en interesserapporten kunt inschakelen.

Allereerst klik je op de blauw button ‘Inschakelen’.

Google Analytics Demografische en interesserapporten inschakelen
Google Analytics Demografische en interesserapporten inschakelen

Vervolgens krijg je de melding dat je eenmalig de tracking code moet aanpassen, je moet namelijk ‘display-advertenties’ gaan ondersteunen. Dit klinkt misschien raar, maar de rapporten zijn dezelfde demografische en interessecategorieën waarmee advertenties worden getarget in het Google Display Netwerk! Binnen Analytics kun je deze informatie over uw gebruikers dus ook gebruiken om de strategieën voor advertentiecampagnes te verfijnen. De inmiddels up-to-date documentatie vind je in het artikel Uw Google Analytics-trackingcode bijwerken om display-advertenties te ondersteunen.

Nadat je de wijziging van code hebt geïmplementeerd op je website, kun je de tracking code valideren door op de blauwe button ‘Trackingcode valideren’ te klikken. Heb je een WordPress website, lees dan snel verder, want dan hoef je de code niet zelf te wijzigen.

Google Analytics trackingcode valideren
Google Analytics trackingcode valideren

Demografische en interesserapporten activeren in WordPress

Heb je eenmaal de demografische en interesserapporten ingeschakeld in Google Analytics, dan hoef je de vereiste wijziging in de tracking code niet zelf door te voeren als je gebruik maakt van de Google Analytics by Yoast plugin. Deze plugin zet de tracking code automatisch in je website zonder dat je zelf aan de slag moet met het header.php of functions.php bestand in WordPress.

Om de wijziging in de tracking code door te voeren is het simpelweg een instelling veranderen in de plugin, die is toegevoegd per 4 september 2014 in versie 5.0.0 van de plugin, zie de changelog.

5.0.0

Release Date: September 4th, 2014

Complete rewrite of the Google Analytics plugin.

Enhancements:
Universal tracking added
Better link tracking
New Universal demographics feature
New menu items in the WordPress admin menu

Zoals op onderstaande afbeeldingen is te zien, hoe je alleen maar naar het juiste tabblad te navigeren en daar twee vinkjes aan te zetten.

Google Analytics by Yoast Demografische en interesserapporten
Universal tracking en Demografische en interesserapporten inschakelen via Google Analytics by Yoast plugin.

Of lees het artikel Enable Demographics and Interest reports in Google Analytics.

YouTube e.a. video embeds in WordPress

Als je een YouTube of video van een ander videoplatform wilt invoegen (embedden) in je WordPress website, dan gaat dit artikel je zeker helpen.

Embed (YouTube) video in WordPress

Het invoegen van een (YouTube) video in WordPress is erg eenvoudig. Je kunt gewoon de video-url kopiëren en plakken in de WordPress editor van je pagina of post die je aan het bewerken bent. Je moet er alleen op letten dat de link op een eigen regel staat, zoals hier:

Dit is een coole YouTube video: 

[De (YouTube) video-url hier plakken, op een eigen regel!]

Cool toch?

WordPress zet de link vervolgens om in de juiste HTML voor het betreffende videoplatform waar je een video van wilt invoegen (YouTube, Vimeo etcetera). Dit is mogelijk omdat WordPress gebruikt maakt van oEmbed:

The easy embedding feature is mostly powered by oEmbed, a protocol for site A (such as your blog) to ask site B (such as YouTube) for the HTML needed to embed content from site B.

Alle videoplatformen die ondersteund worden en meer informatie over deze functionaliteit van WordPress vind je in het WordPress Codex artikel Embeds.

Veel voorkomende problemen met video’s in WordPress

Zoals we hierboven hebben uitgelegd is het erg eenvoudig om een YouTube (of andere) video toe te voegen in WordPress. Dan is het tijd om het resultaat te bekijken op je website. Bij mij zag dit er als volgt uit:

YouTube WordPress video te groot
Op deze pagina is de YouTube video in WordPress te groot, de breedte van de pagina (zie tekst onder de video) is kleiner dan de video zelf.
WordPress YouTube video te klein
De YouTube video in WordPress is te klein ten opzichte van de breedte van de pagina (kijk maar naar de tekst!).

Wat zien we nou op bovenstaande afbeeldingen?

De YouTube video die we zojuist hebben ingevoegd passen zich duidelijk niet aan naar de breedte van de pagina is waar ze worden ingevoegd. Zoals we weten uit voorgaande uitleg zet oEmbed onze YouTube link die we in de WordPress editor geplakt hebben om in de juiste HTML op de website. Als we daar naar kijken zien we het volgende:

<iframe src="http://www.youtube.com/embed/ZR8oXE9feDk?feature=oembed&amp;wmode=opaque" width="770" height="433" frameborder="0" allowfullscreen="allowfullscreen"></iframe>

Uit de code blijkt dus dat de video altijd een fixed width heeft van 770 pixels. Dat gaat niet werken! Op mijn pagina van 940 pixels breed (zonder sidebar) is de YouTube video te klein, en op mijn pagina van 620 pixels (met sidebar) breed is de YouTube video te klein zoals we reeds zagen op mijn afbeeldingen.

Het blijkt echter dat de oEmbed functionaliteit wel prima rekening houden met hoe breed een pagina is om de (YouTube) video vervolgens dus “full width” in te kunnen voegen. Je thema moet dan deze “content width” wel gespecificeerd hebben in de code van het WordPress thema, dit wordt uitgelegd in het artikel How to Set oEmbed Max Width in WordPress 3.5 with $content_width. Met de code die in dit artikel aangedragen wordt kun je echter maar één breedte aangeven in pixels. Dit is voor mij geen oplossing omdat mijn “content width” voor de pagina zonder sidebar 940 pixels is, en voor de pagina’s met sidebar 620 pixels. Ik moet dus een oplossing hebben waarbij de video’s altijd 100% de breedte hebben van de pagina.

Responsive (YouTube) video plugin

Gelukkig ben ik niet de enige die YouTube video’s wil invoegen die zich automatisch aanpassen naar de breedte van de pagina. Dit kan belangrijk zijn als je, zoals in mijn geval, pagina’s hebt met verschillende breedtes. En ook bij responsive of fluid websites zijn de paginabreedtes continue anders. De oplossing is de Advanced Responsive Video Embedder plugin. Door toepassing van slimme CSS en Javascript zorgt deze plugin ervoor dat de video’s altijd op volledige breedte van desbetreffende pagina wordt weergegeven. Natuurlijk zijn er ook nog andere alternatieven die je bijvoorbeeld in het lijstje 16 Cool Responsive WordPress Plugins for Images and Videos kunt vinden.

Google+ pagina koppelen aan je WordPress website

Onlangs, bij het nalopen van de mogelijkheden in de WordPress SEO plugin, kwam ik via ‘social’ terecht bij onderstaande optie (rood gemarkeerd).

Google bedrijfspagina koppelen via WordPress SEO plugin
Google bedrijfspagina koppelen via WordPress SEO plugin

De plugin biedt mij de mogelijkheid, als ik een Google+ pagina heb, deze in te vullen. De vraag is echter, waarom zou ik dit willen doen?

Waarom een Google+ pagina koppelen aan je website?

Het antwoord verwacht ik vervolgens te vinden in het artikel WordPress SEO, The Definitive Guide To Higher Rankings For WordPress Sites op de website van Joost, maar helaas kon ik er niets over vinden. Na een korte e-mailwisseling met de supportafdeling van Yoast, is het gelukkig toch snel duidelijk geworden.

Willem-Siebe Spoelstra: Ik wil even het volgende aangeven. In de WordPress SEO plugin staat onder social het Google+ tabblad, daar staat vervolgens dit: Als je een Google+ pagina voor je bedrijf hebt, vul dan hier de URL in en link het op je Google+ Over Mij pagina. Ik kan echter nergens documentatie vinden wat dit doen en waarom ik dit moet doen.

Taco Verdonschot: Google+ biedt de mogelijkheid voor bedrijven om een Google+ bedrijfspagina aan te maken. Zo’n pagina heeft een eigen link die te vinden is op de ‘Over mij’-pagina van uw Google+ bedrijfspagina. Deze link kunt u vervolgens invullen in de plugin.

Willem-Siebe Spoelstra: Bedankt voor je reactie, maar ik ben er niet mee geholpen. Het punt is juist het gebrek aan documentatie waarom ik deze link in moet vullen. Wat gebeurd er als ik deze link invul en welk SEO voordeel heeft dit. Nergens in de plugin of op de website van Yoast (The definitive Guide) lees ik hier iets over. Wellicht dat ik er zo over heen lees hoor, maar ook dan hoor ik dat natuurlijk graag.

Taco Verdonschot: Je hoeft hem niet in te vullen hoor :) Het betreft hier publisher highlighting, https://support.google.com/webmasters/answer/1708844?hl=en. Naast dat je Google meer vertelt over je bedrijf als je je Google+ bedrijfspagina hebt ingevuld en gelinkt aan je website, is er de mogelijkheid dat Google je bedrijf uitlicht zoals gedaan met het blokje van Philips aan de rechterkant hier https://www.google.com/search?q=philips. De waarde voor SEO is dus:
Google kan zijn zoekresultaten beter afstemmen op de zoeker als ze meer info over je bedrijf hebben en je kunt uitgelicht worden en valt dan natuurlijk veel meer op in de zoekresultaten. Ik hoop dat dat je vraag beantwoord.

De Google+ koppeling achter de schermen

Wat gebeurt er nou exact als je deze link invult in de WordPress SEO plugin? Het doet niets meer en minder dan een stukje code toevoegen in het head gedeelte van je website.

Publisher link element in head gedeelte website
Publisher link element in head gedeelte website

Maar wat valt mij op als Google mij vraagt om deze koppeling te maken, een ander stukje code! Zie onderstaande afbeelding.

Je website koppelen aan je Google+ pagina
Je website koppelen aan je Google+ pagina

Ook via de pagina Google+ Pages waar de supportafdeling van Joost eerder naar refereerde, lees ik niets over de methode die gebruikt word in de WordPress SEO plugin. Pas na lang zoeken kwam ik eindelijk op een developers pagina van Google over de Google+ badge de gekozen methode tegen, zie onderstaande afbeelding.

Methode koppeling WordPress SEO op Google
Methode koppeling WordPress SEO op Google

Heeft de ene methode voorkeur boven de andere? Nee. Zie mijn forumtopic Connect website to Google+ page. Kun je controleren of de koppeling werkt? Ja! Ga naar de Tool voor gestructureerde gegevenstests, vul je URL in en controleer of je onderstaande opmerking ziet.

Google+ koppeling geverifieerd door Google Rich Snippet tool
Google+ koppeling geverifieerd door Google Rich Snippet tool

Gebruik géén nofollow links op je eigen website!

De rode lijn in alle video’s van Matt Cutts over het gebruik van nofollow links op je eigen website, is om dat niet te doen! In onderstaande video’s komen alle voorbeelden wel aan bod zoals:

  • links naar je login pagina;
  • links naar je winkelwagen pagina;
  • links naar je privacybeleid;
  • links naar je algemene voorwaarden.

Video van 01-05-2009:

Video van 29-06-2010:

Video van 22-04-2011:

Video van 30-09-2013:

Verschil tussen inline en inline-block!

Wel eens afgevraagd wat het verschil is tussen display:inline, display:block en display:inline-block?

In woorden, inline vs block vs inline-block

Gevonden via Google: CSS display: inline vs inline-block.

Inline elements:

  • respect left & right margins and padding, but not top & bottom;
  • cannot have a width and height set;
  • allow other elements to sit to their left and right.

Block elements:

  • respect all of those;
  • force a line break after the block element.

Inline-block elements:

  • allow other elements to sit to their left and right
  • respect top & bottom margins and padding
  • respect height and width

Visueel, inline vs block vs inline-block

Gevonden via Google: What is the difference between display: inline and display: inline-block?.

Imagine a element inside a

. If you give the element a height of 100px and a red border for example, it will look like this with…

Inline elements:

display:inline
display:inline

Block elements:

display:block
display:block

Inline-block elements:

display:inline-block
display:inline-block