Mittwoch, 09. November 2016
Für progressive Web-Apps (PWAs) werden neue Technologien eingesetzt, um die Vorteile mobiler Websites und nativer Apps für Nutzer miteinander zu verbinden. Sie sind eine der spannendsten neuen Ideen im Web. Aber um sich wirklich abzuheben, müssen sie indexierbar und verknüpfbar sein. Jede Empfehlung in diesem Artikel beruht auf einer Best Practice für Indexierbarkeit – unabhängig davon, ob ihr eine progressive Web-App oder eine einfache statische Website erstellt. Diese Best Practices haben wir für euch zusammengefasst, damit ihr sie in Form einer Checkliste abhaken könnt.
Inhalte für Crawler zugänglich machen
Warum? In der Vergangenheit wurde der HTML-Code immer auf dem Server generiert oder gerendert, da so am einfachsten eine direkte Verknüpfung der Inhalte erreicht werden konnte. Dem Konzept des clientseitigen Renderns verhalfen dann Web-Apps zum Durchbruch. Beim clientseitigen Rendern werden die Inhalte während des Aufenthalts der Nutzer auf der Seite dynamisch aktualisiert, ohne dass ein erneutes Laden erforderlich ist.
Die demgegenüber neuere Methode ist das Hybridrendern. Hierbei wird serverseitig gerendert, wenn der Nutzer eine URL direkt aufruft. Nach dem ersten Seitenaufbau wird bei weiteren Navigationsschritten und asynchronen Anforderungen clientseitig gerendert.
Unser Beispiel einer serverseitigen PWA zeigt reines serverseitiges Rendern. Bei unserem Hybridbeispiel einer PWA könnt ihr hingegen beide Ansätze in Aktion sehen.
Falls euch die Begriffe des serverseitigen und clientseitigen Renderns noch nicht vertraut sind, lest diese Artikel über client- und serverseitiges Rendering und serverseitiges Rendering in React und Node.js.
Best Practices
Setzt serverseitiges oder Hybridrendern ein, damit die Inhalte in den ersten Nutzdaten für die Webanforderung des Nutzers bereitgestellt werden.
Stellt sicher, dass auf URLs unabhängig voneinander zugegriffen werden kann:
https://www.example.com/product/25/
Die URL enthält einen Deep-Link zur entsprechenden Ressource.
Wenn ihr für eure progressive Web-App kein serverseitiges oder Hybridrendern unterstützen könnt und ihr euch für das clientseitige Rendering entscheidet, empfehlen wir euch, mit dem Google Search Console-Tool „Abruf wie durch Google“ zu prüfen, ob eure Inhalte so gerendert werden, dass sie unser Such-Crawler verarbeiten kann.
Leitet Nutzer, die auf Deep-Links zugreifen, nicht zurück zur Startseite eurer Web-App.
Außerdem sollte anstelle von Deep-Links keine Fehlerseite angezeigt werden.
Saubere URLs bereitstellen
Warum? Fragmentbezeichner (#user/24601/ oder #!user/24601/) waren eine gute Behelfslösung, damit Browser mit der AJAX-Technologie auf neue Inhalte auf einem Server zugreifen konnten, ohne die Seite neu laden zu müssen.
Diese Methode wird als clientseitiges Rendern bezeichnet.
Die Syntax von Fragmentbezeichnern ist jedoch nicht mit allen Webtools, Frameworks und Protokollen wie dem Open-Graph-Protokoll von Facebook kompatibel.
Mit der History API können wir die URL ohne Fragmentbezeichner aktualisieren und dabei asynchron Ressourcen abrufen. So muss die Seite nicht neu geladen werden und die Vorteile beider Methoden lassen sich vereinen. Das AJAX-Crawlingschema mit seinen Fragment-URLs mit Escape-Code (#!) war damals sinnvoll, wird aber heute nicht mehr empfohlen.
Für unser Hybridbeispiel einer PWA und unserem Beispiel einer clientseitigen PWA wird die History API verwendet.
Best Practices
Stellt saubere URLs ohne Fragmentbezeichner (# oder #!) bereit. Zum Beispiel:
https://www.example.com/product/25/
Wenn ihr clientseitiges oder Hybridrendern einsetzt, muss die Browsernavigation mit der History API unterstützt werden.
Zu vermeiden
Von der Verwendung von #! zum Erstellen eindeutiger URLs wird abgeraten:
https://www.example.com/#!product/25/Diese Methode wurde vor Einführung der History API als Behelfslösung eingeführt. Sie unterscheidet sich von der URL-Struktur, bei der nur # verwendet wird.
Die Verwendung von # ohne das Symbol ! wird nicht unterstützt:
https://www.beispiel.de/#produkt/25/
Diese URL-Struktur ist bereits ein Konzept im Web. Gemeint ist damit die Verwendung von Deep-Links zur Verknüpfung mit Inhalten auf einer bestimmten Webseite.
Kanonische URLs angeben
Warum? Wenn dieselben Inhalte unter verschiedenen URLs (ob in derselben oder in verschiedenen Domains) verfügbar sind, lassen sich Unklarheiten bei der Indexierung am besten vermeiden, indem eine Seite als kanonische URL markiert wird. Das bedeutet: Alle anderen Seiten duplizieren die betreffenden Inhalte und verweisen darauf.
Best Practices
Fügt die folgenden Tags für alle Seiten ein, die bestimmte Inhalte spiegeln:
<link rel="canonical" href="https://www.example.com/your-url/" />
Falls ihr Accelerated Mobile Pages unterstützt, müsst ihr auch die zugehörige Anweisung rel="amphtml" richtig einsetzen.
Zu vermeiden
Vermeidet das absichtliche Duplizieren von Inhalten auf mehreren URLs ohne Verwendung des Link-Elements rel="canonical".
Mit dem Link-Element rel="canonical" kann beispielsweise die Doppeldeutigkeit von URLs mit Tracking-Parametern reduziert werden.
Versucht, keine in Konflikt stehenden kanonischen Verweise zwischen euren Seiten zu erstellen.
Für verschiedene Geräte entwickeln
Warum? Ihr solltet für eine bestmögliche Nutzung eurer Website sorgen – und zwar für alle Nutzer und unabhängig vom jeweiligen Gerät.
Erstellt eine responsive Website – Schriftarten, Außen- und Innenabstände, Schaltflächen und das allgemeine Design eurer Website sollten dynamisch an die Bildschirmauflösung und die entsprechenden Darstellungsbereiche angepasst werden.
Bilder in niedriger Auflösung, die für Desktop-Computer oder Tablets vergrößert werden, sehen einfach nicht gut aus. Andererseits dauert es lange, bis hochauflösende Bilder auf Smartphones heruntergeladen sind, und auch das Scrollen auf Mobilgeräten kann durch solche Bilder beeinträchtigt werden.
Weitere Informationen zur Nutzerfreundlichkeit von PWAs
Best Practices
Verwendet das Attribut srcset, um Bilder mit unterschiedlicher Auflösung für Bildschirme mit unterschiedlicher Dichte abzurufen. So lässt sich vermeiden, dass Bilder heruntergeladen werden, die größer als der Bildschirm des Geräts sind.
Skaliert die Schriftgröße und Zeilenhöhe so, dass der Text unabhängig von der Größe des Geräts gut lesbar ist. Auch der Abstand und die Ränder von Elementen sollten sich gut skalieren lassen.
Testet verschiedene Bildschirmauflösungen mithilfe der Funktion „Gerätemodus“ des Chrome-Entwicklertools und des Tools zum Test auf Optimierung für Mobilgeräte.
Zeigt den Nutzern keine anderen Inhalte als ihr Google zeigt. Wenn ihr Weiterleitungen oder die User-Agent-Erkennung (auch Browser-Sniffing oder dynamische Bereitstellung genannt) verwendet, um das Design eurer Website an unterschiedliche Geräte anzupassen, muss der Inhalt an sich unverändert bleiben.
Mit dem Tool „Abruf wie durch Google“ der Search Console könnt ihr überprüfen, ob die von Google abgerufenen Inhalte mit den Inhalten übereinstimmen, die die Nutzer sehen.
Aus Gründen der Nutzerfreundlichkeit solltet ihr keine Schriftarten mit fester Größe verwenden.
Iterativ entwickeln
Warum? Eine der sichersten Methoden, um Webanwendungen Funktionen hinzuzufügen, sind iterative Änderungen. Wenn ihr die Funktionen einzeln hinzufügt, könnt ihr die jeweiligen Auswirkungen gezielt beobachten.
Viele Entwickler sehen PWAs jedoch auch als Möglichkeit, ihre mobile Website auf einen Schlag zu überholen. Sie entwickeln die Web-App dazu in einer isolierten Umgebung und wechseln sie nach dem Fertigstellen gegen die bestehende mobile Website aus.
Bei der iterativen Entwicklung von Funktionen solltet ihr die Änderungen in einzelne Komponenten zerlegen. Wenn ihr beispielsweise vorhabt, vom serverseitigen zum Hybridrendern zu wechseln, geht dies als einzelne Iteration an und fasst es nicht mit anderen Funktionen zusammen.
Beide Herangehensweisen haben Vor- und Nachteile. Bei der Iteration wird die Komplexität der Indexierung der Suche gesenkt, da die Verbesserungen laufend und in kleinen Schritten erfolgen. Das iterative Vorgehen kann die Entwicklung jedoch verlangsamen und die Innovation begrenzen, falls der Entwicklungsprozess nicht bei null beginnt.
Die wichtigsten Komponenten hierbei sind in jedem Fall die kanonischen URLs und die robots.txt-Konfiguration eurer Website.
Best Practices
Führt auf eurer Website schrittweise Iterationen durch, indem ihr neue Funktionen nacheinander hinzufügt.
Falls beispielsweise HTTPS noch nicht unterstützt wird, migriert zuerst zu einer sicheren Website.
Zu vermeiden
Wenn ihr eure progressive Web-App in einer isolierten Umgebung entwickelt habt, solltet ihr sie erst veröffentlichen, nachdem ihr geprüft habt, dass die rel-canonical-Links und die robots.txt-Datei richtig konfiguriert sind.
Eure rel-canonical-Links müssen auf die echte Website verweisen und die robots.txt-Konfiguration muss das Crawlen der Website zulassen.
Natürlich möchtet ihr während der Entwicklung verhindern, dass Crawler eure Website schon vor der Veröffentlichung indexieren. Vergesst vor dem Veröffentlichen jedoch nicht, Crawlern wieder Zugriff auf die neue Website zu gewähren.
Progressive Verbesserung verwenden
Warum? Wann immer möglich, sollten Browserfunktionen vor der Verwendung erkannt werden. Die Funktionserkennung ist außerdem besser, als Tests mit Browsern durchzuführen, die eurer Meinung nach eine bestimmte Funktion unterstützen.
In der Vergangenheit wurden Funktionen leider einfach aktiviert oder deaktiviert, indem man testete, welchen Browser der betreffende Nutzer verwendete. Da Browserfunktionen jedoch ständig weiterentwickelt werden, raten wir dringend von dieser Vorgehensweise ab.
Service Worker ist eine relativ neue Technologie. Dabei sollte der Fortschritt der Softwareentwicklung jedoch keinesfalls auf Kosten der Kompatibilität gehen – ein perfektes Beispiel für die Nutzung der progressiven Verbesserung.
Best Practices
Bevor ihr einen Service Worker registriert, solltet ihr prüfen, ob seine API verfügbar ist:
if ('serviceWorker' in navigator) {
...Nutzt die API-Erkennungsmethode für eure sämtlichen Websitefunktionen.
Verwendet nie den User-Agent des Browsers, um Funktionen in eurer Web-App zu aktivieren oder zu deaktivieren. Prüft immer, ob die API der Funktion verfügbar ist, und arbeitet mit gradueller Fehlertoleranz, falls dies nicht der Fall ist.
Aktualisiert oder veröffentlicht eure Website erst, nachdem ihr sie für mehrere Browser getestet habt. Seht in der Websiteanalyse nach, welche Browser bei euren Nutzern am beliebtesten sind.
Mit Search Console testen
Warum? Ihr solltet wissen, wie die Google Suche eure Website sieht. Ihr könnt die Search Console nutzen, um einzelne URLs von eurer Website abzurufen und zu ermitteln, wie die Google Suche diese sieht. Verwendet dazu die Funktion „Crawling“ > „Abruf wie durch Google“. Die Search Console verarbeitet euer JavaScript und rendert die Seite, wenn diese Option aktiviert ist. Ansonsten wird nur die Raw-HTML-Antwort angezeigt.
Die Google Search Console analysiert außerdem die Inhalte eurer Seite. Dabei kommen mehrere Methoden zum Einsatz, unter anderem die Erkennung von strukturierten Daten, Rich Cards, Sitelinks und Accelerated Mobile Pages.
Best Practices
Überwacht eure Seite mit der Search Console und macht euch mit ihren Funktionen wie beispielsweise „Abruf wie durch Google“ vertraut.
Stellt in der Search Console eine Sitemap über Crawling > Sitemaps bereit. Das kann eine effektive Methode sein, damit die Google Suche alle Seiten eurer Website findet.
Mit strukturierten schema.org-Daten kommentieren
Warum? Strukturierte schema.org-Daten stellen ein flexibles Vokabular für die Zusammenfassung der wichtigsten Bereiche einer Seite als maschinenlesbare Daten dar. Dazu müsst ihr etwa lediglich angeben, dass es sich bei den Daten einer Seite um den schema.org-Datentyp NewsArticle handelt, oder ihr gebt detailliert die Zutaten und Zubereitungsschritte eines Rezepts bzw. den Ort, Bandnamen, Veranstaltungsort und Ticketverkäufer für eine tourende Band an.
Die Nutzung von Metadaten bietet sich nicht für jede Seite eurer Web-App an, wird jedoch dort empfohlen, wo sie sinnvoll ist. Google extrahiert diese Daten, nachdem die Seite gerendert wurde.
Es gibt verschiedene Datentypen, z. B. NewsArticle, Recipe und Product. Hier findet ihr alle unterstützten Datentypen.
Best Practices
Überprüft mit dem Testtool für strukturierte Daten von Google, ob eure schema.org-Metadaten korrekt sind.
Prüft, ob die von euch bereitgestellten Daten angezeigt werden, und überzeugt euch davon, dass keine Fehler vorhanden sind.
Verwendet keine Datentypen, die nicht dem Inhalt eurer Seite entsprechen. Nutzt beispielsweise nicht Recipe, wenn ihr T-Shirts verkauft, sondern Product.
Mit Open Graph oder Twitter Cards kommentieren
Warum? Es ist unter Umständen auch sinnvoll, zusätzlich zu den schema.org-Metadaten das Open-Graph-Protokoll von Facebook und Rich Cards von Twitter zu unterstützen.
Mit diesen Metadatenformaten verbessert ihr die Abläufe beim Teilen von Inhalten in den entsprechenden sozialen Netzwerken.
Wenn ihr diese Formate für eure bestehende Website oder Web-App verwendet, solltet ihr aus Gründen der Viralität die Formate auch in eurer progressiven Web-App nutzen.
Best Practices
Testet euer Open-Graph-Markup mit dem Object Debugger Tool von Facebook.
Macht euch mit dem Metadatenformat von Twitter vertraut.
Vergesst nicht, diese Formate auf eurer bestehenden Website einzufügen, sofern sie dort unterstützt werden.
Mit mehreren Browsern testen
Warum? Aus Sicht der Nutzer ist es natürlich wichtig, dass eine Website auf allen Browsern gleichartig funktioniert. Selbst wenn Anpassungen für verschiedene Bildschirmgrößen vorgenommen werden, erwarten wir, dass sich eine mobile Website auf Geräten ähnlicher Größe gleich verhält, unabhängig davon, ob es sich um ein iPhone oder ein Android-Smartphone handelt.
Auch wenn das Web aufgrund der verschiedenen Browser, die weltweit im Einsatz sind, fragmentiert erscheinen kann, machen ja genau diese Vielfalt und dieser Wettbewerb das Internet zu solch einer innovativen Plattform. Glücklicherweise waren die Webstandards noch nie so ausgereift wie heute. Außerdem können Entwickler mit den verfügbaren modernen Tools problemlos umfangreiche Websites erstellen, die mit allen Browsern kompatibel sind.
Best Practices
Setzt browserübergreifende Testtools wie BrowserStack.com, Browserling.com oder BrowserShots.org ein, um zu prüfen, ob eure PWA mit mehreren Browsern kompatibel ist.
Seitenladezeiten messen
Warum? Je schneller eine Website lädt, desto besser lässt sie sich nutzen. Die Optimierung der Ladezeiten ist bereits ein bekannter Schwerpunkt der Webentwicklung, manchmal wird ihr beim Erstellen einer neuen Version einer Website jedoch nicht ausreichend Priorität eingeräumt.
Beim Entwickeln einer progressiven Web-App solltet ihr die Seitenladegeschwindigkeit messen und optimieren, bevor ihr die Website veröffentlicht.
Best Practices
Verwendet Tools wie Page Speed Insights und Web Page Test, um die Seitenladegeschwindigkeit eurer Website zu messen. Auch wenn der Googlebot beim Rendern relativ geduldig ist, zeigen einschlägige Studien, dass 40 % der Nutzer eine Seite verlassen, wenn diese länger als drei Sekunden lädt.
Nehmt Optimierungen nicht erst nach der Veröffentlichung vor. Wenn die Inhalte eurer Website vor der Migration zu einer neuen progressiven Web-App schnell laden, dürft ihr bei den Optimierungen keinesfalls Abstriche machen.
Wir hoffen, dass ihr diese Checkliste nützlich findet und bei der Entwicklung eurer progressiven Web-Apps im Hinblick auf die Indexierbarkeit verwenden könnt.
Bevor ihr beginnt, solltet ihr euch unbedingt unsere Indexierungsbeispiele für progressive Web-Apps ansehen. Hier erlebt ihr serverseitiges, clientseitiges und Hybridrendern in Aktion. Fragen könnt ihr wie immer in unseren Webmaster-Foren stellen.