SEO Landing — PageSpeed 100 + Schema-Ship

SEO Landing Generator

Erstellt eine statische Single-Page-HTML-Landingpage, optimiert für 100/100 PageSpeed und maximale SEO: kritisches CSS, AVIF-Bilder, vollständige JSON-LD-Strukturierte-Daten, native Interaktivität, null externe Drittanbieteranfragen beim ersten Laden.

Wann verwenden

• Der Benutzer fordert eine Landingpage / One-Pager an, der auf Geschwindigkeit und SEO ausgerichtet ist → generate-Modus.
• Der Benutzer liefert ein Briefing (ТЗ) und wünscht eine produktionsreife statische Seite → generate-Modus.
• Der Benutzer bittet um eine Überprüfung einer bestehenden Landingpage gemäß der Checkliste, ohne Änderungen → audit-only-Modus (§0b, schreibgeschützt, keine Projektdateien).
• Der Benutzer bittet um die Behebung/Verbesserung einer bestehenden Landingpage → fix-existing-Modus (§0c).

Verfahren

0. Leiten Sie die Anfrage zuerst einem Modus zu

Der Skill bietet drei Modi – wählen Sie einen basierend auf der Anfrage aus (bei Unklarheit nachfragen), da jeder Modus unterschiedliche Eingaben sammelt und unterschiedliche Ausgaben erzeugt:

• generate – Erstellt eine neue Landingpage aus einem Briefing („Erstelle/Erzeuge/Generiere eine Landingpage…“). Führt das vollständige untenstehende Verfahren aus.
• audit-only – Schreibgeschützte Inspektion einer bestehenden Seite („Überprüfe/Kontrolliere/Bewerte diese Landingpage gemäß der Checkliste…“, keine Änderungen gewünscht). Führt §0b aus. Schreibt niemals Projektdateien.
• fix-existing – Wendet gezielte Korrekturen auf eine bestehende Seite an („Repariere/Verbessere/Optimiere diese Seite…“). Führt §0c aus.

Repräsentatives Routing:

• „Erstelle eine Landingpage für eine Zahnarztpraxis aus diesem Briefing“ → generate.
• „Überprüfe https://example.com/ gemäß der Performance-Checkliste und melde, was falsch ist“ → audit-only.
• „Das Hero-Bild dieser Landingpage verschiebt sich beim Laden – repariere es“ → fix-existing.

Felder des Generation-Only-Briefings (Ziel-Keywords, Unternehmenstyp, CTA, Medienangaben) werden NUR für die Generierungs- und Wiederaufbauarbeit gesammelt. Ein Audit oder eine gezielte Korrektur darf nicht durch fehlende Generierungseingaben blockiert oder verzögert werden, und der Audit-Only-Modus darf keine Projektdateien erstellen oder ändern.

0a. Briefing erfassen (Generate-Modus; bei Fehlen nachfragen)

Erforderlich vor der Generierung:

• Domain / finale URL – für canonical, og:url, absolute Pfade, JSON-LD @id.
• Seitenidentität (für WebSite-Markup, nur wenn die Seite die Homepage der Domain/Subdomain ist): bevorzugter Seitenname, optionale Alternativnamen und die kanonische Home-URL – getrennt von der Landing-URL erfasst.
• Breadcrumb-Pfad (für BreadcrumbList-Markup, nur wenn eine echte Seitenhierarchie existiert): der sichtbare Breadcrumb-Pfad und kanonische Eltern-URLs.
• Seitensprache, Basis-Schreibrichtung und Open-Graph-Locale – drei separate Eingaben, niemals ein Wert über Formate hinweg kopiert: ein BCP-47-Sprach-Tag für <html lang> (z.B. en-US, ar-SA), die Basis-Schreibrichtung (ltr/rtl – RTL-Dokumente erhalten dir="rtl" auf <html>, und lang allein setzt keine Schreibrichtung), und das Open-Graph-Locale im Format language_TERRITORY für og:locale (z.B. en_GB). Fragen Sie, wenn die Richtung für eine RTL-fähige Sprache unbekannt ist (Technische Spezifikation §2).
• Thema + 1–3 Ziel-Keywords – für H1, Titel, Beschreibung.
• Unternehmenstyp: Organization oder LocalBusiness. Für LocalBusiness erfassen Sie den verifizierten öffentlichen/rechtlichen Geschäftsnamen und die vollständige strukturierte Postanschrift (Straße, Ort, Region, Postleitzahl, Land), plus Telefonnummer und Geokoordinaten. Erfassen Sie auch die verifizierten Schema.org-Untertyp(en) basierend auf dem tatsächlichen Unternehmen (z.B. Restaurant, Dentist, HardwareStore) – niemals aus Ziel-Keywords ausgewählt. Erfinden Sie niemals fehlende Identitätsangaben: Fallen Sie auf Organization-Markup zurück oder lassen Sie das Entitäts-Markup weg, bis die Fakten bereitgestellt werden.
• CTA und Kontakte (Telefon, Formular, Messenger). Wenn ein Formular angefordert wird, erfassen Sie auch dessen Einreichungsziel und -methode (ein First-Party-Endpunkt oder ein dokumentierter Formulardienst – niemals erfunden), den erforderlichen Zustimmungs-/Datenschutztext für die gesammelten personenbezogenen Daten, und wo die Einreichungen gespeichert werden und wem sie gehören; ohne Ziel wird das Formular weggelassen oder explizit als Platzhalter eingefügt (Technische Spezifikation §10 Formulareinreichungsvertrag).
• Ein von der Marke genehmigtes Favicon oder die ausdrückliche Erlaubnis, eines zu erstellen – erfinden Sie niemals stillschweigend ein Markenzeichen.
• Genehmigtes Quellenmaterial und ein Anspruchsinhaber für objektive Marketing-Fakten (Zahlen, Preise, Qualifikationen, Garantien, Vergleiche, Fallstudien) – ohne diese werden solche Behauptungen weggelassen, niemals erfunden.
• Ob Bilder bereitgestellt werden; ob FAQ / Bewertungen / Video-Blöcke benötigt werden. Für einen Video-Block sammeln Sie quellengestützte Fakten: Video-URL/ID, Titel, Beschreibung, genaues Datum/Zeit der Erstveröffentlichung mit Zeitzone und ein eindeutiges, crawlbareres Vorschaubild (plus contentUrl, falls zutreffend). Erfinden Sie niemals fehlende Medienangaben. Sammeln Sie auch den Video-Modus mit dessen Kompromissen: Klick-Only-Fassade (Standard – Datenschutz/Performance; die Seite erfüllt nicht die Google-Anforderungen zur Video-Entdeckung und es wird kein Video-Suchvorteil beansprucht) oder SEO-auffindbar (selbst gehostetes <video> oder ein dokumentierter direkter Embed – erforderlich, wenn Video-Suchverkehr wichtig ist) (Technische Spezifikation §9).

Wenn Domain oder Keywords fehlen – fragen Sie zuerst nach, erfinden Sie sie nicht.

0b. Audit-Only-Modus (schreibgeschützt)

Überprüfen Sie eine bestehende Seite, ohne einen Ersatz zu generieren. In diesem Modus werden keine Projektdateien erstellt oder geändert – das Ergebnis ist ein Bericht.

1. Identifizieren Sie das Ziel: eine bereitgestellte URL (bevorzugt – ermöglicht die Ausführung aller Prüfungen gegen die Realität) oder lokale HTML-Dateien. Wenn keines bereitgestellt wird, fragen Sie nach; raten Sie niemals das Ziel.
2. Führen Sie die anwendbaren Prüfungen aus §5 gegen das Ziel durch: W3C-Gültigkeit, Vorhandensein lokaler Assets (bei lokalen Dateien), JSON-LD über einen Schema.org-Validator, Lighthouse gegen die bereitgestellte/veröffentlichte URL, Crawlbarkeitsvertrag (robots.txt + sitemap.xml auf dem bereitgestellten Host) und die manuellen Barrierefreiheitsprüfungen aus Technische Spezifikation §8.
3. Berichten Sie Belege pro Prüfung: Bestanden/Nicht bestanden mit dem gemessenen Wert oder beobachteten Markup und dem genauen Befehl/Werkzeug, das verwendet wurde. Wenn eine Prüfung nicht durchgeführt werden kann (keine bereitgestellte URL für Lighthouse, keine robots.txt auf dem Host), melden Sie einen Blocker für diese Prüfung – schätzen Sie nicht, extrapolieren Sie nicht und lassen Sie es nicht stillschweigend aus.
4. Unterscheiden Sie Syntax-Gültigkeit von Google-Funktionseignung (FAQPage, VideoObject, Rich Results): gültiges Markup wird als gültiges Markup gemeldet, niemals als erreichtes Suchfeature.
5. Optional mit einer priorisierten Fehlerbehebungsliste beenden. Das Anwenden von Korrekturen ist eine separate fix-existing-Anfrage – beginnen Sie nicht mit der Bearbeitung ohne diese.

0c. Fix-Existing-Modus

Wenden Sie gezielte Korrekturen auf eine bestehende Seite an, ohne einen vollständigen Neubau.

1. Identifizieren Sie die Seite/Dateien und die spezifischen Probleme, die behoben werden sollen; sammeln Sie nur die Eingaben, die diese Korrekturen benötigen (niemals das vollständige Generierungs-Briefing).
2. Wenden Sie jede Korrektur gemäß dem relevanten Abschnitt der technischen Spezifikation an, wobei nicht betroffenes Markup und Inhalt erhalten bleiben.
3. STOPP-PUNKT (§4): Zeigen Sie die geänderte Seite vor der Validierung an. Wenn Korrekturen das ändern, was der Benutzer zuvor genehmigt hat, holen Sie eine erneute Genehmigung ein, bevor Sie berichten.
4. Validieren Sie die geänderte Seite (§5) und berichten Sie nur gemessene Belege.

Generierungs-Workflow (Generate-Modus)

1. Projektordner erstellen

Jedes Projekt lebt in einem eigenen Ordner innerhalb des Workspace – schreiben Sie niemals in den Workspace-Root. Die Ausgabe ist ein Multi-File-Projekt: Jede lokale Ressource, auf die das HTML verweist, muss als echte Datei existieren.

<workspace>/<project-slug>/
  index.html        # die generierte Landingpage
  styles.css        # nur wenn CSS unter dem Falz verschoben wird (§1); fehlt, wenn alles CSS inline ist
  script.js         # nur wenn die Seite JS verwendet (§10); einzelne Datei, defer
  images/           # jede in src/srcset/preload/OG-Tags referenzierte Bildvariante (AVIF/WebP/JPEG, alle Breakpoints)
  favicon.png       # stabiles quadratisches Markensymbol, ≥48×48
  ASSETS.md         # Rechte- und Herkunftsnachweis für jedes Asset
  robots.txt
  sitemap.xml
  SERVER-SETUP.md   # Hosting-Anweisungen

Bild-Zweig:

• Im Briefing bereitgestellte Bilder → alle erforderlichen Varianten (AVIF/WebP/JPEG bei jedem in srcset genannten Breakpoint) daraus erzeugen.
• Keine Bilder verfügbar → vom Benutzer anfordern oder das Bild/den Block weglassen. Geben Sie niemals eine scheinbar erfolgreiche Asset-URL aus, ohne die Datei zu erzeugen oder ausdrücklich danach zu fragen – eine referenzierte, aber fehlende Datei ist ein Generierungsfehler, kein Platzhalter.

2. Seite generieren

Erstellen Sie index.html streng nach references/tech-spec.md – 13 Anforderungsabschnitte (Performance, HTML-Struktur, SEO, Sicherheit, CSS/Schriftarten, Verbotsliste, Testen, Barrierefreiheit, Eingebettetes Video, Typische Blöcke, Verzögerte Widgets, Wahrheitsgehalt des Inhalts und Herkunft, Eingabebereinigung und Ausgabekodierung).

Behandeln Sie jeden Briefing-Wert als nicht vertrauenswürdig: kodieren Sie ihn für seinen genauen Ausgabekontext (HTML-Text, Attribut, URL, JSON-LD), verwenden Sie eine Positivliste für URL-Schemata (lehnen Sie javascript:/unerwartete data: ab), escapen Sie < in serialisiertem JSON-LD und validieren Sie strukturierte IDs (z.B. YouTube ^[A-Za-z0-9_-]{11}$), bevor sie in einer URL landen (Technische Spezifikation §13).

Für eingebettete YouTube-Videos verwenden Sie standardmäßig das Fassadenmuster; der SEO-auffindbare Modus (selbst gehostetes <video> oder ein dokumentierter direkter Embed) ist eine explizite Briefing-Entscheidung mit einem offengelegten Kompromiss, niemals ein stillschweigender Wechsel – Regeln und die Google-Entdeckungsanforderungen in Technische Spezifikation §9, Fassaden-Referenzimplementierung in references/video-facade.md. Karten folgen nur dem Fassadenmuster (Technische Spezifikation §10): ein lokaler Screenshot im initialen DOM, das Iframe wird nur bei expliziter Aktivierung eingefügt – niemals ein natives loading="lazy" Karten-Iframe. Referenz: references/map-facade.md.

3. Begleitdateien generieren

• robots.txt im Site-Root mit einer vollqualifizierten Sitemap:-Zeile, die niemals die kanonische Seite oder erforderliche Medien blockiert.
• sitemap.xml mit XML-escaped, absoluten kanonischen <loc>-URLs, die dem HTML-Kanonischen entsprechen; lastmod nur aus einem verifizierbaren Zeitstempel einer signifikanten Inhaltsänderung (bei Unbekanntheit weglassen – niemals Generierungszeit blind verwenden).
• Hosting-Anweisungen aus references/server-config.md: Caching, Brotli/gzip, Sicherheitsheader.

4. STOPP-PUNKT – Benutzerfreigabe

Zeigen Sie dem Benutzer die generierte Seite und fragen Sie explizit, ob die HTML-Version in Ordnung ist. Fahren Sie nicht mit der Validierung und dem Abschlussbericht fort, bis der Benutzer bestätigt. Wenn es Anmerkungen gibt – korrigieren und erneut fragen.

5. Validieren

Führen Sie den ausführbaren Validierungsvertrag aus Technische Spezifikation §7 durch – festgelegte Befehle gegen die bereitgestellte Seite, nur gemessene Ergebnisse, expliziter BLOCKER, wenn ein Gate nicht ausgeführt werden kann:

• W3C HTML-Gültigkeit (Nu Validator, JSON-Ausgabe; null Fehler).
• Vorhandensein lokaler Assets/Links: Extrahieren Sie jede von der Ausgabe referenzierte lokale URL (img src/srcset, <source> srcset, preload href/imagesrcset, Favicon, OG/Twitter-Bilder, CSS url(), script src) und überprüfen Sie, ob jede Datei im Projektordner existiert. Jede fehlende referenzierte lokale Ressource ist ein schwerwiegender Fehler – erzeugen Sie die Datei oder entfernen Sie die Referenz; versenden Sie niemals HTML, das auf Dateien verweist, die nie erstellt wurden.
• JSON-LD-Syntax (JSON-Parse) – getrennt von der Google-Rich-Result-Eignung, die mit dem Rich Results Test auf der bereitgestellten Seite geprüft wird.
• Responsive Screenshots bei 320/768/1280/1920px, auf Überlauf und Reflow geprüft.
• Lighthouse: festgelegte Version/Profil, 3 Läufe, Median pro Kategorie, Schwellwert ≥ 90, Artefakte im reports/-Verzeichnis des Projekts – nur Laborbelege, niemals Feld-Core-Web-Vitals und niemals WCAG-Zertifizierung.
• Manuelle Barrierefreiheitsprüfungen (Technische Spezifikation §8) – kein automatisiertes Werkzeug allein bestimmt die WCAG-Konformität: Tastaturnavigation, Fokus-Reihenfolge/Sichtbarkeit, Dialog-Fokusfluss, Zoom/Reflow, reduzierte Bewegung, semantischer Name-Rolle-Wert, Qualität von Alternativtexten und alle interaktiven visuellen Zustände. Erfassen Sie Bestanden/Nicht bestanden-Belege pro anwendbarem WCAG 2.1 AA-Kriterium; melden Sie ungelöste Punkte, anstatt sie stillschweigend zu zertifizieren.
• Crawlbarkeitsvertrag: Parsen Sie sitemap.xml, vergleichen Sie jede <loc> mit dem HTML-Kanonischen, überprüfen Sie die Sitemap:-URL in robots.txt und fordern Sie beide bereitgestellten Dateien erfolgreich an (HTTP 200).

Beheben Sie alle gefundenen Verstöße vor der Berichterstattung. Legen Sie Belege ehrlich offen: Jede gemeldete Zahl wird mit dem genauen Befehl und Artefaktpfad geliefert, der sie erzeugt hat; ein Gate, das nicht ausgeführt werden konnte, wird als BLOCKER: <Grund> anstelle einer Zahl gemeldet. Geben Sie niemals einen PageSpeed/LCP-Wert aus, der nicht tatsächlich gemessen wurde.

6. Abschlussbericht

Kurze Auflistung:

• LCP-Parameter
• PageSpeed-Ergebnis
• Im Code verwendete Schema.org-Typen

Hauptfehler

• Verwenden Sie niemals externe JS/CSS-Bibliotheken, externe Schriftarten oder SVG-Bilder (Technische Spezifikation §6).
• Verweisen Sie niemals auf ein lokales Asset, das nie erstellt wurde: Jede src/srcset/preload/OG-URL muss zu einer echten Datei im Projektordner aufgelöst werden; fehlende Quellbilder werden vom Benutzer angefordert, nicht erfunden (AUSGABE-Vertrag).
• Geben Sie niemals einen rohen Briefing-Wert in Markup aus: Kontext-kodieren Sie alles, lehnen Sie javascript:/unerwartete data:-URLs ab und testen Sie die Generierung selbst mit feindlichen Werten (Anführungszeichen, </script>, Event-Handler-Payloads) (Technische Spezifikation §13).
• Laden Sie niemals YouTube-Iframes, Karten, Chats, Abonnement-Popups oder Cookie-Banner beim ersten Laden (Technische Spezifikation §9, §10, §11) – die einzige dokumentierte Ausnahme ist ein im Briefing gewählter SEO-auffindbarer Video-Modus mit einem direkten Embed, der als Abhängigkeit beim ersten Laden aufgezeichnet wird (Technische Spezifikation §9 Modus S).
• Der gesamte Inhalt muss im rohen HTML vorhanden sein – nichts, das nur durch JS gerendert wird.
• Absolute URLs in JSON-LD, canonical und OG-Tags.
• Gesamt-JS-Budget ≤ 15 KB, eine Datei, defer vor </body>.