SavTee

Was ist „SavTee®“?
SavTee® ist ein WordPress SEO Plugin

Der Name SavTee® ist ein Wortspiel aus „Save“ und „Time“. Das Doppelte „e“ ist die Erinnerung an doppelt gesparte Zeit, die durch das Plugin erreichbar wird. Eben wegen der zentralen Editierfunktion auf der einen und den ebenfalls editierbaren Inhalten aus externen Quellen, auf der anderen Seite.

Unser Service zentralisiert die Aktualisierung von beliebigen Content. Die aktuell im WordPress Tool editierbaren und signifikanten Felder lauten H1, Meta Title, Meta Description, der Permalink, sowie der eigentliche Seiten Inhalt (Content). Die Community Version als Standard Variante des Tools, ist in der Lage, Ihre WordPress Artikel und Seiten als tabellarische Ansicht zum Editing anzubieten, um alle Inhalte in einer Übersicht editieren zu können, Sie also zentral zu pflegen.

Darüber hinaus wird mittels unserer SavTee® Erweiterung es zukünftige auch möglich sein, externe Systeme – wie z. B. Gambio oder einen anderen Onlineshop, anzubinden. Das heißt letztlich, Sie können später zentral Artikel aus einem Onlineshop und auch aus Ihrem CMS zentral über ein Backend editieren.

Vorteile?

Sie sparen Zeit! Behalten die Kontrolle über Ihre Artikel SEO und müssen kein fremdes Backend betreten, welches Sie unter Umständen nicht einmal kennen, um bloß einen kleinen Teil eines Artikels zu bearbeiten. Später wird es über eine Mandantenverwaltung auch für Agenturen möglich ein, alle Kunden zentral mit Ihren Seiten anzubinden.

Der Anfang: SavTee® Editor für WordPress

DER GRUND FÜR DIESES TOOl IST …

1.

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.

Remove the row

Column: 1

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.

Column: 2

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.

Nachteil:
Wenn eine Website über mehrere Unterseiten verfügt, was meistens der Fall ist, ist dies mit einem erheblichen zeitlichen Aufwand verbunden.

Vorteil unseres SavTee® Plug-In:
Zentrale Bearbeitung auf einer einzigen Seite, da alle Meta-Daten untereinander aufgelistet sind. Dadurch einfache, schnelle und übersichtliche Bearbeitung der Meta-Daten in einem Arbeitsschritt.