Google Suchindex: Mobile first - Index auch für Suchen auf dem Desktop rückt näher - Websites, die nicht mobil nutzbar sind, verlieren - responsives Webdesign als beste Lösung

23.12.2017 23:48:52, Jürgen Auer, keine Kommentare

Wer über die Weihnachtsfeiertage noch nach "etwas Arbeit" sucht: Der sollte womöglich einen Blick auf seine Website werfen. Zumindest dann, wenn ihm diese ab und zu Anfragen und Kunden bringt, sofern die Kunden über Google kamen.

Google hatte es im Oktober 2016 bereits angekündigt: Längerfristig soll der "mobile Index" der Primärindex auch für Suchen auf dem Desktop werden.

Das heißt: Ursprünglich gab es nur einen Index, aus dem die Suchergebnisse entsprechend ihrer Rangordnung angezeigt wurden. Dann gab es erste mobile Geräte und Suchanfragen über Google von solchen Geräten. Irgendwann hat Google damit begonnen, Seiten, die sich schlecht mobil nutzen lassen, in diesem Index abzuwerten. Das war der Beginn des "mobilen Index". Eine Seite konnte also im "Desktop-Index" vorne auftauchen. War sie aber auf mobilen Geräten schlechter nutzbar, war auch dort die Suchmaschinenposition schlechter.

Schon seit geraumer Zeit erhält Google deutlich mehr Anfragen über mobile Geräte als über Desktop-Geräte. Damit gab es im letzten Jahr eine Ankündigung, daß Google verstärkt damit experimentiert, den Smartphone-Googlebot weiterzuentwickeln. Dieser untersucht nicht nur den Text und die Links, so wie das der klassische Googlebot seit Jahren macht. Sondern er spidert zusätzlich JavaScript und CSS-Dateien. Und ermittelt, ob die Website gut auf mobilen Geräten nutzbar ist. Damit kann diese "mobile Nutzbarkeit der Website" direkt zu einem Rankingkriterium werden.

Im Webmaster-Central-Blog gab es nun einen erneuten Hinweis auf die wohl baldige Einführung des "Mobile first - Index".
.

Getting your site ready for mobile-first indexing

https://webmasters.googleblog.com/2017/12/getting-your-site-ready-for-mobile.html

Der Beitrag vom letzten Jahr: Mobile-first Indexing

https://webmasters.googleblog.com/2016/11/mobile-first-indexing.html

.
Das Problem:

> To recap, currently our crawling, indexing, and ranking systems typically look at the desktop version of a page's content, which may cause issues for mobile searchers when that version is vastly different from the mobile version.

Das Crawling, Indexieren und Ranken prüft die Desktop-Version. Aber oft gibt es spezielle mobile Seiten, die deutlich abgespeckt sind. Dann klickt der Nutzer ein solches "Desktop-Ergebnis" an. Die Website leitet den Nutzer auf die mobile Seite weiter. Und dort finden sich womöglich deutlich weniger Informationen. Oder die Informationen sind kaum lesbar (Schrift zu klein, kein Viewport), sie laufen rechts über, Formulare hängen rechts über usw.

Die Logik des "Mobile first - Index" dagegen:

> Mobile-first indexing means that we'll use the mobile version of the content for indexing and ranking, to better help our – primarily mobile – users find what they're looking for.

Zur Einschätzung einer einzelnen Seite wird die mobile Version des Contents herangezogen. Nicht die möglicherweise größere und reichhaltigere Desktop-Version. Die Wirkung: Der Nutzer, der mobil sucht, findet auf der Seite auch das, was ihm im Suchergebnis angezeigt wurde. Weil er gar nicht auf die Desktop-Version geschickt und von dort zur mobilen Version weitergeleitet wird, sondern sofort die Daten der mobilen Variante sieht.

Eine direkte Wirkung: Der Smartphone-Googlebot

https://support.google.com/webmasters/answer/1061943

> Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

spidert sehr viel häufiger. Und die Seiten, die im Google-Cache angezeigt werden, zeigen nicht mehr die Desktop-, sondern die mobile Variante.

Was ist zu tun?

Unproblematisch ist das für alle Websites, die bereits responsives Webdesign nutzen. Das heißt: Ein Inhalt ist nur unter einer Adresse verfügbar. Die Darstellung paßt sich der Breite des Browsers an. Bei einem breiten Browserfenster (bsp. ab 1000 Pixeln) kann der Content zwei- und dreispaltig erscheinen. Bei einem schmaleren Browserfenster (bsp. weniger als 600 Pixel) rutschen die Blöcke von rechts nach unten, so daß der Nutzer lediglich nach unten scrollen muß. Er kann aber alle Inhalte finden. Wenn es keine breiten Tabellen gibt, muß der Leser niemals nach rechts scrollen.

Wenn Sie den hiesigen Blog als Beispiel nehmen: Wenn Sie hier einen einzelnen Beitrag aufrufen und das Desktop-Fenster schmaler machen. Dann springt die Leiste rechts bei einer Breite kleiner als 680 Pixeln nach unten unterhalb des Beitrags. Der Beitrag selbst wird einfach schmaler. Die Liste mit den zehn neuesten Beiträgen kann unten durchgesehen und angeklickt werden. Ebenso stehen dort die Links zu den weiteren Kategorisierungen zur Verfügung.

Haben Sie einen einzelnen Begriff aufgerufen und machen Sie das Browserfenster schmaler, dann rutscht die graue Leiste rechts ebenfalls nach unten. Zusätzlich wird aus der Links-Rechts-Anordnung Datum - Beiträge eine Oben-Unten-Anordnung: Das Datum steht über dem Beitrag, so daß für den Beitragstitel und die Schlagworte der ganze Platz in der Breite zur Verfügung steht.

Technisch steckt da nicht allzuviel dahinter. Man sortiert die Inhalte in ein Parent-Div (der gesamte Inhalt nach dem Header mit Klasse row-container) und zwei Div-Elemente (der eine für den Inhalt, der andere für die rechte Seitenleiste). Legt man nichts sonst fest, stehen diese beiden Container untereinander. Man startet also mit der mobilen Ansicht. Dann genügt eine media Query:

> @media(min-width:680px) { }

mit einem Inhalt:

> .row-container { display:flex }

Das sorgt bereits dafür, daß die beiden Container ab einer Mindestbreite von 680 Pixeln nebeneinanderstehen. Ferner dürfen Objekte keine festen Breiten (width:400px), sondern nur maximale Breiten (max-width:400px) haben. In manchen Fällen ist noch eine Anweisung width:100% notwendig, damit der ganze Platz genutzt wird. Das sorgt dafür, daß Eingabefelder oder eine Kommentarbox beim Verkleinern des Fensters mitschrumpfen und nicht überhängen.

Ferner sollten die Schriftgrößen nur relativ sein, nicht absolut. Am besten mit font-size:1em die "normale Schriftgröße" auswählen. Statt fixierter Höhe (height:60px) nimmt man min-height:60px. Das sorgt dafür, daß bei einem schmalen Bildschirm das Objekt in der Höhe vergrößert werden kann, so daß der Text im Objekt bleibt.

Schließlich sorgt eine einzige Anweisung

> <meta name="viewport" content="width=device-width, inital-scale=1.0" />

dafür, daß der Browser die Breite des Geräts berücksichtigt und nicht beim Erstaufruf die Darstellung so sehr verkleinert, daß nichts mehr lesbar ist.

Ergebnis (aus dem ersten Link):

> As we said, sites that make use of responsive web design and correctly implement dynamic serving (that include all of the desktop content and markup) generally don't have to do anything.

Websites, die responsives Webdesign nutzen und die korrekt dynamische Bereitstellung nutzen, müssen nichts tun. Nur: Was ist "dynamische Bereitstellung"?

Dynamische Bereitstellung

https://developers.google.com/search/mobile-sites/mobile-seo/dynamic-serving

> Bei der dynamischen Bereitstellung übermittelt der Server unter derselben URL unterschiedlichen HTML- und CSS-Code. Der verwendete Code hängt davon ab, welcher User-Agent die Seite angefordert hat.

Sprich: Wer korrekt implementiertes responsives Webdesign nutzt, der braucht gar keine "dynamische Bereitstellung". Persönlich würde ich davon ebenso wie von gesonderten mobilen Versionen auch abraten. Denn die Erkennung von User-Agents (User-Agent-Sniffing) ist ziemlich heikel. Die Zeit steckt man lieber in ein responsives Webdesign. Mit diesem existiert das Problem nicht: Alle Nutzer haben dieselbe Adresse und sehen denselben Inhalt. Die Darstellung paßt sich dem Gerät an.

Wer dagegen zwei Urls nutzt (bsp. www.example.com versus mobil.example.com), der muß alle Inhalte doppelt bereitstellen. Es sollte ein Canonical Element geben, die beiden Seiten sollten per link rel=canonical und link rel=alternate aufeinander verweisen. Das alles erhöht die Zahl möglicher Fehler deutlich, so daß Content womöglich doppelt im Index auftaucht oder daß Nutzer mit fehlerhaften Weiterleitungen von der Desktop- zur mobilen Version zur Verzweiflung getrieben werden.

Persönlich würde ich mir deshalb die Mühe mit einer solchen doppelten Bereitstellung niemals machen. Egal, ob man das unter derselben Adresse (dynamische Bereitstellung) oder unter zwei verschiedenen Subdomains macht.

Ansonsten gibt es von Google verschiedene Testmöglichkeiten. Zuallererst die Search Console ( unter https://www.google.com/webmasters/ erreichbar ). In die man seine Websites einträgt. Dort gibt es genaue Hinweise, welche Seiten noch nicht mobil ready sind. Dort kann man ebenfalls prüfen, ob der Googlebot CSS- und JavaScript-Dateien spidern darf.

Fallen dort Seiten auf, gibt es den auch direkt zugänglichen Mobile-Test:

https://search.google.com/test/mobile-friendly

Dort werden die Punkte (Viewport definiert, Schrift ausreichend groß, keine überhängenden Breiten, klickbare Elemente nicht zu nah beieinander) geprüft. Ferner gibt es eine Bildschirmansicht, wie die Seite auf einem mobilen Gerät aussieht.

Wer übrigens noch immer der Meinung ist, daß er per mobiler Nutzung keine Interessenten erhält. Bei einem dieser Google-Texte gab es einen interessanten Hinweis: 70 Prozent der mobilen Suchen kämen aus Büros und Privatwohnungen. Bei denen man davon ausgehen kann, daß Desktop-Rechner in der Nähe sind.

Sprich: Nutzer suchen mobil. Finden sie dort interessante Sachen, dann greifen sie das am Desktop auf.

Früher hieß es: Wer nicht in Google auftaucht, ist unsichtbar. Aus diesen anstehenden Änderungen ergibt sich: Wer nicht im mobilen Index auftaucht (etwa, weil die Seite zwar am Desktop schick aussieht, aber mobil nicht nutzbar ist und deshalb im zukünftig mobilen Index nach hinten rutscht), der ist unsichtbar.

*
* (wird nicht angezeigt)
Die Erläuterungen zum Datenschutz habe ich gelesen und stimme diesen zu.