SavTee – PIMp my Data

Vorteile?

Sie sparen sehr viel Zeit! Sie sehen Inhalte tabellarisch untereinander, was die Möglichkeit eines direkten Vergleichs anbietet. Behalten Sie die Kontrolle über Ihre Artikel SEO und da ohne ein fremdes Backend betreten zu müssen, welches Sie unter Umständen nicht einmal kennen, um nur einen kleinen Teil eines Artikels zu bearbeiten. Später wird es über eine Mandantenverwaltung auch für Agenturen möglich ein, alle Ihre Kunden zentral mit allen Seiten anzubinden.

1. Stand der Technik

Unsere Idee ist zu Hause im Raum der Online Contentpflege. Nach heutigem Stand der Technik funktioniert eine Content Anpassung nach der Umsetzung mit dezentralen Mitteln. Das heißt, jede Online verfügbare Web-Applikation, z.B. das „CMS“ WordPress, der Gambio Onlineshop oder das Content Management System Typo3, bestehen maßgeblich aus den Bereichen „Frontend“ und „Backend“. Das Frontend ist die Schnittstelle zum Besucher der Seite, das Backend dient der Aktualisierung und Konfiguration der Inhalte und Funktionen. Dazu existieren unzählige System-Beispiele dieser Art, in immer wieder anderen technischen Ausführungen. Siehe z.B. https://sourceforge.net/directory/internet/www/dynamic/cms /os:linux.

Hinzukommt, dass zu unterscheiden ist zwischen den verschiedenen Programmiersprachen und Betriebssystemen. Ein System verwendet die Sprache Ruby, ein anderes PHP auf Basis von Linux. Es existieren Systeme auf Basis von ASP unter Windows. Und alle diese Systeme verwenden i.d.R. eine Datenbank. Auch hiervon existieren viele verschiedene Typen, von denen die gebräuchlichsten MySQL, bzw. MariaDB – ein Ableger von MySQL – sind. Diese Datenbanken sind bei jedem Webhoster, der für eine Onlinepräsenz benötigt wird, verfügbar. In diesen Datenbanken werden dann nach den verschiedenen Architekturen der jeweiligen Systeme – siehe oben WordPress usw. – die Systeminhalte und Daten gespeichert.

Will man also z.B. Text Inhalte des Systems WordPress ändern, ruft man die Domain, auf der die Webseite installiert wurde, zusammen mit der Login Seite auf – hier im Beispiel z. B. /wp-admin – um in den Backendbereich des WordPress Systems zu gelangen. Dazu dienen ein Benutzername und ein zugehöriges Passwort. Ist man mit dieser Kombination eingeloggt und möchte nun z.B. einen Text auf der Seite „Impressum“ abändern, so ist es nach dem Login in das Backend notwendig die zu editierende Seite über die systemtypische Navigationsstruktur im Backend zu erreichen. Bis zu dem Punkt, an dem die eigentliche Aufgabe erledigt werden kann, werden daher verschiedene Wartezeiten für den Aufruf der unterschiedlichen Navigationsschritte notwendig:

• Die Ladezeit beim Aufruf der zu editierenden Seite selbst,
• sowie die Ladezeit nach dem Speichern der Seite ist dabei zu berücksichtigen,
• ebenso wie die Ladezeit der initialen Loginseite.

Dies kann bei einem kleinem zu verändernden Text, welcher z. B. in 5 Sekunden editiert werden könnte, zu einer Vervielfachung der benötigten Zeit führen, die allein durch die Wartezeit während der eigentlichen Aufgabe generiert würde.
Dieses Verhalten ist bei allen Web-Applikationen gleich. Dabei ist es nahezu unerheblich ob sie auch über sogenanntes Frontend Editing verfügt, also das editieren ohne direkten Backend Zugang oder ob sie auf die oben geschilderte Art und Weise der Anpassung zurückgreift. Alle Abläufe sind i.d.R. wie oben beschrieben gleich.

2. Das zugrunde liegende Problem

Wie oben unter Punkt 1. erklärt, sind die sich addierenden (Warte-) Zeiten ein großer Kostenfaktor. Insbesondere bei der Notwendigkeit Marktfähige Dienstleistungen anbieten zu müssen, entsteht hiermit ein zuberücksichtigender Kostenfaktor für die Agenturen, welcher das Angebot für SEO Leistungen und Contentpflege Online verteuert und verlangsamt. Zudem sind die Einarbeitungszeiten und insbesondere auch die Vielfalt der unterschiedlichen Online Systembackends, die alle Ihre Eigenarten haben, ein weiterer Zeitfaktor.
Wenn eine Agentur SEO relevante Daten auf einer, sagen wir mal, WordPress Webseite abändern möchte, muss Sie i.d.R. wie folgt vorgehen:

BSP Zeitaufwand (gerundet)

1. 30 sec – Die korrekten Logindaten je nach Kunde heraussuchen (abhängig von der
   Speicherung und des Systems in dem gespeichert wird auch länger)
2. 5 sec – Loginseite aufrufen
3. 5 sec – die korrekten Logindaten je nach Kunde eingeben 1min – 3min. – Je nach System (und Internetgeschwindigkeit) im Backend zur editierbaren
   Webseite wechseln.
4. Dies mehrmals, je nach Anzahl der zu erledigenden Aufgaben bei unterschiedlichen Kunden (z.B. in
   anderen WordPress Installationen)
5. 10 sec – Inhalte ändern (für eine Textänderung)
6. 5 sec – Seite speichern (mit Reload)
7. 10 sec – Änderung online überprüfen.

Gesamtaufwand nach herkömmlicher Vorgehensweise: 125 – 245 Sekunden x Kundenanzahl

Dieser Ablauf ist obligatorisch. Selbst bei den heutigen Servergeschwindigkeiten im Shared Hosting und schnellen Internetverbindungen sind damit dennoch hohe Zeitaufwände zu berücksichtigen, die nicht mehr amortisiert werden können und i.d.R. dem Kunden in Rechnung gestellt werden müssen, weil es Arbeitszeit ist.

3. Die Problemlösung

Unsere Idee ermöglicht nun zwei Dinge:

Als Erstes zentralisiert sie über ein gemeinsames universelles Login den zentralen Backendbereich zum Editieren der Inhalte des angeschlossenen Systems (z.B. WordPress) und ermöglicht so nach der Konfiguration das Aktualisieren der Inhalte des jeweiligen Zielsystems / der Webseite / des Onlineshops, ohne das System eigene Backend betreten zu müssen. Dies erfordert keine weitergehende Kenntnis der jeweiligen Backends und standardisiert und zentralisiert so die Aktualisierung von Web Inhalten.

Zum Zweiten egalisiert Sie die verschiedenen Darstellungsarten der verschiedenen Systeme für den Fall der Aktualisierung, da auch hier nur das zentrale universelle Backend notwendig wird, welches bei allen angeschlossenen Systemen auf die gleiche Art funktioniert. Auf diese Weise wird die Einarbeitung in unterschiedliche Verfahrensweisen mehr oder minder überflüssig. Unsere Liste von oben reduziert sich wie folgt um den Part der Zeit intensivsten Aufwände:

1. 30 sec – Die korrekten Logindaten je nach Kunde heraussuchen (abhängig von der
   Speicherung und des Systems in dem gespeichert wird auch länger)
2. 5 sec – Loginseite aufrufen
3. 5 sec – die korrekten Logindaten je nach Kunde eingeben
4. 10 sec – Inhalte ändern (für eine Textänderung)
5. 5 sec – Seite speichern (mit Reload)
6. 10 sec – Änderung online überprüfen.

Gesamtaufwand mit unserer Schnittstelle: 65 Sekunden für eine Änderung, gleich bei welchem Kunden.

4. Die erreichten Vorteile

Ist das angeschlossene System erst einmal konfiguriert, können sich Agenturen über das universelle Backend „per Klick“ in das auszuwählende Zielsystem einloggen um dort sehr schnell Änderungen durchzuführen. Es sind keine umfangreichen Einarbeitungs- oder Ladezeiten mehr zu berücksichtigen, was die Arbeiten schneller macht und die Kosten geringer hält. Neben der zentralen Editiermöglichkeit ist auch die Präsentation innerhalb des zentralen Backends
in tabellarischer Form, statt pro Seite im jeweiligen Backend, so aufgebaut, dass keine Artikelwechsel wie in den Zielsystemen mehr notwendig sind. Das erspart dem Benutzer immens Zeit und dem Kunden dadurch erneut Kosten.
Aktualisierungsarbeiten werden, über die universelle Schnittelle ausgeführt, dazu führen, dass dadurch auch z.B. „nur“ Shopbetreiber ein hohes Einsparungspotential erlangen können.

Vorteile vom z.B. SavTee® – dem auf lokale SEO ausgerichtetem Plugin
Bei der heutigen SEO-Pflege müssen immer folgende Schritte absolviert werden, egal ob mit oder ohne SEO-Plug-In. Beispiel anhand der Meta Daten Page-Title, Meta-Description und der H1 Überschrift:

Bearbeitungs-Ablauf:

1. entsprechende Seite aufrufen
2. zum Page-Title Eingabefeld scrollen, diesen anklicken und Eintragung vornehmen
3. zum Meta-Description Eingabefeld scrollen, diesen anklicken und Eintragung vornehmen
4. zur H1 Überschrift scrollen und Eintragung vornehmen
5. nach Erledigung alles „SPEICHERN“

Bei jeder weiteren Seite muss immer wieder der gleiche Aufwand von Punkt 1-5 erneut werden.