One Pager SEO Blueprint

Was ist ein Onepager?

Ein One Pager – oft auch als Squeeze Page, Long Page, Single Page oder Standalone Landingpage bezeichnet – ist ein ein Designformat, bei dem alle Informationen einer Webseite auf einer einzelnen Seite zu finden sind. Der User navigiert durch Scrollen anstelle von Klicken.

one-pager-old-timey
Onepager: Ein bewährtes Modell

Für SEO entstehen dadurch folgende Probleme:

  • Eine URL muss für alle Themen Keywords ranken
  • Keyword Targeting mit dem Title Tag ist praktisch unmöglich, da sich alle Bereiche einen einzigen Title Tag teilen
  • User, die über ein Suchresultat auf die Seite gelangen, landen stets am Anfang der Seite, anstatt auf dem relevanten Bereich, der möglicherweise in der Mitte der Seite zu finden ist
  • Links und Social Shares führen stets zum Anfang der Seite und nicht zum relevanten Abschnitt der Seite

Auch Matt Cutts sieht potentielle Probleme mit dem One Pager Modell:

Um diese Probleme zu lösen, sollte jeder Abschnitt des Onepagers auf einer eigenen URL zu finden sein. Für den User muss der gesamte Inhalt weiterhin auf einer einzelnen Seite präsentiert werden, während Suchmaschinen SEO optimierte Landingpages inklusive Title Tags vorfinden, die dann für die Ziel Keywords ranken können.

AJAX + HTML5 History API = Best Friends Forever

Um das Problem mit den URLs zu lösen, erstellen wir zunächst eine gewöhnliche Seite mit Landingpages, Title Tags und Navigation. Der Content der einzelnen Seiten wird dann via AJAX in einen Onepager zusammengeführt. Mit Hilfe der – seit HTML5 verfügbaren – Browser History API, können wir beim Scrollen den Status der Adresszeile verändern, so dass Shares und Links immer auf die relevante Sektion zeigen. Anschließend brauchen wir nur noch eine Funktion, die den User zur relevanten Sektion der Seite scrollt abhängig von der URL über die ein User auf die Seite gelangt.

Ein großer Vorteil dieser Lösung ist, dass jedes beliebige CMS dazu verwendet werden kann. Zusätzlich werden Sektionen als getrennte Seiten behandelt, was das Content Management erheblich erleichtert.

Onepager Struktur

Der Ajax Script

Um die einzelnen Unterseiten in einen Onepager zusammenzufügen, können wir Ajax verwenden. Dazu ist es am besten, die Navigation der statischen Seite zu “ajaxifizieren”. Das Script sollte durch jeden Menüpunkt in der Navigation iterieren und den Content auf der URL entnehmen, um ihn auf der aktuellen Seite zu inkludieren. Dadurch bleibt die Seite wartbar und es können neue Seiten hinzugefügt werden, ohne das Script anpassen zu müssen. Jede Unterseite wird dann clientseitig als Sektion in den Onepager eingefügt.

Beachten:

  • Die Reihenfolge der Sektionen sollte der Reihenfolge der Links in der Navigation entsprechen
  • Nur der Content Teil der Seiten sollte inkludiert werden, nicht Navigation, Footer oder andere Template Elemente (auch nicht die HEAD Section)
  • Das Script sollte auf jeder Seite laufen
  • Die URLs sollten auch in der Sitemap wiedergegeben werden

Der History API Script

Der History API Script erfüllt zwei Funktionen:

  1. User die auf die Seite landen werden zur relevanten Sektion gescrollt
  2. Wenn ein User zur einer Sektion scrollt, wird ein neuer Eintrag in die Browserhistory eingetragen und die Adresszeile zeigt die URL der aktuellen Sektion an. Der Backbutton sollte dann den User zur vorherigen Sektion scrollen.

So sollte das ganze funktionieren:

Die Scrollposition ist auf 0. Der User befindet sich auf der ersten Sektion, entsprechend wird in der Adressleiste des Browsers seite1.html angezeigt:

Wenn der User zur zweiten Sektion scrollt ändert sich auch die URL in der Adresszeile:

Beachten:

  • Der History Stack des Browsers muss durch einen speziellen Skript gemanaged werden um unvorhergesehenes Verhalten bei Back Button Navigation zu vermeiden. Das Anklicken des Back Buttons sollte nicht in einen neuen Eintrag in die History resultieren.
  • Ein User, der über eine bestimmte URL auf die Seite gelangt, sollte zur jeweiligen Sektion hingescrollt werden.
  • Die URLs sollten nicht mit Hashtags umgesetzt werden, da Google diese ignoriert (wofür brauchen wir sonst die history api?!)

Die Navigation

Sowohl für Google als auch für die Ajaxifizierung ist eine statische Navigation, die unsere optimierten Unterseiten verlinkt, wichtig. Je nach Design könnte die Navigation allerdings nicht erwünscht sein.

Wenn die Navigation nicht erwünscht ist

Wenn die Navigation nicht erwünscht ist, sollte diese durch Javascript aus dem DOM entfernt werden, jedoch weiterhin im Quellcode verfügbar sein. Verstecken mit CSS wäre auch eine Option, die meiner Meinung nach allerdings riskanter wäre, da Google dieses Vorgehen als manipulativ einstufen könnte.

Wenn die Navigation erwünscht ist

Falls die Navigation vorhanden bleiben soll, muss das Default-Verhalten der Links ausgehebelt werden. Wenn ein User einen Link anklickt, sollte keine neue Seite geladen werden, sondern stattdessen zu der jeweiligen Position der Ziel Sektion gescrollt werden.

Beachten:

  • Links in der Navigation sollten wie alle gewöhnlichen Links implementiert werden
  • Die Sektionen sollten eigene “normale” URLs haben (keine Hashtags)
  • Links sollten am besten den vollen Pfad enthalten

Alternative Anwendungen

Diese Methode eignet sich auch hervorragend für andere moderne User Interfaces, die aus SEO Sicht problematisch sein können:

  • Tabs
  • Accordions
  • Webapps
  • Lightboxes
  • Lazyloading
  • Infinite Scrolling

Hinterlassen Sie einen Kommentar:

8 Kommentare zu “One Pager SEO Blueprint

  • Hallo Boyan,
    toller Artikel der mich sehr interessiert. Könntest du noch einige Infos zur technischen Umsetzung, also wie das mit Ajax funktioniert und wie die History API zu bedienen ist ?
    Danke !!

    Gruß
    Michi

  • Hallo Michi,

    Für die AJAX Sachen bietet sich die Funktion load(); (in jQuery) an zb so: $( “#content” ).load( “ajax/test.html #content” );

    Die URL sollte dabei eine Variable sein, deren Wert du dir aus der Navi holst, sprich du solltest alle Navi Links iterieren, die URL aus dem href Attribut herausholen, die load Funktion Bauen, das Content HTML aus den einzelnen Seiten holen und an der richtigen Stelle appenden.

    Das mit der Reihenfolge kannst du dir bei diesem DEMO mal anschauen: http://jsfiddle.net/j6yUd/.

    Was History API betrifft, ist das eigentlich eine kosmetische Maßnahme, um die URL während dem Scrollen zu verändern. Relevant hier sind die pushState() und onpopstate hier ein guide dazu: https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Manipulating_the_browser_history.

    Simplifiziert, jedes mal wenn der User die Scroll Position einer neuen Section erreicht, wird ein neuer Eintrag in seine History injektiert und die URL in der Adressleiste verändert sich (pushstate). Um kein history Chaos zu erzeugen bräuchtest du allerdings einen etwas ausgefeilteren history managent Script.

    Für die history api gibt es auch einige Frameworks: pijax.js, history.js und bbq.js (wenn ich mich nicht täusche).

    Bei dieser Lösung ist die Sache mit History API mit Abstand das schwierigste, während der AJAX Script relativ einfach ist. Ich hoffe das bringt dich weiter! Bei Gelegenheit werde ich mal ein richtiges Beispiel mit Code posten.

  • Hallo Boyan,
    super interessanter Artikel, auch wenn ich nicht alles verstehe (aber unsere Entwicklungsabteilung ;-)). Gibt es auch eine Möglichkeit, wie man sowas mit einem WordPress-Theme umsetzen kann? Die Entwickler meinen, dass deine hier beschriebene Variante mit einem vorgefertigten WordPress-Template nicht funktioniert. Für Tipps bin ich dir dankbar.

    Viele Grüße,
    Marcus

  • Hallo Marcus,

    Welches Theme du verwendest ist hier irrelevant, denn die ganze Lösung funktioniert über Javascript. Es ist sogar größtenteils irrelevant welches CMS du verwendest.

    Jede Seite hat im Prinzip eine Navigation mit Unterseiten, auf denen der Content zu finden ist. Mit dieser Lösung machst du dir genau diesen Umstand zu Nutze, denn der Script holt sich die Inhalte der einzelnen Unterseiten (indem der script durch die Navi Links iteriert) und integriert sie auf einer einzelnen Seite (onepager). Diese einzelne Seite ist jede beliebige Einstiegsseite auf der der Script zu finden ist.

    Solange deine Entwicklungsabteilung in der Lage ist basic javascript zu schreiben sollte das hinhauen.

    Diese Lösung gibt es natürlich nicht vorgefertigt, aber deshalb gibt es ja Entwicklungsabteilungen.

    Ansonsten ruf mich einfach mal an, wenn es ein größeres Projekt ist kann ich das deinen Programmierern step-by-step erklären.

    Oder frag hier 😉

    vg,
    Boyan

  • Hallo,
    sehr guter Artikel. Nach diesem Ansatz setze ich meine Themes für WordPress gerade auch um. Du schreibst ja dass das Script auf jeder Seite laufen soll. Das ist auch sinnvoll, da sonst die Besucher die über Google kommen nur die indizierte Sektion sehen. Ich bin jemand der gerne noch Fallbacks für No-Skript User einbaut. In diesem Fall, würde der User nur die Sektion angezeigt bekommen mit Header und Footer. Dadurch ist es keine OnePage mehr, aber immerhin noch eine ordentliche Seite.

    Ich hatte vorher bei jedem Seitenzugriff das ganze per PHP aufbauen lassen. Das war natürlich nicht sinnvoll, weil Google so immer den Content der gesamten Page enthält. Ich schätze mal das wird dann als Duplicate Content angesehen?

    Mir stellt sich aber nach folgendem Blogartikel (http://googlewebmastercentral.blogspot.ca/2014/05/understanding-web-pages-better.html) in dem Google beschreibt, dass JavaScript nun mehr oder weniger von den Crawlern “lesbar” ist, wie lange dieser Ansatz den du hier beschreibst, noch bestand hat?

    Denn sobald Google es “schafft” den Ajax Code auszuführen und erst alle Selektionen damit lädt und erst dann crawlt, besteht das gleiche Problem, wie oben beschrieben (siehe oben meinen Teil über PHP).

    Wie siehst Du das?

    Grüße und danke für den Aritkel!

  • Hi Tobias,

    Danke für dein tiefgründiges Kommentar 🙂

    Generell kannst du dein Script extern laden und in robots.txt blockieren, um auf Nummer sicher zu gehen, dass Google keinen Mist baut. Ich würde mich aber nicht darauf verlassen, dass Google nun Javascript immer versteht und richtig interpretiert. Das Problem ist, dass Google nur einen ganz kleinen Teil von JS ausführen kann. Google ist noch lange nicht in der Lage tatsächlich Javascript oder gar Ajax zu “verstehen”. Daher gibt es ja auch die Anleitung von Google wie man Ajax crawlbar macht durch HTML Snapshots: https://developers.google.com/webmasters/ajax-crawling/docs/getting-started?hl=de

    Ist so ähnlich wie mein Ansatz, nur dass es viel komplizierter ist.

    Noch ein Tipp: Wenn du deinen One Pager fertig hast und WMT eingerichtet ist, kannst du über das Feature “render as Google” sehen, wie Google deine Seite tatsächlich sieht, sprich welche ressourcen wirklich geladen und wie verarbeitet werden.

    Um deine Frage zu beantworten, ich denke es wird noch viele Jahre dauern, bis Google-bot so weit ist das gesamte JS und HTML5 richtig und ohne Hilfe ausführen zu können (und zu wollen).

  • Hallo Boyan,
    interessanter Artikel. Könntest du noch ein Beispiel Sourcecode bereitstellen (oder ein Link)?.
    Ich check das mit dem Ajax nachladen nicht ohne Beispiel.
    Danke !!

    Gruß
    Harry