Hey — du hast in derselben Nachricht zwei Dinge gefragt: warum der Sync für deine drei Domains eine Stunde später ausgelöst hat, als du eingestellt hattest, und ob du dein Optimierungsteam gleich auf autonom umstellen solltest, wenn du schon dabei bist. Es stellt sich heraus, dass es dasselbe Thema ist, also nehme ich es gemeinsam durch, statt zwei separate Antworten zu schicken.
Fangen wir mit der Struktur des Systems an, denn das erklärt beide Probleme. Jedes Team hier läuft in einem von drei Modi – einmalig, manuell, autonom – und „autonom“ ist keine separate, klügere Stufe. Es ist ein manueller Lauf mit angehängtem Zeitplan, bei dem die Schleife geschlossen bleibt. Derselbe Agent, dieselben Leitplanken, alles gleich – nur entscheidet ein Scheduler, wann der Button geklickt wird, statt du. Sobald das klar ist, fügt sich der Rest zusammen.
Warum dein Sync und dein Zeitplan an verschiedenen Orten liegen
| Planen | Was es steuert |
|---|---|
| Datensynchronisierung | Der tägliche Abruf von Search-Console-/Analytics-/Store-Daten in deine Dashboards – der Treibstoff für alles andere |
| Agent-Läufe | Automatische Optimierungsläufe nach jedem Sync, Research-Durchläufe, die deine Brief-Warteschlange auffüllen, und jedes Team, das du laufen lässt |
Du findest die Sync-Einstellungen bei jeder Domain und die Lauf-Einstellungen bei jedem Team – nicht auf einer gemeinsamen Automatisierungsseite, was sich, wie ich weiß, beim ersten Suchen falsch anfühlt. Es ist jedoch bewusst so. Deine Sync-Frequenz betrifft die Daten: wie schnell Search Console tatsächlich aktualisiert. Deine Lauf-Frequenz betrifft das Team: wie schnell du willst, dass es auf das reagiert, was es sieht. Das sind unterschiedliche Fragen mit unterschiedlichen Antworten, und eine frühere Version dieser Plattform hatte beides auf einer Seite zusammengeschraubt, was bedeutete, dass das Anfassen von einem der beiden dich zwang, über beides nachzudenken. Die Trennung war die Lösung.
Etwas, das du wissen solltest, bevor du irgendetwas für dein Optimierungsteam einplanst: Ein Lauf, der per Zeitplan ausgelöst wird, und ein Lauf, den du von Hand startest, erzeugen, sobald sie laufen, dasselbe Objekt. Derselbe Bericht, derselbe Verlaufseintrag, dieselben Credit-Kosten, dieselbe Möglichkeit, mitten im Lauf reinzuschauen und zuzusehen, was passiert. Ich habe schon erlebt, dass Leute annehmen, geplante Läufe seien eine leichtere, abgespeckte Version zum Kostensparen – sind sie nicht. Wenn du einem selbst ausgelösten Lauf nicht vertrauen würdest, setz ihn nicht auf einen Timer.
Was mit deinem migrierten Zeitplan tatsächlich schiefgelaufen ist
Du hast erwähnt, die Zeit direkt aus deinem alten Tool eingefügt zu haben – 14:00 UTC, gedacht, um bei dir um 14 Uhr Ortszeit anzukommen. Das ist genau die Falle. Unser Zeitfeld will deine lokale Uhrzeit, nicht UTC; es zeigt die erkannte Zeitzone direkt darunter an, damit du nie raten musst. Fügst du dort einen UTC-Wert ein, wird er als bereits lokal behandelt, ein zweites Mal in UTC umgerechnet, und du landest bei einem Lauf um 16 Uhr statt um 14 Uhr. Die Lösung für deine anderen zwei Domains: die Zeiten neu in lokal eingeben, den UTC-Wert des alten Tools ignorieren.
Die Stunde, nach der du eigentlich gefragt hast – der Sync, der um 7 statt um 6 Uhr ankommt – ist ein DST-Artefakt (Sommerzeitwechsel), und es lohnt sich, es einmal zu verstehen, statt es jeden März und Oktober erneut zu jagen. Stellst du im Januar in Berlin einen Sync auf 6:00 Uhr ein, speichert die Plattform 5:00 UTC, weil Berlin im Winter bei UTC+1 liegt. Ein naiver Scheduler würde einfach für immer um 5:00 UTC auslösen. Kommt der DST-Sprung, wechselt Berlin zu UTC+2, und derselbe 5:00-UTC-Tick landet nun um 7:00 Uhr Ortszeit – leise, ohne Fehlermeldung, einfach ein paar Stunden später als erwartet. Wir rechnen stattdessen bei der Eingabe gegen den aktuellen Offset um, sodass ein 6:00-Uhr-Zeitplan 6:00 Uhr Wanduhrzeit am Tag der Ausführung bedeutet, DST hin oder her. Falls du nach dem Neu-Eingeben der Zeit lokal immer noch eine Abweichung von einer Stunde siehst, ist das ein Fall für ein Support-Ticket – das sollte bei einem frisch eingegebenen Zeitplan nicht passieren.
Die tatsächliche Frequenz einstellen
- Sync: täglich, nicht schneller. Search-Console-Daten liegen an einem guten Tag zwei bis drei Tage zurück. Stündliches Synchronisieren über deine drei Domains hinweg bringt dir keine frischeren Zahlen, es füllt nur den Sync-Verlauf mit Jobs, die immer wieder dieselben veralteten Daten abrufen.
- Optimierung: an den Sync gekoppelt, nicht separat getaktet. Das ist der Teil, der für das, was du gleich einplanst, am wichtigsten ist. Wenn der Sync um 6:02 statt um 6:00 Uhr fertig wird, weil Googles API an diesem Morgen langsam war, löst der Optimierungslauf direkt danach auf den frischen Daten aus – er wartet nicht auf sein eigenes 6:15-Uhr-Zeitfenster und riskiert, gegen die gestrigen Zahlen zu laufen, falls der Sync mal länger dauerte. Zwei unabhängige Uhren klingen gut, bis zu dem Tag, an dem sie auseinanderdriften.
- Research: wöchentlich, dimensioniert auf das, was dein Content-Team tatsächlich abarbeiten kann. Briefs veralten nicht über Nacht, und ungeprüfte Briefs in einer Warteschlange kosten trotzdem Credits in der Erstellung, selbst wenn niemand danach handelt. Wenn dein Team realistisch vier oder fünf Briefs pro Woche freigeben kann, dimensioniere den Durchlauf so, dass etwa das entsteht – ein täglicher Durchlauf, der eine wöchentliche Review-Gewohnheit füttert, baut nur einen Rückstau auf, den nie jemand aufarbeitet.
- Ads, wenn du nächsten Monat zu diesem Team kommst: kein Zeitplan, mit Absicht. Entwürfe werden auf Abruf generiert; nichts wird ohne dich gepostet oder ausgegeben. Die Begründung steht in dem Argument gegen automatisierte Ausgaben, aber die Kurzfassung ist: Ein Zeitplanfehler bei einem Content-Sync ist eine kleine Unannehmlichkeit, ein Zeitplanfehler bei Werbeausgaben ist eine Rechnung. Erwarte nicht, dass die Einstellungen dieses Teams so aussehen wie die, die du heute einrichtest.
Also — solltest du die Optimierung auf autonom umstellen?
Hier die ehrliche Antwort, die weniger dramatisch ist, als die Frage vermuten lässt: Das Einschalten ändert weniger, als man denkt. Der Agent bekommt keine neue Fähigkeit, die er nicht schon hatte, als du den Lauf selbst gestartet hast – dieselben Bestätigungssperren bei allem Destruktiven, dieselben Ermessensentscheidungen, alles gleich. Was sich ändert, ist nur, wer entscheidet, wann er handelt. Gerade jetzt bist es du. Bei einem Zeitplan ist es die Uhr.
Die Frage, die ich statt „ist autonom sicher“ tatsächlich stellen würde, ist diese: Bist du damit einverstanden, dass das Ergebnis deiner letzten drei manuellen Optimierungsläufe wieder passiert, unbeaufsichtigt, in dem Rhythmus, den du einstellst? Wenn ja, bist du bereit – schalte es ein. Wenn du nur deshalb damit einverstanden bist, weil du diese drei Läufe persönlich geprüft hast, bevor irgendetwas nachgelagert passiert ist, ist das ein echtes Signal, und es bedeutet, dass es die richtige Entscheidung ist, noch etwas länger manuell zu bleiben, nicht ein Versagen der Nerven.
Angesichts deiner aktuellen Situation – drei Domains gerade migriert, Zeiten noch nicht vollständig eingestellt – würde ich noch ein paar Tage mit autonom warten. Behebe die beiden verbleibenden Zeitpläne, sieh zu, wie der morgige Sync zur richtigen Stunde landet, führe die Optimierung noch zwei- oder dreimal manuell aus, sodass du wirklich einmal von Anfang bis Ende gesehen hast, was sie tut. Dann plane sie ein. Die obigen Fragen zur Frequenz lassen sich mit einem echten Lauf vor Augen deutlich leichter beantworten als abstrakt, und es kostet nichts, eine Woche zu warten, um dahin zu kommen.
