Wer in den mobilen Ergebnissen bei Google zukünftig nicht so angezeigt werden möchte, sondern lieber so, sollte dringend die richtige Implementierung seiner mobilen Webseite sicherstellen. Welche Möglichkeiten es gibt, und wie eine fehlerhafte Implementierung trotzdem Resultate liefert, soll dieser Artikel aufzeigen.
Grundsätzlich gibt es drei verschiedene Varianten, eine mobile Webseite zu erstellen:
- durch Responsive Webdesign
- durch dynamische Bereitstellung der Inhalte auf derselben URL
- oder auf einer separaten mobilen Webseite, zum Beispiel einer Subdomain
Während beim Responsive Webdesign immer das gleiche HTML ausgespielt wird und die Darstellung der Inhalte über Media-Queries (CSS) für verschiedene Bildschirmauflösungen variiert, wird die mobile Ausgabe bei der zweiten Variante (dynamische Bereitstellung der Inhalte) in Abhängigkeit vom User-Agent getroffen. Variante 3 (separate mobile Webseite) unterscheidet sich insofern von Variante 2, dass die Inhalte der mobilen Version nicht auf derselben URL bereitgestellt werden, sondern auf einer neuen URL, zum Beispiel einer Subdomain.
Jede dieser drei Varianten hat ihre Daseinsberechtigung und Vorteile/Nachteile mit Blick auf verschiedene Anwendungsfälle. Im Folgenden werde ich das Setup der dritten Variante genauer unter die Lupe nehmen.
Auf der Desktop-Version wird dem Googlebot in dem Tag mit dem Attribut rel=“alternate“ eine alternative Version signalisiert. Mit dem Attribut href=““ wird die konkrete Ziel-URL angezeigt, auf der sich die alternative Version befindet. Auf der entsprechenden Unterseite der mobilen Version muss dann ein Canonical-Tag auf die vergleichbare Unterseite der Desktop-Version verweisen. Google schreibt dazu: „Dieses Tag rel=“canonical“ auf der mobilen Seite, das auf die Desktop-Seite verweist, ist obligatorisch.“
Sucht ein Nutzer nun mit einem mobilen Endgerät in Google, dann wird die Desktop-Version einfach durch die Mobile-Version ersetzt. Googelt man zum Beispiel [noblego.de] mit dem iPhone, erhält man folgendes Ergebnis:
Spannend ist die Art der Implementierung aus mehreren Gründen. Zum einen ist weder ein Canonical-Tag im Quellcode, HTTP-Header oder der Sitemap (http://m.noblego.de/sitemap-1.xml) implementiert, zum anderen ist die komplette Subdomain von der Indexierung durch NOINDEX und vom Crawling durch NOFOLLOW ausgeschlossen.
Eine Site-Abfrage (im Firefox User-Agent iPhone) liefert folgendes erwartbares Ergebnis:
Führt man die Site-Abfrage (im Firefox User-Agent iPhone) wie folgt aus, erscheinen Ergebnisse von m.noblego.de:
Bei der Site-Abfrage [site:noblego.de inurl:“m.noblego.de“] mit dem User-Agent iPhone erfolgt der Hinweis, dass keine Suchergebnisse gefunden wurden. Allerdings werden im unteren Bereich in den Vorschlägen URLs der Mobile-Version angezeigt.
Ein Blick in die Webmaster Tools verrät, dass die Seite sehr wohl gecrawlt wird. Benny von noblego.de war so nett, mir Zugriff auf die Subdomain m.noblego.de zu gewähren.
Wenig überraschend ist die Tatsache, dass in den Webmaster Tools keine indexierten Seiten angezeigt werden.
Ergänzend hierzu der Indexierungsstatus der Sitemap, der zum gleichen Ergebnis kommt.
Nicht überraschend ist, dass die Subdomains in den mobilen SERPs Rankings erzielt. Schließlich wird die mobile Subdomain in den Suchergebnissen angezeigt.
Spannend ist, dass Google bei diesem Setup offenbar das NOINDEX-Tag vollkommen ignoriert (beim dem Verweis auf die Mobile-Version mit rel=“alternate“), obwohl es davon weiß, wie die site:-Abfrage belegt. Dementsprechend wird die Mobile-Version anzeigt, obwohl sie nicht gecrawlt werden dürfte – schließlich fehlt außerdem der Canonical-Tag.
Eine mögliche Erklärung ist, dass die Seiten zuvor auf INDEX gestanden haben. Dagegen spricht allerdings, dass in den Webmaster Tools keine indexierten Seiten angezeigt werden.
Auch bild.de verfügt über eine mobile Subdomain. Die Startseite findet man unter http://m.bild.de/,variante=L. Genau wie noblego.de ist auch die Startseite der mobilen Version von der Indexierung ausgeschlossen. Der Canonical-Tag verweist dabei auf die WWW-Version:
Im Unterschied zu noblego.de wurde auf der Startseite kein rel=“alternate“ implementiert. Ob sich dieser Verweis möglicherweise in der Sitemap befindet, kann an dieser Stelle nicht geprüft werden. In jedem Fall liefert die „Brand“-Suchanfrage mit dem iPhone folgendes Ergebnis:
Offenbar wurden hier nur solche Ergebnisse indexiert, die unter der m.bild.de-Subdomain auch für die Indexierung freigegeben wurden.
Genau dieses Ergebnis hätte ich eigentlich auch für noblego.de erwartet, unabhängig davon, ob ein rel=“alternate“ eingebunden ist oder nicht. Was denkt ihr darüber?
Bildnachweis:
© Oleksiy Mark – Fotolia.com
