gergobalogh/launch-check

Startcheck: Ist diese Seite bereit?

Am Starttag kommt das meiste Publikum einer Seite – eine Korrektur am zweiten Tag erreicht die meisten nicht mehr. Machen Sie es richtig, bevor der Beitrag rausgeht.

Diese Checkliste gilt für jede Seite. Halten Sie sie frei von Seitennamen und Seitendaten: Schreiben Sie hier eine neue Lektion als allgemeine Regel und behalten Sie die Seite und ihre Zahlen in den eigenen Notizen des Projekts.

So führen Sie es aus

1. Nennen Sie die Seite. Ihren Typ (Artikel oder Geschichte, Werkzeug oder Spiel, Hub), ihren Zweck in einem Satz und ihre Schritte: angekommen → nutzbar → erste Verwendung → Hauptaktion → es hat geklappt → nächster Schritt. Reduzieren Sie nicht zutreffende Schritte. Fügen Sie keine Eingaben, Zahlen oder Aktionen hinzu, nur um eine Prüfung zu erfüllen.
2. Stellen Sie einen lokalen Build bereit (dist/ oder den Dev-Server) mit blockiertem Analytics. Öffnen Sie niemals die Live-Seite.
3. Gehen Sie jede Prüfung auf den vier Bildschirmen unten durch. Markieren Sie jede als bestanden, fehlgeschlagen, unverifiziert oder N/V mit einem Grund. Bei einer Prüfung, die eine Beurteilung erfordert, schreiben Sie, was Sie gesehen haben (den wiedergegebenen Satz, den Screenshot, den Sie betrachtet haben), nicht nur „bestanden".
4. Blocker: Beheben Sie ihn oder holen Sie den ausdrücklichen Verzicht des Benutzers ein und verifizieren Sie ihn, falls unverifiziert. Empfehlung: Melden Sie sie; sie stoppt den Start nicht.
5. Schreiben Sie das Ergebnis in die Notizen oder das Aufgabenboard des Projekts, wobei alle 29 Prüfungen gezählt werden: Startcheck: 25 bestanden, 1 fehlgeschlagen, 1 unverifiziert, 2 N/V; Blocker: U1 fehlgeschlagen; Empfehlung: S3 unverifiziert; N/V: U2 (keine Eingabe), U3 (keine Wartezeiten).

Bildschirme: Telefon 390×844, Tablet 820×1180, Laptop 1366×768, großer Desktop 1920×1080. Überprüfen Sie jeden; ein breites Layout verschiebt Dinge genauso wie ein schmales. Bestätigen Sie Layoutfehler in einem Screenshot, da die Quelle allein sie nicht zeigen kann.

Browser: Ein kopfloses Chromium (Playwright) ist ausreichend, da ein lokaler Build kein Login benötigt. Blockieren Sie vor dem Laden der Seite Ihren Analytics-Host auf diesem Tab (page.route(/your-analytics-host/, r => r.abort())), damit die Prüfungen nie als Besuche gezählt werden.

Nach Seitentyp:

• Artikel oder Geschichte: Weiterzuscrollen ist der nächste Schritt, daher ist U2 N/V, und U3, wenn nichts wartet.
• Werkzeug oder Spiel: T2 deckt den gesamten Text der Seite ab; die erste Verwendung muss ein echtes Ergebnis liefern.
• Hub: Der Nutzen liegt darin, das Richtige zu finden, daher bedeutet T1, dass jeder Link das tut, was er verspricht.

Hook

• H1 · Blocker. Vom ersten Bildschirm allein, in jeder Größe, können Sie in einem Satz sagen, was der Besucher bekommt. Den Nutzen, nicht das Thema. Schreiben Sie diesen Satz auf. Wenn Sie ihn nicht schreiben können oder er nur den Gegenstand nennt, ist dies fehlgeschlagen.
• H2 · Empfehlung. Der erste Bildschirm gibt einem Fremden einen Grund weiterzumachen: einen bestimmten Fund, eine Zahl, ein Ergebnis oder eine Frage, und zwar eine wahre. Es sollte immer noch für jemanden funktionieren, der ohne Kontext von einem Beitrag kommt.
• H3 · Empfehlung. Die Linkvorschau macht dasselbe Versprechen. og:image, Titel und Beschreibung sagen den Nutzen. Überprüfen Sie die Tags und das Bild im Build.
• H4 · Blocker. Die erste Aktion ist ohne Scrollen in jeder Größe sichtbar und sieht eindeutig wie eine aus, mit ausreichendem Kontrast. Bei einer Scroll-Geschichte ist die erste Aktion der Scroll: ein sichtbares Scroll-Hinweiszeichen gilt als bestanden.

Body

• T1 · Blocker. Der Body liefert, was der Hook versprochen hat, und zwar früh. Der Nutzen wartet nicht bis zum Ende. Wenn die Seite lang ist, kommt zuerst eine Kurzversion und der Rest ist die Wahl des Besuchers.
• T2 · Blocker. Es liest sich von Anfang bis Ende gut. Lesen Sie alles der Reihe nach, wie ein Fremder es tun würde. Jeder Teil folgt aus dem vorherigen und fügt etwas hinzu, nichts ist Füllmaterial, und Sie können das Ganze in einem Satz nacherzählen.
• T3 · Empfehlung. Ein Hauptpunkt oder eine Hauptzahl pro Bildschirm. Der Rest kommt in eine Tabelle oder hinter „mehr". N/V, wenn die Seite keine Zahlen oder Ergebnisse präsentiert.
• T4 · Blocker. Jede Zahl und Behauptung hat eine Quelle, und alles Verborgene funktioniert. Öffnen Sie jede Schublade, jeden Tab und jedes Akkordeon und folgen Sie jedem Quelllink. Ein geschlossener Abschnitt ist immer noch Teil der Seite.
• T5 · Empfehlung. Der Text entspricht den Stilregeln des Autors und besteht einen KI-Schreib-Erkennungscheck, ohne Platzhalter-, Entwurfs- oder Debug-Text. Der Seitentext erscheint unter dem Namen des Benutzers, also melden Sie Probleme und fragen Sie; formulieren Sie nicht allein um.

Screens

• S1 · Blocker. Es sieht auf allen vier Bildschirmen und in jedem Schritt richtig aus. Machen Sie nach jedem Schritt einen Screenshot und betrachten Sie jeden: nichts abgeschnitten, überlappend oder ungestylt (Skript-erstellte Elemente können bereichsbezogenes CSS verpassen), kein seitlicher Scroll. Nach einer Suche oder Auswahl, die eine Karte bewegt, überprüfen Sie, ob das Ergebnis in dem Teil landet, der nicht von einem Panel abgedeckt wird, in jeder Größe.
• S2 · Blocker. Der gesamte Text ist in seiner gerenderten Größe lesbar. Messen Sie ihn, beurteilen Sie nicht mit dem Auge, und zielen Sie auf 12 px oder mehr. Für SVG-Diagramme: Schriftgröße × gerenderte Breite ÷ viewBox-Breite.
• S3 · Empfehlung. In unter 2 s auf einem Telefon nutzbar. Nutzbar bedeutet den frühesten Zeitpunkt, an dem die erste Aktion funktioniert. Messen Sie ab dem Start des Ladens, mit kaltem Cache und einem angegebenen Telefon-CPU- und Netzwerkprofil. Ein nicht gedrosselter Desktop-Lauf kann kein Telefon-Bestehen zeigen.
• S4 · Blocker. Langsames und fehlgeschlagenes Laden sehen beide richtig aus. Testen Sie langsame Netzwerke (CDP Network.emulateNetworkConditions, 9 / 1,6 / 0,75 / 0,4 Mbit/s) und einen fehlgeschlagenen Ladevorgang. Servieren Sie mit Komprimierung wie das CDN für Zeitmessungen; ein unkomprimierter lokaler Server übertreibt jede Wartezeit. Machen Sie alle 0,5 s über jeden Ladeübergang hinweg einen Screenshot von einem Kaltstart aus und betrachten Sie die Frames. Halten Sie das letzte gute Bild mit einem Ladelabel oben; ein Fallback ist nur für Fehler. Labels müssen während des Ladens und nach einem Fehler korrekt sein. N/V, wenn nichts spät lädt.

Verwendung

• U1 · Blocker. Nach jedem Schritt ist das nächste Steuerelement auf dem Bildschirm in jeder Größe sichtbar, dort, wo die Seite den Besucher zurücklässt. Testen Sie jeden Weg in einen Schritt separat (Beispiel, getippt, angetippt). Überprüfen Sie jedes Scroll-Ziel, jede klebrige Kopfzeile und den Falz.
• U2 · Empfehlung. Es gibt einen Ein-Tipp-Zugang (ein Beispiel oder eine Voreinstellung) neben jeder Freiform-Eingabe, und das Ereignis sagt, welcher verwendet wurde. N/V ohne Freiform-Eingabe.
• U3 · Blocker. Jede Wartezeit über 2 s zeigt Fortschritt an und endet in einem klaren Ergebnis oder einem klaren Fehler. Treiben Sie lokal eine verzögerte und eine fehlgeschlagene Antwort. Ein Spinner, der nie endet, gilt als fehlgeschlagen. N/V, wenn keine Aktion wartet. Ein Steuerelement, das angezeigt wird, bevor sein Skript geladen wurde (ein Formular für eine faule Karte), muss funktionieren oder in die Warteschlange gestellt werden: Verwenden Sie es während des Ladens und nach einem fehlgeschlagenen Ladevorgang. Eine nicht behandelte Formularübermittlung lädt die Seite neu.

Nächster Schritt

• N1 · Empfehlung. Im Moment des Erfolgs gibt es einen klaren nächsten Schritt: eine verwandte Seite, versuchen Sie eine andere, noch einmal spielen. Platzieren Sie ihn dort, wo der Erfolg eintritt, nicht in der Fußzeile.
• N2 · Empfehlung. Teilen-Buttons, die den Fund senden: WhatsApp, Facebook, X und Link kopieren, jeder trägt einen geschriebenen Satz mit dem Fund, nicht nur den Titel, platziert, wo das Ergebnis erscheint. Der Satz ist öffentlicher Text, also formuliert ihn der Benutzer: Fragen Sie. Ein Hub ohne Fund benötigt trotzdem einen Satz vom Benutzer. Erfinden Sie keinen oder markieren Sie dies nicht allein als N/V. Das share-Ereignis sendet nur das Netzwerk, niemals den Text oder die URL.

Suche

Googles KI-Antworten (AI Overviews, AI Mode) beziehen Seiten aus dem normalen Suchindex: Eine Seite, die mit einem Snippet rankt, kann zitiert werden, und es ist keine reine KI-Datei oder ein Markup erforderlich. Strukturierte Daten müssen mit dem übereinstimmen, was die Seite zeigt.

• F1 · Blocker. Die Seite kann indexiert werden: eine kanonische Adresse, kein versehentliches noindex, in der Sitemap aufgeführt. Eine zu dünne Seite zum Ranken (ein Stub, der nur auf andere verweist, eine leere Liste) wird stattdessen von der Suche ferngehalten: noindex und nicht in der Sitemap, ohne dass eine andere Sprachversion darauf verweist.
• F2 · Empfehlung. Der Titel sagt, was die Seite enthält, nicht nur der Seitenname allein, mit dem Namen am Ende; die Beschreibung ist die eigene der Seite und erscheint auf keiner anderen Seite.
• F3 · Empfehlung. Eine sichtbare Zeile sagt, wer es gemacht hat, wann es veröffentlicht wurde und wie aktuell seine Daten sind, mit demselben Veröffentlichungsdatum in den strukturierten Daten. Ändern Sie das Änderungsdatum nur, wenn sich der Inhalt tatsächlich ändert. N/V für einen Hub.
• F4 · Blocker. Jedes Bild im HTML hat eine Quelle und echten Alt-Text, einschließlich Figuren, die nur ohne JavaScript angezeigt werden. Ein leeres <img> gilt als fehlgeschlagen.
• F5 · Empfehlung. Eine datenbasierte Seite bietet die Daten an: eine CSV nach einer Datenschutzprüfung (nur die Felder, die die Seite bereits zeigt), eine Lizenzzeile neben dem Download und Dataset-Markup. Ein Video erhält VideoObject-Markup mit einem Poster. N/V, wenn die Seite keines von beidem hat.

Nach dem Start: Beantragen Sie die Indexierung der Seite in der Search Console (das Konto des Benutzers, also fragen Sie) und fügen Sie die Frage, die sie beantwortet, zur KI-Antwort-Fragenliste des Projekts hinzu, falls es eine führt.

Messung

Die Prüfungen gehen von einem datenschutzfreundlichen Ereignis-Tracker (Umami, Plausible oder ähnlich) mit benutzerdefinierten Ereignissen aus.

• M1 · Blocker. Die Ereignisse sind im Build, der startet. Ein Ereignis pro anwendbarem Schritt, eines pro Aktion, Erfolg ist die Wirkung und nicht der Klick, und ein *-leave-Ereignis gibt den weitesten Schritt und die Zeit im Blickfeld an.
• M2 · Blocker. Die Ereignisse feuern durch den echten Tracker. Eine gestubte Tracker-Funktion kann verlorene Ereignisse verbergen. Führen Sie den echten Tracker auf dem Produktionshostnamen aus, wobei context.route den lokalen Build bedient und den Sende-Endpunkt des Trackers abfängt, sodass nichts die Maschine verlässt. Steuern Sie jedes Steuerelement, auch Sprunglinks: Jedes Ereignis beschreibt seine Aktion, ein Fehler sendet keinen Erfolg, und ein Sprung über Inhalt hinweg sendet kein Leseereignis. Folgen Sie einem verfolgten ausgehenden Link im selben Tab und überprüfen Sie, ob das *-leave-Ereignis immer noch ankommt: Eine Anfrage, die während des Entladens der Seite gestartet wurde, kann verloren gehen, daher öffnen solche Links in einem neuen Tab.
• M3 · Blocker. Ereignisse sind im docs/analytics.md des Projekts aufgelistet mit der Go-Live-Zeit, und eine Trichter-Spezifikation befindet sich in docs/funnels/ (das Speichern im Analyse-Tool benötigt das Ja des Benutzers).
• M4 · Blocker. Nichts, was ein Besucher getippt oder ausgewählt hat, wird an Analytics gesendet: kein Hash in Seitenaufrufen (den Hash ausschließen), kein Abfragetext, keine Orte. Nur feste Labels und Buckets.
• M5 · Blocker. Ziele werden vor dem Start aufgeschrieben (eine Zahl pro Schritt, die Sie erreichen erwarten), damit die Überprüfung nach dem Start einen Vergleich hat.
• M6 · Blocker. Agents bleiben von der Live-Seite fern, da ihre Besuche als echter Traffic gezählt werden. Ein Prüfskript, das auf die Live-Seite zeigen kann, muss selbst Analytics blockieren.