Post-Launch (Überwachung nach dem Umzug)

Post-Launch

Die Überwachung. Sie läuft, sobald DNS umgezogen ist, und dann einmal täglich für dreißig Tage. Sie berichtet; sie blockiert nie, repariert nie und kündigt nie etwas an.

Die eine Regel

Blocker werden zuerst gelesen und zuletzt angekündigt. Nichts über einen Launch wird angekündigt – keine E-Mail, kein Post, kein Kundengespräch – bevor dieser Report sauber zurückkommt. Eine Ankündigung ist der einzige Schritt eines Launches, der nicht rückgängig gemacht werden kann, und die beiden Blocker hier sind exakt die beiden Zustände, in denen der Launch nicht wirklich stattgefunden hat: ein Zertifikat, an dem niemand vorbeikommt, und ein Noindex, das Suchmaschinen anweist, die Site zu vergessen. Beide sehen in einem Browser, in dem man bereits eingeloggt ist, normal aus.

Wenn jemand dich bittet, anzukündigen, während ein Blocker besteht, sag klar, was der Blocker ist und was er kostet, und mach es nicht weich.

Nur lesend

Die Skill ist nur lesend. Sie ruft die Live-Site, den Staging-Host, den alten Host und die URLs in der Redirect-Map ab, und fragt vier öffentliche DNS-Resolver, wohin die Domain zeigt. Sie schreibt genau zwei Dinge, beides eigene Aufzeichnungen des Operators: das Report-Bundle und watch.json darin. Sie editiert nie eine Site, sendet nie ein Formular ab, schaltet nie eine Einstellung um, ruft nie eine Provider-API auf und berührt nie DNS.

Es folgen drei Regeln, und du wiederholst sie, wenn du berichtest:

1. Beleg für jeden Befund. Eine URL, ein Status, ein Header, eine DNS-Antwort, eine CSV-Zeile.
2. Ein Überspringen ist kein Bestehen. Jede Eingabe, die du nicht geliefert hast, wird zu einer benannten Zeile in Nicht abgedeckt.
3. Nicht abgedeckt ist nie ein Bestehen. Du wiederholst diesen Abschnitt dem Menschen wörtlich.

Die zwei Modi

Modus	Wann	Was er beantwortet
--mode cutover	in dem Moment, in dem DNS umgezogen ist, und nach jeder Reparatur	ob der Launch tatsächlich stattgefunden hat
--mode watch	einmal täglich, Tage 1–30	was heute fällig ist und ob etwas abgewichen ist

Führe cutover zuerst aus, behebe, was es findet, führe es erneut aus, bis es sauber ist, dann kündige an. Starte die Überwachung am selben Tag.

1. Sammle die Eingaben

Jede Eingabe, die du auslässt, wird zu einer Prüfung, die nicht ausgeführt werden kann. Frage nach jeder; rate nicht.

• Die Produktions-URL. Erforderlich.
• baseline.json – aus dem pre-launch-Bundle oder aus einem launch-audit-Lauf gegen Staging vor dem Umzug. Das ist der Maßstab für „hat sich etwas geändert“. Ohne sie haben vier Prüfungen nichts zum Vergleichen und eine fünfte fällt auf --expect-analytics zurück. Alle sagen das.
• redirects.csv – aus dem mit --old-url erstellten launch-audit-Bundle. Jede Zeile wird an der URL, mit der sie geschrieben wurde, erneut angefordert.
• Die URL der alten Site, wenn eine ersetzt wird.
• Die Staging-URL, damit der Lauf bestätigen kann, dass die Staging-Kopie jetzt versiegelt ist.
• Die Analytics-Mess-ID, für den Fall, dass es keine Baseline gibt.
• Die DNS-Einträge, die vorhanden sein sollten, als apex= und www=-Werte.

Wenn du die Baseline oder die Redirect-Map nicht hast, sag das vor dem Lauf, nicht danach: Sie stammen aus den beiden früheren Phasen, und nach dem Umzug kann keine von beiden neu erstellt werden.

2. Führe die Cutover-Prüfung aus

Führe das Skript aus; lies niemals seinen Quellcode und implementiere nie neu, was es tut.

node scripts/post-launch.mjs --mode cutover --url <produktion-url> \
  --baseline <pfad zu baseline.json> --redirects <pfad zu redirects.csv> \
  --old-url <alte site url> --staging-url <staging url> \
  --expect-analytics <mess-id> --expect-dns apex=<ip>,www=<host> --out <verzeichnis>

Der Pfad ist relativ zum eigenen Verzeichnis der Skill – führe den Befehl von dort aus. Das Bundle wird unter dem aktuellen Arbeitsverzeichnis geschrieben: ohne --out landet es in ./website-launch/<host>-post-launch-<datum>/, was mit dem obigen Befehl innerhalb des eigenen Verzeichnisses der Skill bedeutet. Schreibe das Bundle mit --out dorthin, wo die Arbeit lebt.

Weitere Flags: --dev-host <host> (wiederholbar), --browser auto|on|off, --out <verzeichnis>, --config <pfad>, --json, --help.

Exit-Codes: Immer 0, egal wie schlecht der Umzug ist. 2 für einen Verwendungsfehler oder einen E/A-Fehler. Exit 0 bedeutet nie „der Launch ist in Ordnung“ – dies berichtet, es blockiert nicht. Lies den Report.

3. Lese den Report in dieser Reihenfolge

references/reading-the-report.md enthält das Bundle-Layout. references/cutover-day.md erklärt, warum der Tag in der Reihenfolge läuft, in der er läuft – lies es, bevor du anfängst, Dinge außer der Reihe zu reparieren.

1. Die Blocker. Fettgedruckt, als erstes, egal aus welchem Schritt des Tages sie stammen. Repariere diese vor allem anderen und bevor jemand erfährt, dass die Site live ist.
2. Die hohen Befunde. Redirect-Drift, eine fehlende Seite, ein toter Formular-Endpunkt, eine live geschaltete Staging-Kopie, der alte Host, der noch bedient – jedes dieser Dinge verliert jetzt Traffic oder Anfragen. Sie sind die heutige Arbeit, nicht die dieser Woche.
3. Der Baseline-Diff. references/baseline-diff.md sagt, welche Felder sich bei einem Launch voraussichtlich ändern und welche nie. Melde nicht den gesamten Diff als Schaden; melde die Teile, um die niemand gebeten hat.
4. Mittel und Info. Lies sie. Sag, was sie sind. Repariere sie heute nicht.
5. Nicht abgedeckt, wörtlich. Jede Zeile, unbearbeitet, einschließlich der beiden Dinge, die kein Crawl sehen kann.

Dann führe erneut aus, und führe immer wieder aus, bis die Blocker verschwunden sind.

4. Arbeite die sechs menschlichen Punkte ab

Sie werden am Ende jedes Laufs ausgegeben und sind nicht optional:

Sitemap einreichen (Search Console und Bing)   ·   Indexierung für die Top-Seiten anfordern
die neue Search Console-Property bestätigen    ·   Analytics in Echtzeit überprüfen
den alten Host am Laufen halten und weiterleiten   ·   erst ankündigen, wenn dies sauber ist

Hake niemals etwas im Namen einer anderen Person ab. „Der Endpunkt hat 200 zurückgegeben“ ist nicht „eine Person hat die Test-Übermittlung erhalten“, und „das Tag ist im HTML“ ist nicht „ein Hit ist in Echtzeit erschienen“.

5. Führe die tägliche Überwachung aus

node scripts/post-launch.mjs --mode watch --url <produktion-url> --day <n>

Es gibt aus, was überfällig ist, was heute fällig ist und was in den nächsten sieben Tagen kommt, dann führt es den automatisierten Teil erneut aus und zeichnet den Lauf auf. references/thirty-day-watch.md enthält den gesamten Zeitplan, worauf in der Search Console und in Analytics an jedem Tag zu achten ist, und wie „gesund“ aussieht, damit ein normaler Post-Launch-Einbruch nicht als Katastrophe gemeldet wird.

Lasse --day weg und es zählt ab dem ersten Lauf. Ein Tag, an dem die Überwachung nie lief, bleibt für die automatisierten Aufgaben überfällig, bis ein Lauf ihn abdeckt; eine menschliche Aufgabe bleibt überfällig, bis ein Mensch sie erledigt, weil nichts, was ein Skript tut, ein Beleg dafür ist, dass jemand die Search Console geöffnet hat.

6. Tag 30

Zwei Dinge, und keins davon ist automatisiert:

• Die Retrospektive. Was ist zurückgegangen, was hat die Redirect-Map übersehen, und was sollte zum pre-launch-Gate hinzugefügt werden, damit der nächste Launch es nicht wiederholt. Schreibe es auf.
• Die Entscheidung zum alten Host. Der alte Host darf erst außer Betrieb genommen werden, wenn die Search Console kein Crawlen alter URLs mehr zeigt und die Weiterleitungen seit mindestens dreißig Tagen in Kraft sind. Erst wenn beides zutrifft, bezahle weiter dafür. Es frühzeitig abzuschalten, wirft jeden Link weg, den die alte Site verdient hat.

7. Präsentiere das Ergebnis

Führe mit der Entscheidung an, nicht mit einer Zählung.

1. Das Urteil. „Der Umzug hat einen Blocker“ oder „Der Umzug ist sauber.“ Ein Satz.
2. Was ihn blockiert, mit der benannten Reparatur.
3. Was blutet, gruppiert nach Ursache: die hohen Befunde, in einfacher Sprache.
4. Was sich gegenüber der Baseline geändert hat, um das niemand gebeten hat.
5. Nicht abgedeckt, wörtlich.
6. Die menschlichen Punkte, mit dem, was erledigt ist und was nicht.
7. Ob der Launch angekündigt werden darf. Sage es explizit, so oder so.

Die zwei Prüfungen, die nie laufen

• Kopie vs. Quellendokumente. Nichts vergleicht die Wörter auf den Live-Seiten mit der freigegebenen Kopie. Eine Person muss beide lesen.
• Seiten vs. vereinbarter Umfang. Nichts weiß, welche Seiten existieren sollten. Eine Seite, die nie gebaut wurde, ist hier unsichtbar.

Referenzen

Datei	Deckt ab
references/cutover-day.md	Das geordnete Tages-Skript und warum jeder Schritt dort sitzt, wo er sitzt
references/thirty-day-watch.md	Der Zeitplan, was in der Search Console und in Analytics zu lesen ist, wie gesund aussieht, die alte-Host-Regel
references/baseline-diff.md	Jedes Diff-Feld, welche Änderungen bei einem Launch erwartet werden und welche nicht
references/reading-the-report.md	Das Bundle, die Schweregrade, die IDs, wie man priorisiert

Wo dies sitzt

pre-launch kontrolliert das Repository vor dem Deployment und blockiert. launch-audit crawlt eine Staging- oder Live-URL und berichtet. post-launch ist dieses hier: der Umzug und die dreißig Tage danach. Führe sie in dieser Reihenfolge aus – die Baseline und die Redirect-Map, die diese Skill benötigt, können nur von den ersten beiden erstellt werden, und nur, während die alte Site noch online ist.