Aparte mobiele URL's en de 'Vary: HTTP header'

Zoals ik al in mijn blogartikel van 19 maart aangaf, vond ik de sessies nogal gericht op de bouw van responsive websites. Echter in deze laatste hangout werd gelukkig aandacht besteed aan de andere 2 varianten:

  1. mobiele content serveren op een aparte domeinnaam of URL
  2. dynamisch serveren van mobiele content op de desktop URL (Vary: HTTP header)

Onze Google spreker Juan-Felipe Rincon benadrukte nog eens dat het voor de Google spider niet uitmaakt via welke variant je je mobiele content serveert. Als het technisch maar goed is ingericht. Google neigt wel vaak de voorkeur te geven aan een responsive site omdat die (volgens Google) het minst foutgevoelig is in aanmaak.
En vergeet ook niet dat het serveren van content op aparte URL's of via de Vary: HTTP header zowel contentmatig als technisch meer werk met zich meebrengt; je moet in principe 2 verschillende contentsites ontwikkelen en bijhouden.

Juan-Felipe gaf ons de volgende technische adviezen.

'Bidirectional' annotaties bij aparte mobiele URL's

Met aparte mobiele URL's wordt bedoeld:

  • m.example.com/ (aparte domeinnaam), of
  • www.example.com/mobile (via een sub-directory op de bestaande site)

Beide opties zijn van uit SEO-optiek goed, er is geen voorkeur. Als de annotaties technisch maar goed worden ingericht. Heel simpel gezegd, annotaties zijn signalen die je in de broncode van zowel de mobiele als de desktop pagina plaatst, waarmee je aangeeft dat het equivalenten zijn. Ze verwijzen dus naar elkaar:

  • In de desktop broncode geef je dat aan met de rel="alternate" tag
  • In de mobiele broncode voeg je de canonical tag toe

De annotaties worden geplaatst in de <head> van de broncode. Doe dit alleen voor pagina's die elkaars gelijke zijn. Dus als je bijvoorbeeld voor 'product y' geen aparte mobiele pagina hebt, plaats dan geen rel="alternate" tag in de desktop broncode.

Voorbeeld van een rel="alternate" tag in de desktop broncode:
Hiermee zeg je dat er een 'alternatieve' lokatie is als de pagina wordt opgeroepen via een 'media'-apparaat met een maximale breedte heeft van 640pixels (smartphone).

Voorbeeld van een canonical tag geplaatst in de mobiele broncode:
Via deze tag laat je zien dat de mobiele URL een tweelingbroer (of -zus) heeft op een ander domein.

Dynamische mobiele content tonen via de 'Vary: HTTP header'

Deze manier van content serveren komt niet vaak voor. De implementatie hiervan gebeurt op server niveau en moet secuur worden ingesteld. In het geval van dynamisch serveren wordt zowel de desktop als mobiele content getoond op dezelfde URL (net zoals bij een responsive site). Maar de mobiele pagina en dus ook de content kan er heel anders uitzien dan de desktop variant. Dat is het grote verschil met responsive design.

In Jip en Janneke taal is dit wat er gebeurt: als je met je smartphone een pagina wilt bekijken en er op klikt, wordt er eerst gekeken met wat voor apparaat jij je hebt aangemeld. Daarna krijg je de mobiele content voorgeschoteld. Dit gebeurt op serverniveau via user agent detectie door middel van de Vary: HTTP header (technisch gesproken). Als dit niet goed is ingesteld, kan het zijn dat je de desktopvariant te zien krijgt op je mobiel.

Voorbeeld van de 'Vary: HTTP header':

5 tips om niet te vergeten

Vervolgens gaf Juan-Felipe nog een aantal goede tips om niet te vergeten.

1- Redirects goed instellen

Zorg dat de redirects vanuit desktop naar mobiel correct zijn ingesteld.

Voorbeeld: Je hebt een desktoppagina voor 'product z' en je klikt op die pagina, vanuit de Google resultaten, via je smartphone. Dan is het de bedoeling dat je wordt doorgestuurd naar de mobiele 'product z' pagina (via HTTP 301 of HTTP 302) en niet bijvoorbeeld naar de mobiele homepage. Dat klinkt nu wel heel logisch, maar in de praktijk komt het nog wel eens voor dat je 'ongezout' wordt doorgestuurd naar de mobiele homepage. Dit is geen gebruikersvriendelijke manier van serveren. Als Google dit signaleert kunnen ze daar zelfs een melding van maken binnen de zoekmachineresultaten.

Voorbeeld van zo'n melding:


Stuur een mobiele bezoeker ook niet door naar de mobiele homepage als je geen equivalent hebt van de desktoppagina. Serveer dan gewoon de desktop pagina aan de mobiele bezoeker.

2- Geen HTTP 404 status code serveren aan mobiele bezoekers

Als je geen mobiele pagina hebt die gelijk is aan de desktoppagina, serveer de bezoeker dan ook geen HTTP 404 Not Found pagina, maar toon gewoon de desktop variant.

3- Link de tweeling aan elkaar, vinden ze niet erg

Bij het tonen van content op 2 aparte URL's, adviseert Google een link te zetten vanuit de mobiele pagina naar de desktoppagina, en andersom. Een bezoeker moet zelf kunnen kiezen welke variant hij of zij wil bekijken. En als iemand dan vanuit de mobiele versie kiest voor desktop, zorg dan dat die daar ook blijft tijdens de volledige sessie.

4- Check de crawlfouten in Google Webmaster Tools (GWT)

Als je een GWT- account hebt, check dan onder 'crawlfouten' de Faulty redirects voor de smartphone. Als Google ziet dat je bijvoorbeeld alles redirect naar de homepage van de mobiele site in plaats van naar de equivalent, wordt dat hier aangeven. En los het op voordat Google een waarschuwing plaatst in de zoekresultaten zoals hierboven.

Voorbeeld Faulty redirects voor smartphone in GWT:

5- Kadootje van Google

Als laatste tip gaf Juan-Felipe nog mee dat wanneer je alles keurig hebt ingericht, zoals correcte annotaties en redirects, Google in staat is de mobiele pagina te renderen zonder de redirect van desktop naar mobiel.
Dus stel; je zoekt via je mobieltje in de Google zoekmachine naar een onderwerp; je ziet een geschikt resultaat met als URL de desktopvariant. Maar deze desktoppagina heeft ook een mobiele variant. Google is dan in staat jou als gebruiker meteen door te sturen naar de mobiele pagina zonder dat er een redirect op serverniveau plaatsvindt. Dit scheelt tijd (0.5 tot 1 seconde).

Gratis voor niks kado van Google; ik vond dat een mooie afsluiting van deze #MobileMadness maand. Iemand die tijd investeert in optimalisatie mag ook zeker beloond worden.

Alle #MobileMadness hangouts op een rij

Ben je er aan toe je site mobielvriendelijk te maken maar wil je nog eens onze verslagen teruglezen van de afgelopen kick-off, hangouts en Q&A? Dat kan uiteraard:

Vragen of assistentie bij mobiel

Of heb je toch nog vragen of wil je begeleiding bij de bouw van een mobiele site? Ook dat kan, neem contact op met een van onze SEO specialisten.


Over Olinda Luksen

Olinda LuksenOlinda Luksen is werkzaam als Sr. SEO Consultant bij Maxlead. Vanuit die rol begeleidt ze klanten bij diverse SEO projecten; van de bouw van een nieuwe site tot het optimaliseren van bestaande websites om op die manier beter gevonden te worden in Google.

Olinda heeft ruime ervaring opgedaan in de reisbranche waar zij verantwoordelijk was E-commerce projecten waarin de focus op SEO lag.

Meer over Olinda >>