Responsiv oder eine eigene Handy-Version?

Ein eigener smartphone-optimierter Ast der Website kann aus mehreren Gründen sinnvoller sein, als eine durchgängig Responsive Website. Einige dieser Gründe:

Das Design ist schwierig zu übersetzen

Oft müsste man wesentlich in das Erscheinungsbild eingreifen, wenn es sowohl für PC als auch für Handys geeignet sein soll. Speziell ältere Websites können oft nicht mit vertretbarem Aufwand geändert werden.
Natürlich: Wir haben Computer – alles geht! Aber gerade bei „liebevoll gestalteten“ Seiten, oft mit MS-Word Unterstützung ;-) geht es nicht ohne Änderungen daran. Damit kann man sich ordentlich Feinde machen...

Sehr häufig sind Bilder auch zu klein und können nicht mehr größer beschafft werden. Das klingt zunächst paradox, weil ja Handys kleine Bildschirme haben, in der Praxis schränkt es aber die Möglichkeiten der Gestaltung sehr ein.

Inhaltliche Gründe

Man muss sich zunächst fragen: Was bezweckt man, wen will man wie erreichen?

Nehmen wir zb eine Apotheke. Üblicherweise geht man zu einer, die in der Nähe des Wohnortes ist – schlichtweg weil man im Krankheitsfall nicht ewig durch die Gegend fahren will. Ein typischer Grund, warum jemand am Handy nach einem Ort in der Nähe sucht. Hier hilft auch Google mit, wenn man die nötigen Geo-Tags auf der Site hat.

Andererseits wird eine Apotheke vielleicht recht umfangreiche Informationen auf der Website anbieten, die nicht unbedingt für einen akuten Fall wichtig sind: Produkte, Gesundheitsthemen... das sucht man nicht häufig am Handy und längere Texte werden da auch kaum gelesen.
Aber: Gerade solche Inhalte sind es, die das Ranking in Google sehr positiv beeinflussen können.

Ähnliche Denkansätze gibt es für viele Fälle, das muss von Fall zu Fall entschieden werden. Kommen jetzt noch andere Gründe dazu, kann es besser sein, die Inhalte zu trennen: Schnelle Info fürs Handy (ganz oben die Adresse!), erweiterte Inhalte für den PC und das Tablet.

Strategien

Wenn möglich sollten beide Versionen responsiv sein – nur eben Mobile-First / Desktop-First. Dann kann man sich die Handy-Weiche sparen und auf der Desktop-Version einen großen Link zu Handy-Version anbringen.

Inhaltliche Doppelgleisigkeiten sollte man weitestgehend vermeiden. Natürlich ist es mit modernen CMS leicht möglich, große Inhaltsbereiche in beiden Version anzuzeigen; zb bieten sich hier News an. Diese müssen aber per Canonical-Tag gekennzeichnet werden, was aber wieder den Grundgedanken etwas aushebelt.

Die Weiche

Es gibt sehr viele einschlägige Scripte im Web. Grundsätzlich sollte man automatische Weiterleitungen vermeiden, die den „Willen des Users“ ignorieren. Man muss zumindest von der Smartphone-Version sauber auf die Desktop-Version kommen können. Um den User-Wunsch zu speichern, sind Cookies nötig, die sich auch für serverseitige Weichen per PHP eignen. Praktischer ist localStorage per Javascript. JS-Weiterleitungen sollte man vermeiden, aber ein großer Link-Button zur Handy-Version lässt sich damit gut einblenden.

Generell am besten sind Weichen, die nicht die Gerätetypen abfragen, sondern auf die tatsächliche Auflösung achten und eventuell beim ersten Besuch das Ziel entscheiden, die weitere Entscheidung aber dem User überlassen. Das Problem beim Abfragen der Gerätetypen ist, dass es viele Ausnahmen gibt und sich diese auch laufend ändern. Bei einer Bildschirmbreite von > 1024 Pixel kann man mit Sicherheit von einem PC-artigen Gerät ausgehen – auch wenn es ein Tablet ist. Alles darunter wird wohl mit der Handy-Version gut bedient sein.

In jedem Fall

sollte man im Auge behalten, dass Google selbst entscheidet, auf welche Seite man bei einer Suche geschickt wird. Das sollte man nicht aushebeln. Wenn jemand nach zb „Johanniskraut“ gesucht hat, will er - auch am Handy! - ein relevantes Ergebnis sehen. Google weiß selbst, dass der User ein Smartphone benutzt und wird eine Website, die in der Nähe verortet ist, besser listen. Wenn der User in der Desktop-Version landet, soll er schnell die Adresse in geeigneter Form finden können. Eine brachiale Weiterleitung ist kontraproduktiv.