WordPress-Outsourcing für SEO-Agenturen: Entwicklung im festen Monatsvertrag vergeben

Eine SEO-Agentur verkauft Audits, Content-Strategie und Linkaufbau. Nach dem Audit bleibt eine Aufgabenliste, und ein Teil davon verlangt Änderungen am Theme, an Plugins oder an der Serverkonfiguration. Ohne WordPress-Entwickler im Team bleibt diese Liste liegen, und der Kunde fragt im Juli, warum der Bericht aus dem März noch nichts bewirkt hat. Dieser Leitfaden zeigt, wie Sie diese Arbeit in einem festen Monatsvertrag nach außen vergeben: was der Entwickler übernimmt, wie er Zugriff bekommt, ohne dass Konten geteilt werden, was in den Vertrag gehört und wie Sie prüfen, ob die Arbeit wirkt.

Die Abschnitte zu Urheberrecht und Datenschutz fassen deutsche, österreichische und Schweizer Vorschriften sowie die DSGVO nach dem Stand vom 24. Oktober 2026 zusammen. Sie ersetzen keine Rechtsberatung für Ihre Agentur.

#Das Wichtigste in Kürze

• Die Agentur behält Diagnose, Prioritäten und Kundenbeziehung. Der Entwickler verantwortet die Umsetzung und dafür, dass eine Änderung die Produktion nicht beschädigt.
• Zugriff bekommt eine Person, keine Firma: eigener Nutzer in der Search Console, eigenes Konto in WordPress, eigener SSH-Schlüssel. Jeder davon lässt sich mit einem Handgriff entziehen.
• Im Vertrag stehen das monatliche Stundenkontingent, die Zeit bis zur ersten Reaktion (getrennt von der Behebungszeit), das Verfahren für größere Aufgaben, White-Label und Vertraulichkeit.
• Ein freier Entwickler bleibt Urheber seines Codes. Die Agentur nutzt ihn nur so weit, wie der Vertrag Nutzungsrechte einräumt, und darf sie an Kunden nur mit Zustimmung des Entwicklers weitergeben.
• Ein Entwickler mit Zugriff auf Websites mit personenbezogenen Daten ist weiterer Auftragsverarbeiter. Sie brauchen die Genehmigung des Kunden und einen Vertrag zur Auftragsverarbeitung (AVV).
• Den Effekt messen Sie pro Aufgabe: Ausgangswert, Datum der Umsetzung, Wert nach 28 Tagen Felddaten aus CrUX oder der Search Console.

#Begriffe für Agenturinhaber

#Welche Aufgaben aus dem SEO-Audit einen WordPress-Entwickler brauchen

Ein technisches Audit endet meist mit einer Liste von Befunden, nicht mit einer Liste von Personen. Der erste Schritt ist die Aufteilung, wer was erledigt. Die folgende Tabelle trennt danach, wo die Änderung liegt: im Inhalt und in den Einstellungen des Backends oder im Code und auf dem Server.

Wenn Sie dem Entwickler ein Ticket schicken, zeigt die Spalte “SEO-Agentur”, was er von Ihnen erwartet: URL-Liste, Search-Console-Daten, Weiterleitungstabelle. Ein Ticket ohne diese Angaben beginnt mit Rückfragen, und Rückfragen verbrauchen Stunden aus dem Paket. Woher die Wochen Wartezeit auf einfache Änderungen kommen, beschreibt der Beitrag warum Änderungen an WordPress-Websites Wochen dauern.

Für Agenturen im DACH-Raum kommt ein praktischer Punkt dazu. Viele Kundenwebsites sind mehrsprachig, etwa Deutsch und Französisch für die Schweiz oder Deutsch und Englisch für einen Exporteur aus Österreich. Hreflang-Fehler und doppelte Sprachversionen landen deshalb häufiger auf der Liste als bei rein einsprachigen Projekten. Legen Sie die Sprachpaare als Tabelle fest, bevor der Entwickler das Theme anfasst, sonst repariert er eine Logik, deren Sollzustand niemand aufgeschrieben hat.

#Wie der Entwickler Zugriff auf die Search Console bekommt, ohne Kontoübergabe

Die Search Console kennt mehrere Berechtigungsstufen. Die Beschreibung stammt aus Googles Hilfe zu Inhabern, Nutzern und Berechtigungen (support.google.com).

Ein Entwickler braucht fast nie die Inhaberschaft. Der uneingeschränkte Zugriff genügt: Er sieht alle Daten und kann Korrekturen zur Prüfung einreichen, während Nutzerverwaltung und Einstellungen bei den Inhabern bleiben.

Am Ende der Zusammenarbeit werden die Tokens leicht übersehen. Laut derselben Hilfeseite verliert ein entfernter Inhaber den Zugriff, seine Bestätigungstokens werden aber weder gelöscht noch ungültig. Liegt der Token (HTML-Datei, Meta-Tag, DNS-Eintrag) noch auf der Website oder in der Domain, kann die Person die Property erneut bestätigen. Deshalb sollte ein externer Entwickler die Property nicht mit dem eigenen Konto bestätigen. Hat er es doch einmal getan, entfernen Sie beim Abschied den Nutzer und seinen Token. Google weist beim Entfernen im Dashboard darauf hin, wenn der Nutzer den Zugriff zurückgewinnen kann: Dann liegen seine Tokens noch an Ort und Stelle.

Beim Entfernen der Tokens ist Vorsicht geboten. Die deutsche Fassung der Hilfeseite erinnert daran, dass derselbe Bestätigungstoken auch für andere Google-Dienste gelten kann, etwa Merchant Center oder Google Workspace. Wer einen Meta-Tag aus dem Theme löscht, sollte vorher prüfen, ob der Shop des Kunden darauf angewiesen ist.

Werden alle bestätigten Inhaber entfernt, verlieren die übrigen Nutzer und delegierten Inhaber nach einer Übergangszeit den Zugriff. Bestätigter Inhaber sollte also der Kunde bleiben, während Agentur und Entwickler mit einem Zugang arbeiten, den der Kunde kontrolliert.

#Welche WordPress-Rolle ein externer Entwickler bekommt

WordPress hat sechs Standardrollen. Die Dokumentation auf wordpress.org beschreibt sie so (in Klammern die Namen in der deutschen Oberfläche): Super Admin (Super-Administrator) verwaltet ein Multisite-Netzwerk, Administrator hat Zugriff auf alle Verwaltungsfunktionen einer einzelnen Website, Editor (Redakteur) veröffentlicht und verwaltet Beiträge, auch fremde, Author (Autor) veröffentlicht eigene Beiträge, Contributor (Mitarbeiter) schreibt, veröffentlicht aber nicht, und Subscriber (Abonnent) verwaltet nur das eigene Profil.

In einer Einzelinstallation hat nur der Administrator unter anderem diese Berechtigungen: update_core, update_plugins, install_plugins, edit_plugins, edit_themes, edit_files, create_users, delete_users und unfiltered_html. In Multisite hat sie nur der Super-Administrator. Ein Entwickler, der Plugins aktualisieren oder neue installieren soll, braucht also die Rolle Administrator auf dem Staging und meist auch auf der Produktion. Die Rolle Redakteur reicht für technische Arbeit nicht.

Wenn das Konto des Entwicklers ein Administratorkonto ist, zählt die Hygiene drumherum:

• Ein eigenes Konto pro Person. Ein gemeinsames Konto “agentur-dev” bedeutet, dass niemand weiß, wer was geändert hat, und dass Sie einer Person den Zugriff nur entziehen können, indem Sie allen das Passwort ändern.
• Dateibearbeitung im Backend abgeschaltet. Die Härtungsdokumentation von WordPress (developer.wordpress.org) sagt, dass define( 'DISALLOW_FILE_EDIT', true ); in der wp-config.php allen Nutzern edit_themes, edit_plugins und edit_files entzieht. Der Entwickler sollte Code ohnehin aus dem Repository ausrollen, nicht über den Editor im Backend.
• Staging mit gekennzeichneter Umgebung. Die Funktion wp_get_environment_type() liefert local, development, staging oder production und nimmt production an, wenn nichts gesetzt ist (developer.wordpress.org). Mit staging auf der Kopie können Code und Plugins sich anders verhalten, zum Beispiel keine E-Mails an Shopkunden verschicken.
• SFTP oder SSH statt FTP. Dieselbe Härtungsdokumentation empfiehlt SFTP, weil Passwort und Daten auf dem Weg verschlüsselt sind. In der Praxis funktioniert ein eigener SSH-Schlüssel pro Person besser: Den Zugriff entziehen heißt, eine Zeile aus authorized_keys zu löschen, ohne anderen das Passwort zu ändern. Wie Deployment über SSH und Git aussieht, zeigt der Beitrag modernes WordPress-Deployment mit SSH und Git.

Konten bei Hoster, Domain-Registrar und CDN sowie Lizenzen für Premium-Plugins gehören dem Kunden oder der Agentur. Der Entwickler erhält dort Zugriff als Nutzer, nicht als Eigentümer. Das gilt auch für Lizenzschlüssel: Läuft eine Plugin-Lizenz auf die private E-Mail-Adresse des Entwicklers, endet mit der Zusammenarbeit oft auch der Zugang zu Updates.

#Wie Sie Zugriffe am Ende der Zusammenarbeit entziehen

Die Liste für den Tag, an dem der Vertrag endet. Am besten steht sie im Vertrag als Pflicht beider Seiten:

1. Search Console: Nutzer und alle seine Bestätigungstokens entfernen (Datei, Meta-Tag, DNS-Eintrag).
2. WordPress: Konten des Entwicklers auf Produktion und Staging löschen, seine Beiträge einem anderen Nutzer zuordnen.
3. Server: seine SSH-Schlüssel aus authorized_keys, SFTP-Konten und gegebenenfalls Datenbankkonten entfernen.
4. Repository: Zugriff auf die Organisation, Deploy-Keys und CI-Secrets entziehen.
5. Hosting, CDN, DNS-Verwaltung, Zahlungsanbieter: Nutzer entfernen und dort, wo ein Konto geteilt war, Passwort und API-Schlüssel ändern.
6. Externe Werkzeuge: Google Analytics, Tag Manager, Monitoring, Passwortmanager.
7. Daten: schriftliche Bestätigung, dass der Entwickler Kopien von Datenbanken und Dateien mit personenbezogenen Daten gelöscht oder zurückgegeben hat (Pflicht aus Art. 28 Abs. 3 lit. g DSGVO, siehe unten).

Lässt sich diese Liste nicht in einer Stunde abarbeiten, wurden Zugriffe zu breit oder auf gemeinsame Konten vergeben.

#Core Web Vitals: was der Entwickler behebt und was der Hoster

Die Schwellen stehen bei web.dev (vitals). Gemessen wird am 75. Perzentil der Seitenaufrufe, getrennt für Mobilgeräte und Desktop.

INP wurde 2024 zur stabilen Core-Web-Vitals-Metrik und hat FID ersetzt. Kundenberichte aus der Zeit davor, die von FID sprechen, beschreiben eine Kennzahl, die Google in diesem Set nicht mehr verwendet.

Die Aufteilung der Verantwortung ergibt sich aus den Bestandteilen jeder Metrik. LCP umfasst Verbindungsaufbau, Weiterleitungen und Serverantwort und erst danach das Laden und Rendern des Elements. Ein Teil dieser Zeit gehört dem Hoster, ein Teil dem Theme.

Ein Thema mit DACH-Bezug fällt in diese Tabelle: Consent-Banner. Auf deutschsprachigen Websites lädt fast jede Seite eine Einwilligungslösung, und ihr Skript wirkt sich auf LCP, INP und CLS aus, je nachdem, wie und wann es eingebunden ist. Die Einbindung gehört zum Entwickler, die Auswahl des Anbieters und die rechtliche Konfiguration zur Agentur oder zum Kunden.

Ein Entwickler, der bei jedem schwachen Wert “das liegt am Hosting” antwortet, zeigt keine Messung. Ein guter Partner zerlegt eine hohe TTFB in PHP, Datenbank und Netz und benennt erst dann die Ursache. Braucht der Kunde vor der Entscheidung eine eigene Diagnose, ist das der Core-Web-Vitals-Audit. Die Korrekturen selbst beschreibt die Seite zur Beschleunigung einer WordPress-Website. Den technischen Überblick über die Metriken gibt der WordPress-Performance-Leitfaden zu Core Web Vitals, Cache und Bildern.

#Was in den Monatsvertrag mit dem WordPress-Entwickler gehört

Ein fester Vertrag mit einem Entwickler verkauft zwei Dinge: reservierte Zeit und eine planbare Reaktion. Der Vertrag sollte beides so beschreiben, dass nach drei Monaten niemand raten muss, was vereinbart war.

#Umfang und Stunden

Das monatliche Stundenkontingent, die Abrechnungsweise (etwa in Viertelstunden), was im Paket enthalten ist und was nicht. Eine mögliche Formulierung:

Der Auftragnehmer reserviert für den Auftraggeber in jedem Kalendermonat 24 Arbeitsstunden. In einem Monat nicht genutzte Stunden gehen nicht auf Folgemonate über.

Dass Stunden nicht übertragen werden, sieht nach einem Vorteil nur für den Entwickler aus, hat aber Gründe auf beiden Seiten. Der Entwickler lehnt andere Kunden ab, um diese Zeit für die Agentur freizuhalten. Würden sich Stunden endlos ansammeln, könnte die Agentur nach einem halben Jahr Dutzende Stunden in einer einzigen Woche verlangen, und das kann niemand leisten. Bleiben regelmäßig Stunden übrig, ist das Paket zu groß.

#Reaktionszeit und Behebungszeit

Das sind zwei verschiedene Zusagen. Reaktionszeit heißt Bestätigung, erste Diagnose und Plan. Die Behebungszeit hängt von der Ursache ab, und die kennt vor der Diagnose niemand. Eine mögliche Formulierung:

Reaktionszeit bedeutet die Bestätigung des Eingangs der Meldung mit einer ersten Diagnose und dem Plan für das weitere Vorgehen. Die Reaktionszeit läuft an Arbeitstagen von Montag bis Freitag während der Geschäftszeiten nach mitteleuropäischer Zeit. Die Reaktionszeit ist keine Frist zur Behebung des Fehlers.

Legen Sie außerdem fest, was jede Priorität bedeutet (zum Beispiel P1: Produktion oder Bestellungen funktionieren nicht; P2: ein Release ist blockiert; P3: Weiterentwicklung und Optimierung) und wer die Priorität vergibt. Ohne Definition wird jede Kundenmeldung zu P1.

Bei Kunden in Österreich und der Schweiz lohnt ein Satz zu Feiertagen. Die gesetzlichen Feiertage unterscheiden sich zwischen den Ländern und innerhalb Deutschlands und der Schweiz auch zwischen Bundesländern und Kantonen. Schreiben Sie in den Vertrag, nach welchem Kalender die Arbeitstage gezählt werden, sonst streiten Sie im Dezember über eine verpasste Reaktionszeit.

#Arbeit außerhalb der Geschäftszeiten

Gilt das SLA an Arbeitstagen, schreiben Sie ausdrücklich, dass Abende, Wochenenden und Störungen außerhalb dieser Zeiten eine eigene schriftliche Vereinbarung brauchen. Eine Agentur, die dem Kunden eine Rund-um-die-Uhr-Bereitschaft verspricht, aber einen Entwickler zu Bürozeiten hat, verkauft etwas, das sie nicht hat.

#Größere Arbeiten außerhalb des Pakets

Migration, neuer Inhaltstyp, Umbau der Templates passen selten ins Monatskontingent. Der Vertrag sollte festlegen, dass eine Aufgabe ab einer bestimmten Stundenzahl einen eigenen schriftlichen Umfang, eine Schätzung und eine Freigabe vor dem Start bekommt.

#Startphase und Kündigung

Zu Beginn geht ein Teil der Zeit dafür drauf, die Kundenwebsites, die Zugriffe und die Abläufe der Agentur kennenzulernen. Deshalb ist eine längere erste Laufzeit sinnvoll, danach ein monatlicher Vertrag mit festgelegter Kündigungsfrist.

#White-Label, Vertraulichkeit und Kundenschutz

Eine Vertraulichkeitsvereinbarung, unterschrieben, bevor Kundennamen und Zugänge übergeben werden. Die Regel, dass der Entwickler mit dem Endkunden nur spricht, wenn die Agentur das will. Das Verbot, dem Endkunden während der Zusammenarbeit und für eine festgelegte Zeit danach ein eigenes Angebot zu machen.

#Definition eines fertigen Tickets

Ein Ticket enthält das erwartete Ergebnis, URLs, Umgebung, Schritte zum Nachstellen des Problems und ein Abnahmekriterium. Fehlt etwas davon, geht das Ticket mit Rückfragen an die Agentur zurück, und ob diese Zeit vom Paket abgeht oder nicht, muss ebenfalls im Vertrag stehen.

Suchen Sie einen Partner für eine ganze Website statt für ein Stundenpaket, hilft unser Beitrag dazu, wie Sie eine WordPress-Agentur auswählen. Die laufende Betreuung einer einzelnen Website ohne Weiterentwicklung beschreibt das Angebot zur Wartung von WordPress-Websites.

#Wem gehört der Code, den der Entwickler für Kunden der Agentur schreibt

Hier unterscheiden sich die drei Länder im Detail, im Ergebnis aber kaum: Ein freier Entwickler ist kein Arbeitnehmer, und die Regeln, die dem Arbeitgeber automatisch Rechte am Programm geben, greifen bei ihm nicht. Was die Agentur mit dem Code tun darf, steht deshalb im Vertrag oder nirgends.

#Deutschland: Nutzungsrechte nach dem UrhG

Das deutsche Recht kennt keine Übertragung des Urheberrechts als Ganzes. Der Urheber räumt Nutzungsrechte ein, deshalb spricht § 31 UrhG durchgehend von Nutzungsrechten. Ein Vertrag, der “das Urheberrecht überträgt”, benutzt einen Begriff, den das Gesetz so nicht vorsieht. Schreiben Sie “räumt Nutzungsrechte ein”.

Aus § 31 Abs. 5 folgt die praktische Regel: Nennen Sie jede Nutzung einzeln. Für Code sind das Vervielfältigen, Bearbeiten und Umarbeiten auch durch Dritte, Veröffentlichen und öffentliches Zugänglichmachen im Netz, Weitergabe und Unterlizenzierung an Kunden der Agentur. Ohne die Zustimmung nach §§ 34 und 35 hat die Agentur vielleicht Rechte, kann sie aber nicht an den Kunden weiterreichen, der am Ende den Code betreibt.

Ein Vorschlag, den der Anwalt der Agentur prüfen sollte (Formulierung nach deutschem Recht):

Der Auftragnehmer räumt dem Auftraggeber an dem im jeweiligen Monat erstellten Code mit Abnahme des Monatsprotokolls das ausschließliche, räumlich und zeitlich unbeschränkte Nutzungsrecht für folgende Nutzungsarten ein: Vervielfältigung ganz oder in Teilen, Bearbeitung, Umgestaltung und sonstige Änderung auch durch Dritte, Verbreitung sowie öffentliche Zugänglichmachung im Internet. Der Auftragnehmer stimmt zu, dass der Auftraggeber diese Nutzungsrechte ganz oder teilweise auf seine Kunden überträgt oder ihnen weitere Nutzungsrechte einräumt.

Die Kopplung an das Monatsprotokoll hat einen praktischen Grund: Jede Abnahme hält fest, welcher Code zu welchem Zeitpunkt unter den Vertrag fällt. Das Formerfordernis ist in den hier ausgewerteten Paragrafen §§ 31, 34 und 35 nicht geregelt. Schriftlich und unterschrieben sollte die Vereinbarung trotzdem sein, schon damit die Agentur sie gegenüber dem Kunden belegen kann.

#Österreich: Werknutzungsbewilligung und Werknutzungsrecht

Das österreichische Urheberrechtsgesetz (RIS, Fassung vom 24.10.2026) unterscheidet in § 24 zwischen der Werknutzungsbewilligung, die eine Nutzung erlaubt, und dem ausschließlichen Werknutzungsrecht. Nach § 27 sind Werknutzungsrechte “vererblich und veräußerlich”, aber: “Auf Sondernachfolger kann ein Werknutzungsrecht in der Regel nur mit Einwilligung des Urhebers übertragen werden.” Für die Agentur heißt das dasselbe wie in Deutschland: Die Einwilligung zur Weitergabe an den Kunden gehört in den Vertrag.

§ 40b regelt Programme von Dienstnehmern. Schafft ein Dienstnehmer ein Programm in Erfüllung seiner dienstlichen Obliegenheiten, “steht dem Dienstgeber hieran ein unbeschränktes Werknutzungsrecht zu”, sofern nichts anderes vereinbart ist. Ein externer Entwickler ist kein Dienstnehmer der Agentur, also ersetzt der Vertrag diese Regel.

#Schweiz: Übertragung nach dem URG

Die Schweiz geht einen anderen Weg. Nach Art. 16 Abs. 1 URG (fedlex) gilt: “Das Urheberrecht ist übertragbar und vererblich.” Hier darf der Vertrag also tatsächlich von Übertragung sprechen. Art. 16 Abs. 2 schränkt ein: Die Übertragung eines Teilrechts schließt andere Teilrechte nur ein, wenn das vereinbart ist. Auch hier gilt deshalb, jede Nutzung zu nennen.

Art. 17 URG gibt dem Arbeitgeber bei Programmen, die “in einem Arbeitsverhältnis bei Ausübung dienstlicher Tätigkeiten sowie in Erfüllung vertraglicher Pflichten” entstehen, allein die ausschließlichen Verwendungsbefugnisse. Die Vorschrift setzt ein Arbeitsverhältnis voraus und gilt nicht für einen externen Auftragnehmer. Für Schweizer Kunden formuliert der Vertrag die Klausel oben deshalb als Übertragung der genannten Teilrechte statt als Einräumung von Nutzungsrechten.

#WordPress selbst und das Repository

Der Vertrag erfasst WordPress selbst nicht. WordPress steht unter GPLv2 oder einer späteren Version, und WordPress.org betrachtet Plugins und Themes als abgeleitete Werke, die die GPL erben (wordpress.org). Die Rechtseinräumung betrifft den Code, den der Entwickler für die Agentur geschrieben hat. Dieser Code gehört vom ersten Tag an in ein Repository der Agentur oder des Kunden. Rechte auf Papier helfen wenig, wenn der Code nur auf dem Laptop des Entwicklers liegt.

#Ist der externe Entwickler ein Auftragsverarbeiter

Fast immer, wenn er Zugriff auf Datenbanken mit personenbezogenen Daten hat: WooCommerce-Bestellungen, Kontaktformulare, Nutzerkonten, Newsletter-Listen. Die übliche Konstellation: Der Kunde der Agentur ist Verantwortlicher, die Agentur ist Auftragsverarbeiter, und der Entwickler, den die Agentur mit Arbeit an diesen Daten beauftragt, ist weiterer Auftragsverarbeiter.

#Deutschland und Österreich: Art. 28 DSGVO

In beiden Ländern gilt die DSGVO unmittelbar. Art. 28 Abs. 2 (EUR-Lex) lautet: “Der Auftragsverarbeiter nimmt keinen weiteren Auftragsverarbeiter ohne vorherige gesonderte oder allgemeine schriftliche Genehmigung des Verantwortlichen in Anspruch.” Bei einer allgemeinen Genehmigung informiert die Agentur den Kunden über jede beabsichtigte Hinzuziehung oder Ersetzung eines weiteren Auftragsverarbeiters, und der Kunde kann Einspruch erheben. Art. 28 Abs. 4 verlangt, dass dem weiteren Auftragsverarbeiter per Vertrag dieselben Datenschutzpflichten auferlegt werden, die die Agentur gegenüber dem Kunden hat. Erfüllt der Entwickler sie nicht, haftet die Agentur gegenüber dem Kunden für die Einhaltung seiner Pflichten.

#Schweiz: Art. 9 DSG

Die Schweiz ist nicht in der EU, und für Schweizer Kunden gilt das revidierte Datenschutzgesetz (fedlex). Nach Art. 9 Abs. 1 DSG darf die Bearbeitung vertraglich einem Auftragsbearbeiter übertragen werden, wenn die Daten nur so bearbeitet werden, wie der Verantwortliche selbst es tun dürfte, und keine Geheimhaltungspflicht entgegensteht. Abs. 2 verlangt, dass sich der Verantwortliche vergewissert, dass der Auftragsbearbeiter die Datensicherheit gewährleisten kann. Abs. 3 lautet: “Der Auftragsbearbeiter darf die Bearbeitung nur mit vorgängiger Genehmigung des Verantwortlichen einem Dritten übertragen.” Das Schweizer Gesetz verwendet eigene Begriffe (Auftragsbearbeiter statt Auftragsverarbeiter), und der Gedanke ist derselbe: ohne Genehmigung des Kunden kein externer Entwickler an den Daten.

#Drei Dokumente in der Praxis

1. Im Vertrag der Agentur mit dem Kunden: die Genehmigung (gesondert oder allgemein) für weitere Auftragsverarbeiter, mit dem Namen des Entwicklers oder mit einem Verfahren zur Information. Für Schweizer Kunden die vorgängige Genehmigung nach Art. 9 Abs. 3 DSG.
2. Ein AVV zwischen Agentur und Entwickler, der die Pflichten aus Art. 28 Abs. 3 DSGVO weitergibt: Verarbeitung nur auf dokumentierte Weisung, Vertraulichkeit der Personen mit Zugriff, Maßnahmen nach Art. 32, Unterstützung bei Anfragen betroffener Personen, Löschung oder Rückgabe der Daten nach Abschluss der Leistungen, Bereitstellung der Informationen für Überprüfungen.
3. Eine Regel für die Arbeit mit Daten: Staging mit anonymisierten oder reduzierten Daten, eine Kopie der Produktionsdatenbank nur, wenn die Aufgabe sie verlangt, und deren Löschung nach Abschluss des Tickets.

Eine mögliche Klausel zu Daten auf dem Staging:

Der Auftragnehmer bringt keine Kopie der Produktionsdatenbank außerhalb der vom Auftraggeber benannten Infrastruktur. Erfordert eine Aufgabe die Arbeit mit einer Datenkopie, löscht der Auftragnehmer sie innerhalb von 7 Tagen nach Abschluss des Tickets und bestätigt dies im Ticket.

#Wie Sie die Arbeit des Entwicklers im Monatspaket messen

Ein Stundenbericht sagt, wie viel Zeit verbraucht wurde. Er sagt nicht, ob die Website des Kunden besser funktioniert. Die Messung wird deshalb bei jeder Aufgabe geplant, bevor der Entwickler beginnt.

Für Performance-Aufgaben sind Felddaten die Quelle. Die CrUX API liefert einen gleitenden 28-Tage-Durchschnitt aggregierter Metriken und wird täglich gegen 04:00 UTC aktualisiert (developer.chrome.com). In den Datensatz gelangen nur öffentlich auffindbare Seiten mit ausreichend vielen Aufrufen, deshalb hat eine kleine Unterseite oft keine Daten auf URL-Ebene, nur auf Ebene der ganzen Domain. Der Core-Web-Vitals-Bericht in der Search Console nutzt dieselben CrUX-Daten, gruppiert ähnliche URLs und gibt der Gruppe den Status der schwächsten Metrik. Nach einer Korrektur startet die Schaltfläche zur Validierung ein 28-Tage-Fenster: Tritt das Problem in dieser Zeit bei keiner URL auf, gilt es für Google als behoben (support.google.com).

Daraus folgt der Rhythmus: Messung vorher, Datum der Umsetzung, Messung nach mindestens 28 Tagen. Ein Bericht nach einer Woche zeigt eine Mischung aus alten und neuen Seitenaufrufen.

Für SEO-Aufgaben (Weiterleitungen, Indexierung, strukturierte Daten) messen Sie mit den Berichten der Search Console: Indexierungsstatus der betroffenen URLs, Statusbericht für den jeweiligen Typ strukturierter Daten, Leistung einer Seitengruppe vor und nach der Änderung.

Ein einfaches Format für den Monatsbericht, den die Agentur unter eigener Marke an den Kunden gibt:

Die Zahlenfelder füllen Sie mit Daten aus den Werkzeugen, nicht mit Schätzungen. Die Spalte “Status der Messung” verhindert, dass ein Erfolg berichtet wird, der noch nicht sichtbar ist.

#Woran Sie einen schlechten White-Label-Partner erkennen

Warnsignale bei der Wahl eines Entwicklers oder einer Firma, die unter Ihrer Marke arbeiten soll:

• Unbegrenzte Tickets zum Festpreis. Irgendwer zahlt für das fehlende Limit, meist mit einer Warteschlange, in der Ihr Ticket ohne Termin liegt.
• Keine schriftliche Reaktionszeit. “Wir antworten schnell” ist keine Zusage. Fragen Sie nach der Reaktionszeit für die kritische Priorität und nach den Zeiten, in denen sie gilt.
• Versprochene Behebungszeit für jede Störung. Vor der Diagnose kennt niemand die Ursache. Eine Garantie, alles in 2 Stunden zu beheben, heißt, dass der Vertrag nicht durchdacht ist.
• Stunden, die endlos übertragen werden. Klingt günstig, erzeugt aber eine Zeitschuld, die der Partner nicht auf einmal begleichen kann.
• Kein Staging. Ein Entwickler, der direkt auf der Produktion des Kunden arbeitet, verlagert das Risiko auf Ihre Agentur.
• Gemeinsame Konten und ein Passwort fürs Team. Niemand kann feststellen, wer was geändert hat, und einer Person lässt sich der Zugriff nicht einzeln entziehen.
• Bestätigung der Search Console mit dem eigenen Konto des Entwicklers. Beim Abschied bleiben die Tokens und damit die Möglichkeit zur Rückkehr.
• Code nur auf dem Server, ohne Repository der Agentur oder des Kunden. Nutzungsrechte auf Papier helfen nicht, wenn Sie den Code nicht haben.
• Kein AVV. Fragt der Partner nicht nach personenbezogenen Daten, denkt er nicht an die Haftung, die die Agentur für ihn gegenüber dem Kunden trägt.
• Ein Vertrag, der von “Übertragung des Urheberrechts” spricht, für einen deutschen Kunden. Das zeigt, dass niemand den Text an das UrhG angepasst hat, und meistens fehlt dann auch die Zustimmung zur Weitergabe an den Kunden.
• Ein Partner, der vom ersten Tag an Kontakt zum Endkunden will. White-Label heißt, dass die Agentur entscheidet, ob und wann es dazu kommt.

#Wie der Agency Development Desk funktioniert

Der Agency Development Desk ist unser festes Angebot für SEO-, Branding- und Designagenturen ohne eigenen WordPress- und WooCommerce-Entwickler. Die Regeln sind dieselben, die dieser Leitfaden als sicher beschreibt:

• drei Pakete mit monatlichem Stundenkontingent: Desk Flex (10 Std.), Desk Core (24 Std.) und Desk Embedded (48 Std.), jedes mit einer schriftlichen Zeit bis zur ersten Reaktion je nach Priorität;
• das SLA gilt an CET-Arbeitstagen, Abend-, Wochenend- und Notfallarbeit braucht eine eigene schriftliche Vereinbarung;
• Reaktion heißt Bestätigung, erste Diagnose und Plan, keine garantierte Behebung in derselben Zeit;
• ungenutzte Stunden gehen nicht auf den nächsten Monat über, weil diese Kapazität für die Agentur reserviert war;
• die erste Laufzeit beträgt zwei Monate, danach läuft das Paket monatlich mit einem Monat Kündigungsfrist;
• größere Sprints bekommen einen eigenen schriftlichen Umfang, eine Schätzung und eine Freigabe;
• NDA vor der Übergabe von Zugängen, White-Label-Arbeit im Prozess der Agentur und Kundenschutz im Vertrag;
• der Code landet in einem Repository, das die Agentur oder der Kunde kontrolliert, und Konten und Lizenzen hängen nicht von uns ab.

Aufgaben nehmen wir als schriftliches Ticket mit erwartetem Ergebnis, Links, Umgebung und Abnahmekriterium an, ohne Pflichttermine. Die Paketpreise stehen auf der Seite des Angebots. Um die Passung zu prüfen, genügt eine E-Mail mit der Art der betreuten Kunden, dem Stack, einem Beispiel-Backlog aus dem letzten Audit und der erwarteten Stundenzahl pro Monat.