STORIES

***
TL;DR: Dieser Artikel beschreibt, wie man aus Ryte (ehem. Onpage.org) Projektdaten per API und Apps Skript in ein Google Spreadsheet für eigene Reports laden kann, und zwar regelmäßig und projektübergreifend. Er richtet sich an Einsteiger und Fortgeschrittene, die mit einigen technischen Grundbegriffen bereits vertraut sind.
***

Hinweis: Onpage.org heißt seit August 2017 Ryte.

Onpage.org ist das weltweit führende Tool für OnPage-SEO. In der SEO-Szene ist hinreichend bekannt, dass eigentlich kein anderes OnPage-Tool an die Leistungen von Onpage.org herankommt. Zum vielversprechenden DeepCrawl hat es ca. 2 Jahre Vorsprung am Markt, der neue Moz Site Crawl kommt bei weitem nicht an die Vielfältigkeit von onpage.org ran.

Der Alltag im OnPage-SEO besteht aus vielen Tools, daher entsteht beim Anwender das Bedürfnis, alle relevanten Daten in einer einzigen Übersicht – Dashboard oder Report – zusammenzuführen. Die Zusammenführung der Daten darf im Umkehrschluss kein mühevoller, monatlicher Akt sein, sondern idealerweise automatisiert passieren.

Die OnPage API

Onpage.org bietet den Zugriff der Projektdaten über die REST-API an, jedoch mit einer Einschränkung: es ist mindestens ein Account vom Typ „Business“ notwendig. Der „vollständige Integrationsguide” ist im Vergleich zu anderen Dokumentationen recht dünn und bebildert gehalten. Hinweis: Stellt Eure API-Fragen nicht an den aufgeführten Kontakt am Ende der Seite, es ist lediglich der Vertriebskontakt.

Wie im Guide beschrieben, gibt es für jede Visualisierung im Zoom-Modul einen Dropdown mit der Auswahl „API-Call”, der kopiert werden muss. Dies ist der spätere POST-payload für die Abfrage gegen den /zoom/ Endpoint, nicht direkt der vollständige API-Call.

„Dünn” ist die Dokumentation in dem Sinne, dass es eine keine vollständige Referenz der Endpoints, Methoden und Objekte gibt, aus welcher man modular Requests zusammenbauen könnte. So ist man an die jeweilige konkrete Struktur des kopierten JSONs gebunden. Dies ist aber zu verkraften, da man im Gegenzug die genaue Filterkonfiguration des Frontends in einen API-Call überführen kann – dies ist ein sehr hilfreiches Feature, wenn man tief verschachetelte Filteransichten regelmäßig abfragen möchte.

Einschränkung der API-Abfragen auf Zoom

Implizit ergibt sich aus dem Guide und den im Frontend angezeigten Zahnrad-Symbolen, dass API-Abfragen ausschließlich für das Zoom Modul verfügbar sind, da in den anderen Modulen Focus, Impact, WDF-IDF etc. keine Zahnradysmbole zu finden sind. Korrigiert uns gerne, wenn wir hier etwas übersehen haben.

Sammlung der Ansichten: Welche Bereiche sind für mein Projekt relevant?

Da für alle Boxen in Zoom ein POST-Payload-JSON kopiert werden kann, stellt sich die Frage, wie man mehrere Ansichten und Abfragen gleichzeitig abarbeiten kann. Eine einfache Lösung bietet die untenstehende Implementierung über Apps Skript.

Vorbehalt: Je nach Projekt, Agentur und eigener Arbeitsweise sind natürlich unterschiedliche Ansichten interessant. Wir haben eine willkürliche Auswahl zusammengestellt und diese in ein Konfigurationsobjekt gepackt, welches im Skript unten beliebig nach eigenen Wünschen erweitert werden kann.

Beim Kopieren und Zusammenführen der POST-Payloads sollte man diese vor dem Einfügen in das Skript durch ein JSON-Minifier-Tool schleusen, um den Inhalt auf einer Zeile darzustellen und das Skript übersichtlich zu halten.

Im Folgenden nutzen wir für die Implementierung Javascript in Kombination mit der Ausführungsumgebung Google Apps Skript. Apps Skript ist mit die einfachste Art, um als Marketer mit APIs zu experimentieren, ohne den technischen Unterbau von Grund auf zu kennen oder erstellen zu müssen.

Anlegen eines Apps Skriptes

Erster Schritt ist die Anlage eines Skriptes auf script.google.com.

Dort fügt ihr den untenstehenden Code ein und entfernt den bestehenden Funktionsrumpf „function myFunction() {}“. Falls ihr später mehrere Skripte aus dem gleichen Projekt zeitlich steuert, sollte diese spezifische Namen haben. Unten findet ihr den vollständigen Code inklusive Funktionsrumpf „function onPageApiCall() {}”.

Konfiguration I: Unsere Sammlung von POST-Payloads

Nach Anlage und Speicherung des Skriptes geht es an die Konfiguration. Nachstehend sieht man unsere Liste an Abfragen an die Onpage API, die Namen sollten hoffentlich sprechend genug sein:

Für die Beispielimplementierung unten haben wir JSON-payloads aus Übersichtsgrafiken („action“: „aggregate„) und Listenansichten („action“: „list„) zusammengeführt. Das Ergebnis sind zwei Codeblöcke:

1) die einzelnen minified payloads pro Request und
2) eine konsolidierte ONPAGE_CALLS Liste aus Objekten pro Bereich.

Es mag unübersichtlich wirken, anders wären jedoch alle Informationen inklusive der Tool-URLs nicht ohne Redundanz aufzuführen.

Konfiguration II: Projekt, API-Key und Limit

Alle payloads sind mit den drei Variablen versehen, damit beim Kopieren eines Skripts diese Werte nur an einer Stelle geändert werden müssen:

- Projekt: Dies entspricht schlichtweg dem Projektnamen in Onpage
- API-Key: Dieser ist in jedem payload JSON enthalten und ist projektübergreifend der gleiche, nur an den User gebunden
- Limit: Ein willkürlicher Wert für die Limitierung von Ergebnissen, hier 200.

Konfiguration III: Google Spreadsheet als Ausgabe

Zum Abschluss fehlt noch die Spreadsheet-ID Eures Google-Dokuments in das ihr schreibt. Zur Konfiguration des Sheets müsst ihr lediglich ein Datenblatt „OnPage” nennen und die ID nach diesem Muster aus der URL kopieren.

Erster Skriptdurchlauf, Interpretation und Scheduling

Da in der aktuellen Konfiguration 26 API Requests ausgeführt werden, kann ein erster Durchlauf durchaus 5 Minuten dauern, also habt etwas Geduld. Im App Skript Menüpunkt Ansicht > Ausführungsprotokoll können die genauen Schritte nachvollzogen werden. Wenn alles korrekt läuft, sollte folgende Tabelle im Tab „Onpage” sichtbar sein:

Jeder Inhaltsblock ist wiederum ein eigenes Objekt bzw. eine eigene Tabelle. Wir haben uns in der aktuellen Darstellung noch nicht die Mühe gemacht, jede erneut in eine Einzeltabelle zu überführen. Mit einer bedingten Formatierung haben die Listenansichten aber bereits eine gute Aussagekraft mit einfacher Vergleichbarkeit zu anderen Projekten:

Ähnlich den grauen Prioriätspunkten in der Zoomübersicht mit Werten 1-3, lassen sich über die Mengen die Ausprägungen der jeweiligen OnPage-Problemfelder visualisieren, womit schnell Projektschwerpunkte für den nächsten Zeitraum gesetzt werden können. In der Interpretation also folgende Probleme vordergründig:

- lange Klickpfade
- keine oder schlechte interne Verlinkung indexierbarer URLs
- Bilder ohne Alt-Text sowie
- große Dateien, vorrangig Bilder

Der letzte Schritt zur Automatisierung ist die Einrichtung des Schedulings mit einem regelmäßiger Skripttrigger. der über das Uhr-Icon links oben im Menü gesetzt werden kann. Er sorgt für die automatisierte Ausführung zu einem wiederkehrenden Zeitpunkt. Hier könnt ihr zwischen den Intervallen>„stündlich”, „täglich” und „wöchentlich” wählen.

Fazit

SEO fängt bekanntlich bei OnPage an. Über Apps Skript lassen sich die wertvollen OnPage-Potentiale einfach in das eigene Reporting einbinden. Die gezeigte Lösung ist recht stark mit der Konfiguration verzahnt, sicherlich gibt es noch eine elegantere und außerdem generische Umsetzung. Falls ihr weitere Ideen zur Nutzung der Onpage Zoom API habt, teilt sie uns gerne in den Kommentaren mit!