Virtueel robots.txt bestand in WordPress

In een kersverse WordPress installatie had ik via ‘Settings’ en dan ‘Reading’ braaf de zoekmachine geblokkeerd zodat de zoekmachine mijn website niet zal indexeren.

Blokkeer zoekmachine met virtueel robots.txt bestand in WordPress

Blokkeer zoekmachine met virtueel robots.txt bestand in WordPress

Toen ik het robots.txt bestand wilde controleren via de URL mijndomein.nl/robots.txt zag ik tot mijn verbazing dat het virtuele robots.txt bestand dat WordPress aanmaakt niet bestond! Na wat Google zoekopdrachten te hebben verricht ben ik er achter gekomen dat dit virtuele robots.txt bestand pas door Google wordt aangemaakt zodra je een bericht heb gepubliceerd. In mijn geval heb ik ook de permalink settings die nog op ‘Default’ stond aan moeten passen naar bijvoorbeeld ‘Post name’, en warempel toen deed het robots.txt bestand het gelukkig!

Paginering en SEO

Als je duplicate content hebt op je website kan het canonical element uitkomst bieden. In het geval er verschillende URL’s naar dezelfde pagina verwijzen, is het canonical element een manier om Google een hint te geven welke pagina opgenomen moet worden in de zoekresultaten. Lees eerst het artikel “Duplicate content en SEO” voor meer achtergrondinformatie over dit onderwerp. Naast duplicate content zijn er nog een aantal situaties te bedenken waarbij je Google wilt laten weten welke URL ze op moeten nemen in de zoekresultaten. Vaak wordt hier het canonical element voor gebruikt, terwijl dat niet de juiste oplossing is. Op 8 april 2013 verscheen er dan ook een blogpost op het Webmaster Central Blog van Google met de titel “5 common mistakes with rel=canonical“. In dit artikel zullen we deze veelgemaakte fouten bespreken.

Het internet kent vele voorbeelden van websites die paginering gebruiken. Het zojuist genoemde artikel geeft als voorbeeld een artikel verdeeld over meerdere pagina’s.

Imagine that you have an article that spans several pages:

  • example.com/article?story=cupcake-news&page=1
  • example.com/article?story=cupcake-news&page=2
  • and so on

Het artikel “Paginering” van Webmasterhulprogramma’s geeft ook een aantal voorbeelden.

Websites pagineren inhoud op verschillende manieren. Bijvoorbeeld:

  • Nieuws- en/of publicatiesites verdelen een lang artikel vaak over verschillende kortere pagina’s.
  • Winkelsites kunnen de lijst met items in een grote productcategorie verdelen over meerdere pagina’s.
  • Discussieforums verdelen threads vaak over opeenvolgende URL’s.

Vaak willen webmasters niet dat dat alle URL’s van de verschillende pagina’s in Google zichtbaar zijn. Gebruik maken van de het canonical element is in deze situatie echter niet van toepassing. De veelgebruikte fout die je ziet is dat webmasters het canonical element op de vervolgpagina’s laten verwijzen naar de eerste pagina van het artikel. Dit is echter foutief gebruik van het canonical element. De vervolgpagina’s bevatten immers unieke inhoud, geen duplicate content.

Specifying a rel=canonical from page 2 (or any later page) to page 1 is not correct use of rel=canonical, as these are not duplicate pages. Using rel=canonical in this instance would result in the content on pages 2 and beyond not being indexed at all.

Canonical element artikel paginering

Goede inhoud van pagina twee en pagina drie gaat verloren als je daar een canonical element gebruikt naar de eerste pagina.

Je kunt je afvragen waarom je überhaupt paginering op je website wilt hebben. Onderzoek door Google heeft aangetoond dat gebruikers liever alles op één pagina zien in plaats van tussen verschillende pagina’s (elk met hun eigen URL) te navigeren. In het artikel “View-all in search results” van 15 september 2011 wordt dit uitgelegd.

User testing has taught us that searchers much prefer the view-all, single-page version of content over a component page containing only a portion of the same information with arbitrary page breaks (which cause the user to click “next” and load another URL).

Google gebruikers zien liever view-all pagina's

Zoekers zien liever pagina’s die alle resultaten tonen versus paginering. Het laatste zorgt ervoor dat ze langer moeten wachten op het gewenste resultaat (latency).

Om deze reden zal Google al uit zichzelf proberen de ‘view-all’ pagina, als deze aanwezig is, op te nemen in de zoekresultaten in plaats van alle afzonderlijke pagina’s. Je hoeft hier dus niks voor te doen. Als mensen linken naar afzondelijke pagina’s, zal Google dit zien als link naar de ‘view-all’ pagina.

If your site has a view-all option, there’s nothing you need to do; we’ll work to do it on your behalf. Also, indexing properties, like links, will be consolidated from the component pages in the series to the view-all page.

Wil je Google echter toch een handje helpen om duidelijk te maken dat de ‘view-all’ pagina opgenomen moet worden in de zoekresultaten, dan kun je op de afzonderlijke pagina’s een canonical link element opnemen naar de ‘view-all’ pagina zoals hieronder afgebeeld.

Canonical naar "view-all" pagina

Soms duurt het echter te lang voor een ‘view-all’ pagina om te laden, en dat waarderen gebruikers natuurlijk niet. In zo’n geval kan het toch een betere oplossing zijn om de afzonderlijke pagina’s in de Google index op te laten nemen. Zorg er in zo’n geval voor dat er géén canonical link element naar de ‘view-all’ pagina opgenomen wordt op de afzonderlijke pagina’s en dat de ‘view-all’ pagina een robots meta tag met ‘noindex’ heeft opgenomen in de HTML.

Paginering komt veel voor op het internet en Google zal er altijd naar streven om gebruikers het beste resultaat te geven in de zoekresultaten. Als het ‘view-all’ verhaal niet van toepassing is voor jouw website kun je Google in dat geval toch een hint geven over de relatie tussen de afzonderlijke pagina’s met rel=”next” en rel=”prev”. Volg de link om te zien hoe je dit kunt implementeren op je website.

Google zal alle links naar de afzonderlijke pagina’s clusteren zodat de hele serie pagina’s PageRank kan opbouwen. Google zal de bezoeker sturen naar de meest relevante afzonderlijke pagina, meestal de eerste pagina van de serie.

  • Consolidate indexing properties, such as links, from the component pages/URLs to the series as a whole (i.e., links should not remain dispersed between page-1.html, page-2.html, etc., but be grouped with the sequence).
  • Send users to the most relevant page/URL—typically the first page of the series.
  • Consolidate indexing properties, such as links, between the component pages/URLs.
  • Send users to the most relevant page/URL from the component pages. Typically, the most relevant page is the first page of your content, but our algorithms may point users to one of the component pages in the series.

Paginering video

Op 13 maart 2012 is er een blogpost met video verschenen over paginering met rel=”next” en rel=”prev”. De video heb ik hieronder geplaatst.

Ook wordt er in de blogpost antwoord gegeven op een brandende vraag die ik had, in welke situaties het gebruik van ‘noindex’ op vervolgpagina’s nog steeds verstandig kan zijn. Dit hoeft alleen als je er zeker van wilt zijn dat deze pagina’s niet opgenomen worden in de zoekresultaten.

Does rel=next/prev also work as a signal for only one page of the series (page 1 in most cases?) to be included in the search index? Or would noindex tags need to be present on page 2 and on?

When you implement rel=”next” and rel=”prev” on component pages of a series, we’ll then consolidate the indexing properties from the component pages and attempt to direct users to the most relevant page/URL. This is typically the first page. There’s no need to mark page 2 to n of the series with noindex unless you’re sure that you don’t want those pages to appear in search results.

Doordat deze robots meta tag gebruikt kan worden naast de link elementen rel=”next” en rel=”prev” ga ik ervan uit dat Google nog steeds de links naar de afzonderlijke pagina’s clustert zodat PageRank geldt over de hele serie pagina’s. Het topic in Google Webmaster Forums over rel=”next” en rel=”prev” bevestigt dit. Daarmee zijn alle vragen beantwoord.

@TheDonald, @jerenel: If you’ve marked page 2 to n of your paginated series as “noindex, follow” to keep low quality content from affecting users and/or your site’s rankings, that’s fine, you can additionally include rel=”next” and rel=”prev.” Noindex and rel=”next”/”prev” are entirely independent annotations.

This means that if you add rel=”next” and rel=”prev” to noindex’d pages, it still signals to Google that the noindex’d pages are components of the series (though the noindex’d pages will not be returned in search results). This configuration is totally possible (and we’ll honor it), but the benefit is mostly theoretical.

If you believe the user experience on page 2 to n provides little value — so much so that you’ve already marked these pages as noindex — then to ensure that these low-quality pages aren’t returned to users and/or considered in ranking updates such as Panda, even if you choose to add rel=”next” and rel=”prev,” you may want to consider keeping the noindex (or “noindex, follow”).

Paginering en WordPress

WordPress websites maken veelvuldig gebruik van paginering. Om bovenstaande goed toe te passen adviseer ik het gebruik van WordPress SEO. WordPress SEO voegt automatisch rel=”next” en rel=”prev” toe aan de HTML van de pagina. Dat ziet er als volgt uit.

rel="next" en rel="prev" door WordPress SEO

WordPress SEO voegt automatisch rel=”next” en rel=”prev” toe aan de HTML van pagina’s.

Zoals je ziet is er ook een canonical link element aanwezig via de plugin WordPress SEO die verwijst naar zichzelf, en dus niet naar de eerste pagina in de serie pagina’s. Dit is zoals het hoort te zijn. Ook heeft WordPress SEO een robots meta tag toegevoegd met ‘noindex’ op alle pagina’s van de serie, behalve de eerste pagina. Zoals uitgelegd is dit een mogelijkheid maar niet noodzakelijk als je gebruikt maakt van rel=”prev” en rel=”next”. Heb je toch een reden om noindex toe te passen dan kan dat ingesteld worden via WordPress SEO onder ‘Titles & Meta’.

NOINDEX voor paginering via WordPress SEO

De robots meta tag met “noindex” kan gebruikt worden voor paginering via WordPress SEO

Duplicate content en SEO

Duplicate content, in het Nederlands dubbele inhoud, houdt elke website eigenaar op een gegeven moment wel bezig. Velen zijn daarbij angstig voor een ‘duplicate content penalty’ van Google. Alweer een tijd geleden las ik een erg interessant artikel van Tom Ewer, The Right Way to Use Categories and Tags in WordPress to Boost SEO. Hij benoemde heel goed dat deze penalty helemaal niet bestaat. Althans, niet in de vorm zoals de meeste mensen erover spreken!

Before we start, let’s push this little issue to one side. Google (and other major search engines) will never penalize a WordPress site for having archive pages that publish and point to the same content. They confirmed this way back in 2008. When Google comes across duplicate content, their algorithm will adjudge which version is the original, and place that above the alternative options. There is in reality just one valid reason why you might choose to noindex taxonomy/archive pages — when the pages are of no use to searchers (e.g. date based archives). If a page is of potential use to a searcher, it should be included within the index. I would recommend that you keep your post’s content to excerpt length when published on taxonomy and archive pages. Not only will this resolve any duplicate content/devaluation issues, it will make for more easily browseable pages.

Tom Ewer geeft dus aan dat het geen probleem is als twee archiefpagina’s naar hetzelfde artikel linken. Dat gebeurt immers al snel als je een artikel in meer categorieën plaats of verschillende tags toewijst aan een blogbericht. Tijd om te definiëren wat duplicate content precies is.

Wat is duplicate content?

Als wij het over duplicate content hebben, bedoelen we meestal pagina’s die via verschillende URL’s bereikbaar zijn. De webmasterhulpprogramma’s schrijven het volgende:

Dubbele inhoud verwijst gewoonlijk naar substantiële blokken inhoud binnen of tussen domeinen die ofwel volledig gelijk zijn of in hoge mate op elkaar lijken. Dit is meestal niet misleidend bedoeld. Voorbeelden van niet-kwaadwillige dubbele inhoud zijn:

  • Discussiegroepen die zowel normale pagina’s als ingekorte versies voor mobiele apparaten kunnen genereren
  • Items die worden weergegeven of waarnaar wordt verwezen via meerdere, afzonderlijke URL’s
  • Printerversies van webpagina’s

Het tweede item in bovenstaande quote geeft dus aan dat Tom Ewer het helemaal aan het juiste eind heeft. Hoewel je dus ook de volledige artikelen mag weergeven op de homepage of archiefpagina’s, is het advies van Matt Cutts om alleen een samenvatting weer te geven. Ook dit werd reeds door Tom Ewer benoemd.

In het artikel Deftly dealing with duplicate content uit 2006 geven ze ook nog het voorbeeld:

store items shown (and — worse yet — linked) via multiple distinct URLs

In het artikel Demystifying the “duplicate content penalty” uit 2008 geven ze zo’n voorbeeld van twee URL’s die exact dezefde pagina weergeven. Bij de eerste link wordt eerst de kleur geselecteerd in een webwinkel, en daarna het merk. In de tweede link is dit net andersom.

Like www.example.com/skates.asp?color=black&brand=riedell and www.example.com/skates.asp?brand=riedell&color=black.

Duplicate content penalty

Het antwoord is nee, je krijgt geen duplicate content penalty. Bovenstaande voorbeelden van duplicate content zijn, zoals Google het zelf zegt, niet misleidend bedoeld. In het artikel waar Tom Ewer naar verwijst bevestigd Susan Moskwa van Google ook dat er geen penalty is:

Let’s put this to bed once and for all, folks: There’s no such thing as a “duplicate content penalty.” At least, not in the way most people mean when they say that.
There are some penalties that are related to the idea of having the same content as another site—for example, if you’re scraping content from other sites and republishing it, or if you republish content without adding any additional value. These tactics are clearly outlined (and discouraged) in our Webmaster Guidelines.

Inhoud kopiëren en op je eigen website plaatsen is dus niet toegestaan! In die gevallen kan Google dus wel een ‘penalty’ geven:

In de zeldzame gevallen waarin Google merkt dat dubbele inhoud wordt weergegeven met de bedoeling onze rangschikking te manipuleren en onze gebruikers te misleiden, zullen we ook de juiste aanpassingen aanbrengen in de indexering en rangschikking van de betreffende sites. Dit kan een nadelig effect hebben op de positie van de site of de site kan worden verwijderd uit de index van Google en daardoor niet meer in zoekresultaten worden weergegeven.

De conclusie is dat je als gewone webmaster bezig bent met je eigen website, je niet druk hoeft te maken over (een penalty voor) duplicate content.

Having this type of duplicate content on your site can potentially affect your site’s performance, but it doesn’t cause penalties.

Wat is geen duplicate content?

In het eerder genoemde artikel uit 2006 worden ook nog twee voorbeelden aangedragen wat Google niet ziet als duplicate content, namelijk eenzelfde artikel in verschillende talen en het kopiëren van kleine stukjes tekst (zoals quotes in dit artikel).

Though we do offer a handy translation utility, our algorithms won’t view the same article written in English and Spanish as duplicate content. Similarly, you shouldn’t worry about occasional snippets (quotes and otherwise) being flagged as duplicate content.

Wat doet Google met duplicate content?

In alle gevallen waar er sprake is van duplicatie content zonder opzet, probeert Google de beste URL weer te geven in de zoekresultaten. Andere URL’s die verwijzen naar dezelfde content filtert Google uit de zoekresultaten. Zoekmachines, waaronder Google, willen immers de beste resultaten weergeven voor een zoekopdracht. Tien resultaten met verschillende URL’s die allemaal linken naar dezelfde pagina is dus niet de bedoeling! Dat is ook de reden waarom duplicate content voor Google zo belangrijk is. Google heeft een algoritme gemaakt om duplicate URL’s uit de zoekresultaten te weren, en ons als gebruikers dus van de beste unieke resultaten te kunnen voorzien. In onderstaande quote uit het eerder genoemde artikel van 2008 wordt uitgelegd hoe het algoritme werkt.

Google tries to filter out duplicate documents so that users experience less redundancy. You can find details in this blog post, which states:

  1. When we detect duplicate content, such as through variations caused by URL parameters, we group the duplicate URLs into one cluster.
  2. We select what we think is the “best” URL to represent the cluster in search results.
  3. We then consolidate properties of the URLs in the cluster, such as link popularity, to the representative URL.

Here’s how this could affect you as a webmaster:
In step 2, Google’s idea of what the “best” URL is might not be the same as your idea. If you want to have control over whether www.example.com/skates.asp?color=black&brand=riedell or www.example.com/skates.asp?brand=riedell&color=black gets shown in our search results, you may want to take action to mitigate your duplication. One way of letting us know which URL you prefer is by including the preferred URL in your Sitemap.
In step 3, if we aren’t able to detect all the duplicates of a particular page, we won’t be able to consolidate all of their properties. This may dilute the strength of that content’s ranking signals by splitting them across multiple URLs.

In het laatste deel van bovenstaande quote wordt dus duidelijk dat er ook situaties zijn waar Google het duplicate content probleem niet helemaal oplost zoals de webmaster dat zou wensen. Verder in het artikel wordt nog een ander interessant nadeel van duplicate URL’s benoemd. Google moet namelijk wel elke URL crawlen om er achter te komen dat het duplicate content is! Dat kost bandbreedte op je website.

Lastly, consider the effect that duplication can have on your site’s bandwidth. Duplicated content can lead to inefficient crawling: when Googlebot discovers ten URLs on your site, it has to crawl each of those URLs before it knows whether they contain the same content (and thus before we can group them as described above). The more time and resources that Googlebot spends crawling duplicate content across multiple URLs, the less time it has to get to the rest of your content.

Gelukkig zijn er een hoop manieren om Google te vertellen welke URL opgenomen moet worden in de zoekresultaten, of welke URL’s genegeerd kunnen worden bij het crawlen. Praktisch alle informatie hierover vindt je in de artikelen ‘Dubbele inhoud’ en ‘Canonieke URL’s’.

Duplicate content video’s

Heel veel mensen blijven vragen stellen over duplicate content. En gelukkig blijft Matt Cutts de vragen beantwoorden. Een geweldige bron van Matt Cutts video’s kun je vinden op The ShortCutts website. Zoek daar op duplicate content en je vindt er diverse video’s met vragen en antwoorden. Een aantal vindt ik de moeite waard om hier te plaatsen.

In onderstaande video krijgt Matt Cutts de vraag of het een probleem is dezelfde productspecificaties op je productpagina te hebben staan als vele andere webwinkels. Het antwoord is dat dit niet erg is. Bijvoorbeeld de specificaties van een laptop zijn nou eenmaal altijd hetzelfde. Je moet er echter wel voor zorgen dat de rest van je pagina afwijkt ten opzichte van de andere websites. Zorg dus voor een unieke productomschrijving bijvoorbeeld. Waarom zou Google jouw anders hoger moeten ranken dan alle andere websites moet je jezelf afvragen.

Ben je er nog niet van overtuigd dat je echt een unieke productomschrijving moet gebruiken voor jouw productpagina’s? Hier beantwoord Matt Cutts de vraag of dezelfde productomschrijving gebruiken als op andere webwinkels gezien kan worden als duplicate content. Het antwoord is natuurlijk ‘ja’.

In het geval er verschillende URL’s naar dezelfde pagina verwijzen, is het canonical element een manier om Google een hint te geven welke pagina opgenomen moet worden in de zoekresultaten. In onderstaande video geeft Matt Cutts meer uitleg over het gebruik van het canonical element.

Maakt je webwinkel gebruik van automatisch genereerde URL-parameters, dan kun je Google vertellen welke parameters genegeerd kunnen worden. Je bespaart hiermee bandbreedte en Google kan meer aandacht besteden aan het crawlen van URL’s die er echt toe doen in plaats van het crawlen van duplicate content. In onderstaande video meer uitleg over het gebruik van URL-parameters in Google Webmaster Tools.

WordPress in het Nederlands

WordPress in het Nederlands is mogelijk, hoewel de standaard WordPress download van WordPress.org weergegeven wordt in het Amerikaans Engels. Niet zo gek, want WordPress is ontstaan in Texas, Amerika. Er zijn een groot aantal bijdragers aan de WordPress community om WordPress in zoveel mogelijk talen beschikbaar te maken. Het Nederlandse vertaalteam, dat onder leiding staat van Remkus de Vries, heeft een download voor WordPress in het Nederlands beschikbaar gesteld. Met deze download kun je WordPress direct in het Nederlands downloaden en instellen. Maar wat als je WordPress al in het Engels hebt geïnstalleerd? Of, zoals in mijn geval, mijn webhost WPEngine standaard de website in het Engels installeert. We kunnen dus eigenlijk twee werkwijzes onderscheiden:

  1. WordPress in het Nederlands downloaden en instellen;
  2. WordPress in het Engels omzetten naar WordPress in het Nederlands.

WordPress in het Nederlands downloaden en instellen

  1. Download WordPress in het Nederlands.
  2. Het .zip bestand moet je vervolgen opslaan én uitpakken op je computer.
  3. Upload alle bestanden van het uitgepakte .zip bestand naar de rootlocatie van je server via een (S)FTP verbinding. Voor het uploaden van bestanden via een (S)FTP verbinding heb je een programma nodig. Zelf maak ik gebruik van FileZilla (gratis). Heb je geen inloggegevens voor een (S)FTP verbinding ontvangen, weet je niet wat je rootlocatie is en/of weet je niet hoe je bestanden moet uploaden? Schakel dan je webhost in.
  4. In de rootlocatie van je server vind je het bestand wp-config.php, open dit bestand in een text editor om deze te gaan bewerken. Een voorbeeld van een text editor is het programma kladblok, maar een beter alternatief is Sublime Text 2. In mijn geval klik ik op de rechter muisknop en vervolgens op ‘Bekijken/bewerken’ om het wp-config.php bestand te openen in Sublime Text 2.
  5. Zoek de code define ('WPLANG', ''); op in het bestand en vervang dit door define ('WPLANG', 'nl_NL');.
  6. Sla het bestand op en upload het weer naar de rootlocatie van je server. In mijn geval heb ik het bestand rechtstreeks vanuit de server geopend (zie stap 4), en is het voldoende om op Ctrl + S te klikken en terug te gaan naar het programma FileZilla. Deze geeft dan automatisch een melding met de vraag of je het bestand wilt uploaden.

WordPress in het Engels omzetten naar WordPress in het Nederlands

  1. Volg de stappen 1 en 2 zoals hierboven beschreven.
  2. In het uitgepakte .zip bestand vind je de map ‘languages’ door eerst op de map ‘wp-content’ te klikken. Upload deze map ‘languages’ in de ‘wp-content’ map op je server via een (S)FTP verbinding. Voor meer informatie zie stap 3 zoals hierboven beschreven.
  3. Volg de stappen 4 tot en met 6 zoals hierboven beschreven.

Niet alles vertaald naar het Nederlands?

Als je scherp bent dan heb je gezien dat op mijn website op dit moment van schrijven, 4 augustus 2013, nog steeds niet alles is vertaald naar het Nederlands. Ik heb zelf natuurlijk bovenstaande stappen uitgevoerd. Ervaar je hetzelfde probleem? Het probleem schuilt zich dan meestal in het gebruik van een bepaald WordPress thema. Zelf maak ik gebruik van het Toolset Bootstrap thema, en de ontwikkelaars hebben Engelse woorden opgenomen in dit thema die ze niet in aanmerking laten komen voor de standaard vertaling zoals hierboven uitgelegd. Neem contact op met de ontwikkelaar van het WordPress thema dat je gebruikt om vertaalproblemen op te lossen. Ik heb mijn thema ontwikkelaar gemeld dat dit probleem speelt en gevraagd dit voor een toekomstige release op te lossen.

Dear Willem,

Yes. This is hard coded to the theme. We will review this and add this to our todo list and make sure that what is translatable by WP core (by default) should be translatable as well to the Toolset Bootstrap theme.

Bronnen WordPress in het Nederlands

Meer informatie over dit onderwerp kun je vinden via de WordPress Codex:

Pinterest waarschuwt pinners bij prijsdalingen!

Omdat veel mensen Pinterest graag gebruiken om ideeën op te doen voor nieuwe aankopen, heeft Pinterest in hun artikel ‘A feed just for shopping‘ bekend gemaakt nu ook een feed te hebben alleen voor shopping. Kies in het menu voor Cadeaus.

Het is al langer mogelijk om je als bedrijf te registeren van Pinterest. Verkoop je producten dan moet je zeker aan de slag met Product Pins. De pin toont dan niet alleen een afbeelding van je product, maar ook de prijs, beschikbaarheid en het gegeven dat deze te koop is via jouw website. Het zijn ook alleen deze Product Pins die getoont worden in de nieuwe shopping feed van Pinterest.

Het andere voordeel van Product Pins, is dat klanten door een re-pin van het door hun geliefde artikel, op de hoogte kunnen blijven van prijsdalingen (dus aanbiedingen). Ik quote uit het eerder gelinkte artikel.

Pinners also get email notifications when Product Pins they’ve saved drop in price.

Hoe mooi is dat? Pinterest geeft zelf het goede voorbeeld hoe jij het ook voor je bedrijf in zou kunnen zetten.

Pinterest waarschuwt bij prijsdaling Product Pin

Pinterest waarschuwt bij prijsdalingen!

Verwijder Categoriebasis van URL’s in WordPress

Wil je de “categoriebasis” niet gebruiken voor je WordPress URL’s? Dat is mogelijk, maar met een waarschuwing! Ik gebruik het zelf ook op enkele blogs. De berichten worden geplaatst in categorieën, en normaal gesproken kun je de categoriepagina bekijken via een URL als mijnsite.com/categorie/nieuws. De plugin WordPress SEO van Yoast gaf ons echter de mogelijkheid om de categoriebasis uit de URL te verwijderen, zie onderstaande afbeelding.

Verwijder categoriebasis uit WordPress URL

Deze opmerking gaat nu echter gepaard met een dikke waarschuwing.

The feature for stripping the category base will be removed in version 1.6 of WordPress SEO. We suggest using FV Top Level Categories if you insist on keeping this but do know that the feature is very error prone and not that important for your SEO.

As soon as you disable the feature below, the option will no longer be available.

Dit wordt verder ook toegelicht via WordPress SEO op Github. Net als in het artikel Removing the Category Base from Your URLs in WordPress wordt de plugin FV Top Level Categories genoemd als alternatief.

Pas wel op dat als je de categoriebasis verwijderd, je niet dezelfde URL’s gebruikt als pagina’s. FN Top Level Categories legt het nog eens uit.

Normally WordPress uses the category prefix to distinguish page from a category, but with this plugin you need to make sure the slugs are unique, otherwise some pages might turn up instead of categories.

Hoe vaak word je Google+ pagina, foto’s en berichten bekeken?

Het antwoord op de vraag hoe vaak je Google+ pagina, foto’s en berichten worden bekeken is relatief simpel te beantwoorden. Google heeft geeft nu het aantal weergaven weer, zie de afbeelding ter illustratie.

Google+ pagina weergaven

Google+ pagina weergaven

Wil je de paginaweergaven verbergen, volg dan de instructies op de Google pagina See how many times your Google+ page & content has been viewed by other people.

Google Analytics trackingscode implementeren op website

Op dit moment verlangt Google Analytics dat je de nieuwe Universal Analytics-trackingscode implementeert op je website.

Universal Analytics biedt nauwkeurigere gegevens en toegang tot nieuwe tools.

De instructie hoe deze trackingscode geimplementeerd moet worden op een website vind ik in Google Analytics nogal beperkt.

Dit is de Universal Analytics-trackingcode voor deze property. Kopieer en plak deze code op elke webpagina die u wilt bijhouden om te profiteren van alle voordelen van Universal Analytics voor deze property.

Waar moet deze code exact ‘geplakt’ worden. Het antwoorden vinden op een Google Analytics helppagina via het artikel De webtrackingcode instellen.

4. Plak het fragment (ongewijzigd, in zijn geheel) in elke webpagina die u wilt bijhouden. Plak het fragment vlak voor de afsluitende tag .
Als uw website gebruikmaakt van sjablonen om pagina’s te genereren, plakt u het fragment vlak vóór de afsluitende tag, in het bestand dat het gedeeltebevat.

Succes!

Google Analytics trackingscode in WordPress

Bijna elk thema die je voor WordPress gebruikt heeft een wp_head in het header.php bestand zitten, en daardoor kan een plugin ook de code voor je implementeren op je WordPress website. Dit is eenvoudiger en biedt vaak meer mogelijkheden. Ik maak gebruik van de plugin Google Analytics for WordPress van Yoast.

Zoekopdrachten in Google Analytics

In Google Analytics kun je bijhouden welke zoekopdrachten gebruikers hebben ingevoerd in Google om je site te bereiken. Dit kun je vinden onder Acquisitie, Zoekmachineoptimalisatie en dan Zoekopdrachten, zoals de pijl op onderstaande afbeelding toont.

Zoekopdrachten in Google Analytics

Meer informatie kun je vinden in het Google Analytics artikel Over zoekmachineoptimalisatie.

Wat bovenstaande afbeelding ook aangeeft is dat je de website eerst moet toevoegen en verifiëren door gebruik te maken van Webmasterhulpprogramma’s van Google. Klik je op de grijze button dan kom je op een Google Analytics scherm waar je de Instellingen voor Webmasterhulpprogramma’s kunt vinden. Klik daar op bewerken om vervolgens de website die is toegevoegd aan Webmasterhulpprogramma’s van Google te selecteren, en de koppeling is gemaakt!

Hoe verwijder je de schaduw van een Pinterest widget?

Vandaag heb ik op een website de profielwidget van Pinterest toegevoegd. Heel vervelend alleen is de drop-shadow CSS die Pinterest heeft toegepast op de widgets, in onderstaande afbeelding is meteen duidelijk wat ik bedoel.

Pinterest widget "box-shadow" probleem

Het kan natuurlijk ook zijn dat je een andere kleur achtergrond wenst dan wit én geen ronde hoeken wenst. Hoe gaan we dit nou oplossen?

Het buitenste span element van de widget laat onderstaande CSS bij bijbehorende class zien.

span.PIN_1394313494148_embed_grid.PIN_1394313494148_fancy {
background: #fff!important;
box-shadow: 0 0 3px #aaa!important;
border-radius: 3px!important;
}

Wil je dit overschrijven middels eigen CSS om één of alle van de CSS regels aan te passen, dan dien je zelf een extra div element toe te voegen om de geplakte code van de Pinterest widget.

<div id="pinterest-container"><a data-pin-do="embedUser" href="http://nl.pinterest.com/klepbank/" data-pin-scale-height="248" data-pin-board-width="300">Visit KlepbankOnline.nl's profile on Pinterest.</a></div>

Vervolgens kun je in je CSS regels opnemen voor het div element met de class pinterest-container.

#pinterest-container > span { 
     box-shadow: none !important; 
}

Dit met dank aan Google en het artikel Anyone know how to remove border from Pinterest widget?