YouTube e.a. video embeds in WordPress

WordPress YouTube video te klein

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!

display: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 <span> element inside a <div>. If you give the <span> 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

Verborgen tekst en links, niet slecht voor SEO!

Lees meer link niet erg voor SEO

Het verbergen van tekst en links is een veelgebruikte manier van vroeger om de zoekresultaten in Google te manipuleren. Simpelgezegd, in de broncode van de website is allerlei tekst (keyword stuffing) en/of links aanwezig die je niet toont aan de normale bezoeker! Voorbeelden: BMW (2006), Alex Chiu (2007).

Echter, er zijn natuurlijk ook veel situaties denkbaar waarbij het verbergen van tekst en/of links een functie heeft. De tekst en/of links worden op enig moment zichtbaar, vaak na een actie van de websitebezoeker (mouse-over, mouse-click). Geen kwade bedoeligen dus! Denk bijvoorbeeld aan:

  • dynamische navigatie;
  • lees meer, lees minder link/button;
  • diverse tabs, veelgebruikt in ecommerce websites.

Maar je wilt natuurlijk wel dat Google dit allemaal gewoon netjes crawlt en indexeert! Met het misbruik van verborgen tekst en links nog in ons achterhoofd, is het natuurlijk interessant om te weten hoe Google hier mee om gaat.

Verborgen tekst en links, manipulatie versus legitiem…

Google geeft in het artikel Verborgen tekst en links een aantal voorbeelden. Belangrijker is echter dat Google aangeeft dat niet alle verborgen tekst als misleidend wordt beschouwd. Het punt dat gemaakt wordt is dat je site simpelweg geen tekst en/of links mag bevatten die alleen voor de zoekmachine zijn bedoeld (manipulatie) en dus nooit zichtbaar zal zijn voor de bezoeker. Onderstaande mag dus niet.

Tekst (zoals overmatig veel zoekwoorden) kan op verschillende manieren worden verborgen, zoals:

  • Witte tekst gebruiken op een witte achtergrond
  • Tekst achter een afbeelding plaatsen
  • CSS gebruiken om tekst buiten het scherm te plaatsen
  • De tekengrootte instellen op 0
  • Het verbergen van een link door een link in te stellen via een klein teken, zoals een streepje in het midden van een alinea

In onze eerder genoemde voorbeelden is er geen sprake van dat we de zoekresultaten willen manipuleren, en Google zal deze verborgen tekst dus gewoon crawlen en indexeren. Ben je daarvan nog niet overtuigd? Lees dan eens Eric Enge Interviews Google’s Matt Cutts. Daar geeft Matt Cutts aan dat met gebruikelijke webdevelopement technieken, zoals dynamische navigatie, geen problemen hebben.

Eric Enge: Right. Are there hidden text scenarios that are harder for you to discern whether or not they are spam versus something like showing just part of a site’s terms and conditions on display, or dynamic menu structures? Are there any scenarios where it’s really hard for you tell whether it is spam or not?

Matt Cutts: I think Google handles the vast majority of idioms like dynamic menus and things like that very well. In almost all of these cases you can construct interesting examples of hidden text. Hidden text, like many techniques, is on a spectrum. The vast majority of the time, you can look and you can instantly tell that it is malicious, or it’s a huge amount of text, or it’s not designed for the user. Typically we focus our efforts on the most important things that we consider to be a high priority. The keyword stuffed pages with a lot of hidden text, we definitely give more attention.

Andere voorbeelden waarbij de hoeveel tekst niet past in het design van de website zijn de ‘lees meer’ links of de tabs. Een voorbeeld van de lees meer link met verborgen tekst zie je op onderstaande afbeelding.

Lees meer link niet erg voor SEO

Lees meer link niet erg voor SEO

Ook hier zijn gerustellende woorden van Matt Cuts te vinden op het World Wide Web, en wel in de vorm van een video.

Techniek voor het verbergen van tekst (toggling content)

Zelf maak ik momenteel gebruik van Twitter Bootstrap 2.3.2, en interessant om te zien is dat zij reeds twee classes beschikbaar stellen voor het tonen en verbergen van tekst, namelijk .hide en .show. Zie het bestand utilities.less.

// Toggling content
.hide {
  display: none;
}
.show {
  display: block;
}

In beginsel is het de juiste manier om via CSS met display: none; de tekst tijdelijk te verbergen. Hiermee verberg je de tekst visueel, voor de normale webbrowser gebruikers. Je verbergt de tekst hiermee ook voor mensen die gebruik maken van AT (afkorting voor Assistive Technology of Adaptive Technology), zoals screenreaders. Ook slechtziende of blinde mensen met een screenreader zullen dus pas de extra tekst lezen als zij op de ‘lees meer’ link geklikt hebben. Zo hebben alle gebruikers dus een zelfde ervaring.

Vanaf Twitter Bootstrap 3.0.1 is .hide vervangen door .hidden.

// Hide from screenreaders and browsers
//
// Credit: HTML5 Boilerplate

.hidden {
  display: none !important;
  visibility: hidden !important;
}

In het artikel How to: Hide Content wordt uitgelegd dat de toevoeging van visibility: hidden noodzakelijk is omdat sommige screenreaders display: none negeren.

Om de tijdelijk verborgen tekst zichtbaar te maken wordt via Twitter Bootstrap gebruik gemaakt van display: block. Ook dit is de juiste methode, maar schijnt volgens Yahoo in het artikel Accessible Solutions For Hiding Content niet voldoende gebruiksvriendelijk te zijn voor de screenreader gebruikers, zie onderstaande quote.

Now that you know how to use display:none to completely hide your panels. You need to do more than convert their display to block for accessibility.

Ian Pouncey’s article on the accessibility built into into the tabbed modules on the Yahoo! Home Page, Accessible Tabs in the new Yahoo Homepage –recreated with YUI3 and WAI-ARIA, shows you how to use YUI3 to handle the different events that hide/display the correct content, as well as allow screen readers to know how the page has changed.

Hebben we toch nog iets om te bestuderen voor een volgend artikel!

Factureren voor de webwinkelier

Een factuur versturen. Elke webwinkelier kan hier mee te maken krijgen. Maar wanneer ben je nou verplicht om een factuur te sturen, en aan welke eisen moet deze voldoen? Wanneer verstuur je de factuur? Bij de orderbevestiging, of pas achteraf? Allemaal relevante vragen die ik graag beantwoord zie. Op ontdekkingstocht dus.

Wie zijn verplicht te factureren?

De belastingdienst legt het gelukkig uit op de pagina ‘Wie zijn verplicht te factureren‘.

U maakt een factuur op voor alle goederen en diensten die u levert aan andere ondernemers. Ook rechtspersonen die geen ondernemer zijn (ook buitenlandse), stuurt u een factuur. Dit kunnen bijvoorbeeld zijn: verenigingen en stichtingen.

Verkoopt u goederen of diensten aan particulieren? Dan bent u niet verplicht een factuur uit te reiken…

Lever je als webwinkel dus aan ondernemers en/of rechtspersonen, dan zul je moeten factureren. Lever je alleen goederen aan particulieren, dan hoeft dit niet. Neem wel even notie van de uitzonderingen op de eerder benoemde pagina van de belastingdienst!

Factuureisen

Ook dit heeft de belastingdienst keurig uitgelegd, zie de pagina ‘Factuureisen‘.

  • uw volledige naam en die van uw afnemer
    U vermeldt de juridische naam. De handelsnaam mag ook, als die in combinatie met het adres en woonplaats bij de Kamer van Koophandel is geregistreerd. Bij fiscale eenheden is het gebruikelijk dat de naam van het onderdeel dat de prestatie levert op de factuur staat.
  • uw volledige adres en dat van uw afnemer
    U vermeldt het adres waar de onderneming feitelijk is gevestigd. Vermelding van alleen een postbusnummer is niet voldoende.
  • uw btw-nummer
    Bij fiscale eenheden is dat het btw-nummer van het onderdeel dat de prestatie levert.
  • uw KvK-nummer
  • de datum waarop de factuur is uitgereikt
  • een uniek volgnummer
  • een omschrijving van de goederen of diensten die u hebt geleverd
  • het aantal geleverde goederen of diensten
  • de datum waarop de goederen of diensten zijn geleverd, of de datum van een vooruitbetaling
  • het bedrag dat u in rekening brengt, exclusief btw
    Levert u prestaties met verschillende btw-tarieven? Vermeld dan de aparte bedragen. Neem daarnaast de eenheidsprijs op, als dit van toepassing is.
  • het btw-tarief dat u in rekening brengt
  • het btw-bedrag

Deze spreken allemaal aardig voor zich, behalve onderstaande.

de datum waarop de goederen of diensten zijn geleverd, of de datum van een vooruitbetaling

Het is niet ongewoon dat een webwinkelier, ongeacht de betaalwijze, pas een order verstuurd zodra de betaling binnen is. Uiteindelijk kwam ik dus tot de conclusie dat we in die situatie altijd met een (volledige) vooruitbetaling te maken hebben. Als een klant echter kiest voor de betaalwijze per bankoverschrijving, dan is de datum van vooruitbetaling uiteraard nog onbekend. Dit zou dus ook inhouden dat het niet mogelijk is als webwinkel de factuur reeds bij de orderbevestiging mee te sturen. Dat blijkt (gelukkig) niet juist te zijn.

Het antwoord krijg ik op een thread die ik gestart ben op Higherlevel: ‘Wanneer (welk moment) factureren in geval van webwinkel?‘.

Soms is het handig om gewoon even op de wettekst terug te vallen:

34g. De factuur wordt uitgereikt uiterlijk op de vijftiende dag van de maand volgende op die waarin de goederenlevering of de dienst is verricht. In geval van vooruitbetalingen als bedoeld in artikel 34c, eerste lidartikel 34c, eerste lid, onderdelen d en e, moet de factuur telkens worden uitgereikt vóór het tijdstip van de opeisbaarheid daarvan.

Artikel 35a
1 Op de factuur zijn de volgende vermeldingen verplicht:
a. de datum van uitreiking van de factuur;
(…)
g. de datum waarop de goederenlevering of de dienst heeft plaatsgevonden of voltooid is of de datum waarop de in artikel 34c, eerste lidartikel 34c, eerste lid, onderdelen d en e, bedoelde vooruitbetaling is gedaan, voor zover die datum vastgesteld is en verschilt van de uitreikingsdatum van de factuur; (…)

De wet bepaalt geen vaste uitreikingsdatum, slechts een uiterste datum. Eerder mag dus ook, maar het kan wel de verschuldigdheid van de btw (en het moment van teruggaaf voor de afnemer) beïnvloeden. Het gaat hier om een vooruitbetaling, waarbij de datum nog niet is vastgesteld danwel niet verschilt van de uitreikingsdatum van de factuur, dus hoeft die datum niet te worden vermeld.

En ook WikiPedia geeft in hun artikel over de factuur aan:

De factuur kan verzonden worden voorafgaand of na de feitelijke levering. Is het eerste het geval dan spreekt men van voorfactureren, in het tweede geval van nafactureren.

Er kan bij vooruitbetalingen echter ook gekozen worden een pro-forma factuur volgens WikiPedia:

De pro-formafactuur wordt vaak, voordat een en ander geleverd wordt, gebruikt bij vooruitbetalingen, waarna de afrekening gebeurt middels de factuur.

Digitaal factureren

We hadden het reeds over het meesturen van de factuur bij de orderbevestiging. Dit is echter om een andere reden niet vanzelfsprekend. De afnemer moet namelijk akkoord gaan met de digitale factuur. Dit kan op meerdere manieren. Vooraf overleggen is een mogelijkheid. Ook kun je gewoon de factuur versturen, en bij betaling kun je er vervolgens vanuit gaan dat de klant akkoord is met het ontvangen van digitale facturen.

Ondernemer in Business adviseert het op te nemen in de algemene voorwaarden, waar de winkelende klant mee akkoord gaat alvorens de order te plaatsen. Zie het artikel ‘Elektronische factuur: voordelen en voorwaarden‘.

Benoem digitalisering in algemene voorwaarden: Nog voordat de factuur de deur uit is gegaan, moet de klant akkoord zijn gegaan met de algemene voorwaarden. Wanneer je besluit (enkel) digitaal te factureren, moet je dat in de voorwaarden opnemen zodat de klant hier vooraf kennis van kan nemen.

Automatisch facturen in je WordPress/WooCommerce webwinkel

Ben je het zat om voor elke bestelling zelf een factuur op te maken, en maak je gebruik van de WordPress plugin WooCommerce om je webwinkel draaiende te houden? Dan kan ik je gratis plugin WooCommerce PDF Invoices & Packing Slips van het WP Overnight team van harte aanbevelen. Naast het feit dat je in staat bent om je eigen templates te maken voor de facturen kun je op hun website als aanvulling op de gratis plugin ook nog Premium templates vinden.

You do not have sufficient permissions to access this page

Nadat ik een plugin van WooThemes had geïnstalleerd kon ik niet van start gaan met de geplande werkzaamheden. Ik werd namelijk geconfronteerd met onderstaande melding toen ik de plugin settings page wilde bezoeken.

You do not have sufficient permissions to access this page.

De WooThemes helpdesk hebben mij fantastisch geholpen, en ik deel hier graag de mogelijke oplossingen van het probleem.

De eerste oplossing die bij mij niet geholpen heeft:

This behavior is caused by a bug in the WordPress core that can also affect other plugins. Changing the authorization keys from their default value is the safest way to avoid potential problems. Please first change the four authorization keys on your wp-config.php to something else. You can use the following link to create a set of four random keys ready to be pasted into your wp-config.php: https://api.wordpress.org/secret-key/1.1/salt/. Changing these keys will cause all logged in users to be logged out, forcing them to log in again the next time they access your blog. Other than that, there are no ill effect.

Het probleem bleek toen ook wel iets groter te zijn en niet aan de plugin te liggen. Ik had namelijk ook geen toegang meer tot de berichten in WordPress.

I can see that WordPress’ built-in WordPress Dashboard, Posts, Posts screen is unavailable also. It should also be available by visiting this URL: http://[domeinnaam].nl/wp-admin/edit.php. I have deactivated all plugins, and the WordPress Dashboard, Posts, Posts screen still doesn’t show. Do you have any custom code in your theme (or another file) that is customising the permissions of WordPress’ built-in posts? The [plugin-name] screen uses the same permissions as the “posts” screen, so until the user has permissions to access normal posts, they won’t be able to access the [plugin-name] screen. This problem isn’t being caused by the [plugin-name] plugin, so you’ll need to identify what is causing WordPress’ built-in “Post” screen from not being available.

Gelukkig stond ik er niet alleen voor, want de support van WooThemes bleef zoeken naar het probleem. En onderstaande was in mijn geval de simpele oplossing.

I just went to http://[domeinnaam].nl/wp-admin/users.php, and changed the “[username]” role to Administrator. This reset the permissions on that user account, and it is now able to access WordPress’ posts feature. This also means that it is now able to access the [plugin-name] section. One of your other plugins must have somehow broken the user permissions for your user account.

Git op Windows installeren

Bijna iedere webdeveloper weet inmiddels van het bestaan van Git. Ermee werken is een ander verhaal. Gelukkig is er het boek Pro Git dat gratis te downloaden is vanaf de Git website. Dit boek is ook in het Nederlands beschikbaar. Stap 1 om met Git aan de slag te gaan is om Git op je computer te installeren.

Voor Windows is er een installatieprogramma beschikbaar, Git for Windows. Volgens het eerder genoemde boek is installeren heel makkelijk.

Je hoeft alleen maar het installatieprogramma te downloaden van GitHub, en het uit te voeren

Tijdens de installatie wordt je echter met een aantal keuzes geconfronteerd waar je geen verstand van hebt, en wat bovendien niet in het boek wordt uitgelegd. Uiteindelijk heb ik ervoor gekozen de stappen en keuzes te volgen van een BeanStalk artikel, zie Installing Git of onderstaande afbeelding.

Git op Windows installeren

Git op Windows installeren

Mocht iemand nog op- of aanmerkingen hebben op bovenstaanden, dan hoor ik dat uiteraard graag!

Over crawlen, indexeren en robots.txt voor WordPress

Crawlen is de activiteit van Google en andere zoekmachines waarbij ze openbaar beschikbare pagina’s ontdekken. Hiervoor worden softwareprogramma’s gebruikt die we ‘webcrawlers’ noemen. De webcrawlers volgen dezelfde links waar jij op klikt tijdens het surfen op websites. Zo worden nieuwe pagina’s ontdekt. De software besteedt extra aandacht aan nieuwe sites, wijzigingen in bestaande sites en dode links.

Al deze pagina’s worden door Google georganiseerd in een grote index. Dit noemen we indexeren. De pagina’s in de index kunnen als zoekresultaat getoond worden aan bezoekers van Google of andere zoekmachines.

Meer informatie:

Crawlen en indexeren, Google Inside Search
Robots.txt Specifications, Google Developers
Robots meta tag and X-Robots-Tag HTTP header specifications

Crawler richtlijnen

Via een robots.txt bestand kun je richtlijnen doorgeven hoe bots van Google en andere zoekmachines je website moeten crawlen. Door het gebruik van ‘Disallow:’ kun je webcrawlers vertellen welke onderdelen van de website ze niet mogen crawlen. Het robots.txt protocol is ontstaan in 1994. Webcrawlers houden rekening met dit bestand, maar slechts tot op zekere hoogte. Je zou wellicht denken dat het uitsluiten van bepaalde pagina’s en bestanden in robots.txt voldoende is om (een deel) van een website uit de index van Google te houden. Dat is echter niet het geval. Als je een pagina of bestand uitsluit voor de webcrawlers in robots.txt, maar de URL nog steeds gevonden wordt op andere websites, kunnen zoekmachines deze externe URL nog steeds crawlen en opnemen in hun index.

Als je dus echt wilt voorkomen dat iets zichtbaar is in de zoekmachines, dan is robots.txt niet de beste oplossing. Een aantal voorbeelden waaruit blijkt dat robots.txt niet voldoende is vind je in het artikel Serious Robots.txt Misuse & High Impact Solutions. Eén voorbeeld daarvan is de website WordPress.com. Onderstaande is zichtbaar in de robots.txt van WordPress.com.

Robots.txt disallow

Er zijn echter een heleboel pagina’s die linken naar de URL http://wordpress.com/next/. Het gebruik van disallow in het robots.txt bestand is dan ook niet voldoende gebleken om dit resultaat uit Google te mijden, zie hieronder.

Geen meta beschrijving door robots.txt

De titel en de URL zijn gewoon zichtbaar in Google. Alleen de beschrijving laat Google nog achterwege vanwege de richtlijnen in het robots.txt bestand.

Google legt heel goed uit wat je moet doen om er zeker van te zijn dat een resultaat uit de zoekresultaten blijft, zie de uitleg Metatags gebruiken om de toegang tot uw site te blokkeren.

Als u er zeker van wilt zijn dat de inhoud van een pagina niet aan de index van Google wordt toegevoegd, zelfs wanneer andere pagina’s ernaar verwijzen, gebruikt u de noindex-metatag. Zolang de Googlebot de pagina ophaalt, zal deze de noindex-metatag herkennen en voorkomen dat de pagina wordt weergegeven in de webindex.

En dat is meteen het bruggetje naar de Index richtlijnen, lees dus snel verder!

Index richtlijnen

De index richtlijnen bepalen écht hoe inhoud zichtbaar (of onzichtbaar) is in de zoekresultaten. Je kunt dit aan Google of andere zoekmachines kenbaar maken door gebruik te maken van een robots meta tag voor HTML pagina’s of door een X-Robots-Tag in de HTTP header. Het voordeel van de HTTP header ten opzichte van de robots meta tag is dat het ook voor andere documenten gebruikt kan worden, terwijl de robots meta tag alleen geschikt is voor HTML pagina’s.

Door het toevoegen van de ‘noindex’ richtlijn aan de robots meta tag voorkom je écht dat de pagina wordt getoont in de zoekresultaten.

<meta name="robots" content="noindex" />

Robots meta tags en X-Robots-Tag HTTP headers worden ontdekt wanneer een URL wordt gecrawled. Je mag dus nooit de webcrawler via een robots.txt bestand verbieden de URL te crawlen, omdat de ‘noindex’ informatie dan niet gevonden kan worden! In eigenlijk alle gevallen is het gebruik van ‘noindex’ dus een betere manier om URL’s uit de zoekresultaten te houden. Omdat je de webcrawler tevens niet verbiedt om de inhoud te lezen kunnen (inbound) links op die pagina’s nog steeds worden ontdekt door de webcrawler en kan autoriteit/PageRank/link juice doorgegeven worden aan die pagina’s.

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.

Zoekmachines ontmoedigen je site te indexeren via WordPress

In het korte artikel Virtueel robots.txt bestand in WordPress liet ik al zien dat WordPress de mogelijkheid biedt om zoekmachines te ontmoedigen je website te ‘indexeren’. Wat WordPress dan doet is het virtuele robots.txt bestand wijzigen naar onderstaande.

User-agent: *
Disallow: /

Dit houdt simpelweg in dat de website dus niet door Google gecrawled mag worden. We weten inmiddels echter dat dit helemaal niet voldoende is om de site uit de zoekresultaten te houden.

Een goed voorbeeld is dat veel webdevelopers gebruik maken van een staging area waar ze wijzigingen aan websites eerst uitproberen voordat ze dit toepassen op de livesite. Vaak word hier gebruik gemaakt van een subdomein zoals dev.domeinnaam.nl of staging.domeinnaam.nl. Die wil je natuurlijk niet in de zoekresultaten zien! Ik geef hieronder twee voorbeelden waarbij dat vinkje in WordPress dus zeker niet geholpen heeft!

Geindexeerd ondanks robots.txt

Geindexeerd ondanks robots.txt

Stagingsite geindexeerd ondanks robots.txt 'disallow'

Stagingsite geindexeerd ondanks robots.txt ‘disallow’

Zoals eerder uitgelegd is dit het risico van een robots.txt bestand. Dit wordt ook nog eens uitgelegd via het Google helpartikel Pagina’s blokkeren of verwijderen met een robots.txt-bestand.

Hoewel Google de inhoud van pagina’s die zijn geblokkeerd door robots.txt niet crawlt of indexeert, kunnen we de URL’s wel indexeren als we deze op andere webpagina’s tegenkomen. Hierdoor kunnen de URL van de pagina en mogelijk andere openbare informatie, zoals ankertekst in links naar de site of de titel van het Open Directory Project (www.dmoz.nl), worden weergegeven in de zoekresultaten van Google.

Nou weet ik mijn god niet hoe Google de URL’s zichtbaar in bovenstaande afbeeldingen gevonden heeft, maar Google weet alles toch ;-). Matt Cutts legt in onderstaande video uit 2009 nog eens haarfijn hetzelfde uit.

Het is interessant dat WordPress echter niet alleen de bovengenoemde robots.txt aanmaakt bij het ontmoedigen van zoekmachines om de website te indexeren, ze voegen ook de robots meta tag toe aan de HTML van alle pagina’s.

We weten echter inmiddels dat deze helemaal niet door Google ontdekt kan worden omdat de robots.txt de zoekmachine verhinderd de pagina te crawlen. Dit heeft dus helemaal geen effect. Ik snap dan ook niet waarom WordPress de robots.txt niet gewoon weglaat, dan zou altijd beter zijn! Ik ben een forumbericht gestart hierover, zie Discourage search engines bug. De oplossing is dus je eigen robots.txt te plaatsen in de root van je website waarbij je de zoekmachines dus wel toestaat om je website te crawlen.

De conclusie is dat de virtuele robots.txt van WordPress niet gewenst is. De oplossing is dat je zelf een robots.txt aanmaakt in de root van je website, waarbij je de zoekmachine gewoon toestaat om je website te crawlen, zodat deze de robots meta tag kan ontdekken en daardoor de pagina dus niet opneemt in de zoekresultaten. Met onderstaande geef je aan dat je gehele website gecrawled mag worden.

User-agent: *
Disallow:

Of zijn er toch nog situaties te bedenken om het crawlen te verbieden via een robots.txt bestand? Lees hieronder hoe je complete robots.txt er uit moet zien!

Het handmatige robots.txt bestand

Joost merkt in zijn artikel WordPress robots.txt Example terecht op dat het door WordPress geadviseerde robots.txt bestand foutief is. In dat bestand zie je een hele rits met blokkades voor de zoekmachines, waarvan het meeste verouderd is. Een paar zaken die wel actueel zijn worden uitgelicht door Joost.

There are two other sections which are blocked in the suggested robots.txt, /*?, which blocks everything with a question mark and as such all search results, and */feed/, which blocks all feeds. The first is not a good idea because if someone were to link to your search results, you wouldn’t benefit from those links.

A better solution would be to add a &lt;meta name="robots" content="noindex, follow"&gt; tag to those search results pages, as it would prevent the search results from rankings but would allow the link “juice” to flow through to the returned posts and pages. This is what my WordPress SEO plugin does as soon as you enable it. It also does this for wp-admin and login and registration pages.

Voor zover ik weet worden met de wp-admin en login pagina’s hetzelfde bedoeld, en ik zie dat WordPress nu zelf al &lt;meta name="robots" content="noindex, follow"&gt; toevoegt aan deze pagina’s. Daar is de WordPress SEO plugin dus niet meer specifiek voor nodig.

Uiteraard heb ik ook even gecontroleerd of WordPress dit al automatisch doet voor de zoekpagina’s, en dat is helaas nog niet het geval. Maar zoals Joost beloofd lost zijn WordPress SEO plugin dit op, en dat blijkt na controle ook daadwerkelijk zo te zijn.

<!-- This site is optimized with the Yoast WordPress SEO plugin v1.5.2.8 - https://yoast.com/wordpress/plugins/seo/ -->

En waarom de feed in zijn geheel niet geblokkeerd moet worden legt Joost ook nog even haarfijn uit.

Blocking /feed/ is a bad idea because an RSS feed is actually a valid sitemap for Google. Blocking it would prevent Google from using that to find new content on your site.

Er blijkt echter één deel van de website te zijn die Joost wel blokkeerd voor de zoekmachine.

I block the plugins directory because some plugin developers have the annoying habit of adding index.php files to their plugin directories that link back to their websites. For all other parts of WordPress, there are better solutions for blocking.

Samenvattend is onderstaande dus het ideale robots.txt bestand.

User-Agent: *
Disallow: /wp-content/plugins/

Overigens had Joost de kern van dit verhaal ook reeds benoemd in een artikel uit 2009, Preventing your site from being indexed, the right way, waar hij zijn verbazing ook al uitspreekt dat mensen robots.txt hiervoor blijven gebruiken.

Geblokkeerde JS en CSS door het ‘ideale robots.txt’ bestand

Het ideale robots.txt bestand blijkt helaas ook een beperkte houdbaarheidsdatum te hebben. Vandaag, 2 augustus 2014, las ik wederom een artikel van Joost, Google Panda 4, and blocking your CSS & JS. Uit dit artikel heb ik geleerd dat Google in Google Webmaster Tools een nieuwe tool heeft geïntroduceerd, namelijk Fetch as Google.

Zoals je kunt lezen als je op voorgaande link klikt, laat deze tool exact aan ons zien hoe Googlebot onze site ziet! Zie onderstaande afbeelding hoe dat er momenteel uitziet voor een klant van mij.

Fetch als Google respecteert robots.txt

Fetch als Google respecteert robots.txt

Voordat je er aan voorbij gaat, de preview die Google toont is exact hoe ik het in mijn browser zie. Dit is bijzonder! De Googlebot (de spider/webcrawler van Google) wordt net als andere webcrawlers vaak bestempeld als ‘domme gebruiker’ omdat ze alleen in staat zouden zijn om de tekstuele content uit de HTML van je pagina te ‘lezen’. Google blijft zichzelf echter steeds verbeteren en is nu dus in staat veel meer van het web te begrijpen en ziet onze websites dus nagenoeg zoals wij ze ook zien in onze moderne browsers! Google legt dit haarfijn uit in hun artikel Understanding web pages better.

Traditionally, we were only looking at the raw textual content that we’d get in the HTTP response body and didn’t really interpret what a typical browser running JavaScript would see. When pages that have valuable content rendered by JavaScript started showing up, we weren’t able to let searchers know about it, which is a sad outcome for both searchers and webmasters.

Als we de Googlebot willen toestaan om onze website te zien zoals wij de website ook zien in onze browser, is het dus belangrijk dat we CSS en Javascript bestanden niet voor Googlebot blokkeren. De kans is groot dat je dit wel (onbewust) hebt gedaan via je robots.txt, waarover later meer. Mocht je toch besluiten deze bestanden te blokkeren, dan hier uit hetzelfde artikel toch echt de redenen om dit niet te doen! Zoals je leest kan dit een negatief effect hebben op de zoekresultaten voor jouw website.

Sometimes things don’t go perfectly during rendering, which may negatively impact search results for your site. Here are a few potential issues, and – where possible, – how you can help prevent them from occurring:

  • If resources like JavaScript or CSS in separate files are blocked (say, with robots.txt) so that Googlebot can’t retrieve them, our indexing systems won’t be able to see your site like an average user. We recommend allowing Googlebot to retrieve JavaScript and CSS so that  your content can be indexed better. This is especially important for mobile websites, where external resources like CSS and JavaScript help our algorithms understand that the pages are optimized for mobile.
  • If your web server is unable to handle the volume of crawl requests for resources, it may have a negative impact on our capability to render your pages. If you’d like to ensure that your pages can be rendered by Google, make sure your servers are able to handle crawl requests for resources.
  • It’s always a good idea to have your site degrade gracefully. This will help users enjoy your content even if their browser doesn’t have compatible JavaScript implementations. It will also help visitors with JavaScript disabled or off, as well as search engines that can’t execute JavaScript yet.
  • Sometimes the JavaScript may be too complex or arcane for us to execute, in which case we can’t render the page fully and accurately.
  • Some JavaScript removes content from the page rather than adding, which prevents us from indexing the content.

Terug naar het artikel Rendering pages with Fetch as Google. Met alle voorgaande uitleg weten weten we nu het doel van de tool. Ook weten we dat als je bijvoorbeeld Javascript of CSS blokkeert in robots.txt dat Googlebot dus geen of een beperkte website kan laten zien in de preview.

Googlebot follows the robots.txt directives for all files that it fetches. If you are disallowing crawling of some of these files (or if they are embedded from a third-party server that’s disallowing Googlebot’s crawling of them), we won’t be able to show them to you in the rendered view.

Maar eigenlijk moet je het andersom zeggen, jij blokkeert Google om jouw website te crawlen zoals een normale gebruiker (jij en ik) de website ook zien in een moderne browser. En Google adviseert dus ook hier verstandig mee om te gaan.

We recommend making sure Googlebot can access any embedded resource that meaningfully contributes to your site’s visible content, or to its layout. That will make Fetch as Google easier for you to use, and will make it possible for Googlebot to find and index that content as well. Some types of content – such as social media buttons, fonts or website-analytics scripts – tend not to meaningfully contribute to the visible content or layout, and can be left disallowed from crawling.

Ter extra ondersteuning nog even een Youtube video met Matt Cutts waar dit in behandeld wordt: SMX Advanced 2014 – Google’s Matt Cutts You&A Keynote.

Terug naar de afbeelding die ik hierboven met jullie gedeeld heb. Je ziet dat Google diverse meldingen geeft van CSS en Javascript bestanden waar de Googlebot geen toegang toe heeft. Dit komt uiteraard omdat we de complete plugins folder in ons handmatige robots.txt bestand geblokkeerd hebben. Omdat we dit met een goede reden hebben gedaan, willen we dat zo houden. Om Googlebot echter niet te hinder gaan we de specifieke CSS en JS bestanden echter wel toestaan te crawlen, gewoon door meer specifiek te zijn. Het robots.txt komt er als volgt uit te zien:

User-Agent: *
Disallow: /wp-content/plugins/
Allow: /wp-content/plugins/sitepress-multilingual-cms/res/css/language-selector.css
Allow: /wp-content/plugins/jetpack/modules/widgets/widgets.css
Allow: /wp-content/plugins/tablepress/css/default.min.css
Allow: /wp-content/plugins/wp-views/embedded/res/css/wpv-pagination.css
Allow: /wp-content/plugins/easy-fancybox/fancybox/jquery.fancybox-1.3.6.pack.css
Allow: /wp-content/plugins/jetpack/modules/sharedaddy/sharing.css
Allow: /wp-content/plugins/wp-views/embedded/res/js/i18n/jquery.ui.datepicker-nl.js
Allow: /wp-content/plugins/wp-views/embedded/res/js/wpv-pagination-embedded.js
Allow: /wp-content/plugins/sitepress-multilingual-cms/res/js/sitepress.js
Allow: /wp-content/plugins/easy-fancybox/fancybox/jquery.fancybox-1.3.6.pack.js
Allow: /wp-content/plugins/easy-fancybox/jquery.easing.pack.js

Uiteraard zijn er diverse mogelijkheden om het aantal JS of CSS bestanden te beperken (zoals Minify), en is het natuurlijk altijd verstandig om te beoordelen of de JS en CSS die plugins gebruiken en implementeren in je website wel daadwerkelijk nodig zijn. Maar dat is om iets te bespreken in een nieuw blogartikel!

Affiliate links op je website

Mijn avonturen om via internet een inkomen te genereren zijn gestart met het bouwen van een affiliatewebsite. Vandaag kwam ik helaas tot de conclusie dat ik bij de vernieuwing van deze website voor een deel van de affiliate links, betaalde links naar andere websites, vergeten was het html attribute rel="nofollow" toe te voegen. Tijd om maar eens vast te  leggen waarom dit belangrijk is!

Wat zijn affiliate links?

Nog niet bekend met affiliate marketing? Het is dan op zijn plaats dat ik een korte introductie geef hoe affiliate marketing op bijvoorbeeld een blog van toepassing kan zijn. Voor het bouwen en beheren van succesvolle websites maak ik regelmatig gebruik van producten en diensten van derden. Na veel ‘trial and error’ weet ik inmiddels welke programma’s en diensten ik kan aanraden. Dat laatste zal ik natuurlijk niet nalaten, dat is tenslotte één van de redenen waarom ik ga bloggen. Sommige bedrijven waar ik zelf klant ben bieden een affiliate programma of partnerprogramma aan. Zodra ik mij daarvoor aanmeld kan ik advertentiemateriaal op mijn blog plaatsen en verdien ik een commissie over elke bezoeker die net al mij ook klant word. Het advertentiemateriaal kan een een simpele tekstlink zijn, maar bijvoorbeeld ook een banner.

Affiliate links op je website: niet zo eenvoudig…

Momenteel heb ik een aantal affiliate websites waar ik gebruik maak van tekstlinks en banners. Ga je hier mee aan de slag, dan heb je te maken met drie belangrijke aandachtspunten die ik in dit artikel wil benoemen.

Affiliate links aandachtspunten

  1. Google;
  2. Beheer;
  3. Betrouwbaarheid.

Affiliate links en Google

Normaal gesproken ziet Google links naar externe websites als een stem voor desbetreffende pagina. Daarmee help je mogelijk een andere pagina aan een betere reputatie en een sterkere positie in Google. Dit betekent niet dat je nooit een externe links moet opnemen in teksten op je website. De externe link kan immers relevant zijn aan de inhoud van je pagina en kan daardoor bijdragen aan de reputatie en positie in Google van je eigen pagina. Ik refereer daarvoor naar de pagina analyse van de WordPress plugin WordPress SEO van Yoast. Als je in je tekst geen externe link opneemt krijg je de volgende (fout)melding:

Geen externe uitgaande links gevonden op deze pagina, overweeg enkele toe te voegen, waar van toepassing.

Bij affiliate links ligt bovenstaande echter gevoelig! Je wilt immers zoveel mogelijk verkoop realiseren via je eigen pagina’s en geen stem uitbrengen op de pagina’s van het affiliate programma waar je aan deelneemt. Een ‘nofollow’ attribuut toevoegen aan de links is daarvoor een mogelijke oplossing.

‘Nofollow’ is een methode waarmee webmasters tegen zoekmachines kunnen zeggen dat ze de links op een bepaalde pagina of een specifieke link niet moeten volgen.

Daarnaast zijn affiliate links commercieel van aard, en heb ik eerder gelezen dat Google wil dat je hiervoor het ‘nofollow’ attribuut gebruikt: Google over rel=”nofollow”.

Betaalde links: de positie van een site in de zoekresultaten van Google is deels gebaseerd op een analyse van sites die een link naar de site bevatten. Om te voorkomen dat betaalde links onze zoekresultaten beïnvloeden en een negatief effect hebben op onze gebruikers, raden we webmasters met klem aan het kenmerk nofollow voor dergelijke links te gebruiken. Volgens de richtlijnen voor zoekmachines moeten betaalde links die door computers kunnen worden gelezen, op dezelfde manier bekend worden gemaakt als betaalde verbanden aan online en offline klanten (bijvoorbeeld het woord ‘Advertentie’ boven aan een paginagrote krantenadvertentie)..

Kortom, het is niet iets om te vergeten! Heeft het voor mij negatieve effecten gehad? Dat niet. Google geeft ook aan dat ze zelf meestal wel snappen wanneer het om affiliatelinks gaat. Zie onderstaande video van Matt Cuts waarin hij zegt:

We handle the vast majority of affiliate stuff correctly because if it is a large enough affiliate network we know about it and we handle it on our side. Even though we handle I believe the vast majority of affiliate links appropriately if you are at all worried about it, I would go ahead and just add the nofollow because you might be earning money from that.

En ook in onderstaande video wordt alles nog eens haarfijn uitgelegd.

Het beheer van affiliate links

Het beheer van affiliate links is een aandachtspunt waar ik in de praktijk mee geconfronteerd ben. Op één van mijn blogs heb ik handmatig affiliate links geplaatst naar andere webwinkels. Dit was ook de reden om de website opnieuw op te bouwen, en gebruik te maken van een productfeed. Op dat moment wist ik echter niet beter, maar als snel kwam ik er achter dat affiliate links wel eens aangepast moeten worden. Hou daar dus rekening mee, ook als je bijvoorbeeld voor je blog gebruikt maakt van affiliate links. Ik ga verder niet in op de vraag hoe we het beheer van affiliate links kunnen vereenvoudigen, los van de productfeed wat ik net benoemde, maar ik weet dat er een hoop WordPress plugins zijn die dit makkelijker voor je moeten maken. Ik heb die alleen nog niet uitgeprobeerd en kan er dus weinig over zeggen.

De betrouwbaarheid van affiliate links

Een ander probleem dat momenteel nog speelt is dat mijn affiliatelinks er niet uitzien als een normale link, maar overduidelijk betaalde links zijn, waardoor de betrouwbaarheid in twijfel zou kunnen worden getrokken. Een normale link zou zijn: http://www.1001-nacht-feestwinkel.nl/. Als je deze omzet met de LinkGenerator van TradeTracker ziet het er als volgt uit: http://www.1001-nacht-feestwinkel.nl/?tt=10458_12_121495_, duidelijk een betaalde link. TradeTracker is slechts één van de vele ‘tussenpersonen’ waar bedrijven hun affiliateprogramma’s hebben ondergebracht en daarmee affiliates zoals jij en ik stimuleren om hun producten te promoten. Ik neem TradeTracker als voorbeeld omdat zij hetvolgende zeggen over de betrouwbaarheid van affiliate links:

Naast de standaard linkingmethodes welke trackingcodes nodig hebben in de trackinglinks biedt TradeTracker een extra unieke trackingmethode genaamd CleanLinking. Het grootste voordeel van het gebruik van CleanLinking is dat de links naar adverteerders niet direct zichtbaar zijn als zijnde trackinglinks, waardoor de links er beter en betrouwbaarder uitzien naar uw bezoekers toe. Daarnaast geeft het u de mogelijkheid om naar campagnes van adverteerders te linken zonder dat u hierbij de Linkgenerator hoeft te gebruiken, aangezien de reguliere link simpelweg werkt.

Zoals gezegd is TradeTracker slechts één speler waar bedrijven hun affiliateprogramma’s onderbrengen, de vraag is dus hoe we voor alle links op onze websites ‘clean links’ kunnen gebruiken. Antwoord zal hopelijk later volgen!