SEO-Landingpage: launchen, strukturieren, prüfen

SEO-Landing Pages erstellen

Nutzen Sie diesen Skill, um Landing Pages zu erstellen, verbessern, prüfen, deployen oder validieren.

Verwenden Sie diesen Skill nicht für kleine Text-, Stil- oder Komponentenänderungen, es sei denn, SEO, Conversion, Barrierefreiheit, Performance, Deployment oder Launch-Bereitschaft sind Teil der Anfrage.

Kern-Workflow

1. Untersuchen Sie das bestehende Projekt, bevor Sie Änderungen vornehmen.
2. Identifizieren Sie das Unternehmen/die Entität, die Zielgruppe, den Standort, die Dienstleistungen, das Conversion-Ziel und das Deployment-Ziel.
3. Identifizieren Sie den Technologie-Stack und bewahren Sie dessen Konventionen.
4. Prüfen Sie Metadaten, Überschriften, strukturierte Daten, Sitemap, Robots (inkl. KI-Crawler-Zugriff), llms.txt, Favicon, Manifest, Social Previews und sichtbare Geschäftsinformationen.
5. Überprüfen Sie responsive Layout, Barrierefreiheit, Bildgrößen, JavaScript-Ladung und CLS-Risiken.
6. Nehmen Sie konkrete Dateiänderungen im bestehenden Projektstil vor.
7. Führen Sie verfügbare Validierungswerkzeuge aus oder geben Sie genaue Befehle an, falls blockiert.
8. Fassen Sie Änderungen, Verifizierung, verbleibende Risiken und Schritte nach dem Launch zusammen.

Standard-Prioritäten

• Machen Sie den ersten Viewport klar: Entität, Angebot, Standort oder Zielgruppe und primärer CTA.
• Halten Sie wichtige Fakten im HTML sichtbar, nicht nur in Metadaten oder JSON-LD.
• Bevorzugen Sie Service-Schema für Dienstleistungen; verwenden Sie Product-Schema nur mit echten Produktangebotsdaten.
• Priorisieren Sie für lokale Unternehmen die NAP-Konsistenz, Servicebereiche, Öffnungszeiten, Karten-/Profil-Links, Bewertungen und echte Fotos.
• Behandeln Sie benutzerdefinierte Domain, Google Business Profile, Bewertungen, Zitate, Search Console und echte Fotos als Launch-/Off-Site-Arbeit, nicht nur als Code-Anpassungen.
• Aktualisieren Sie nach Domain- oder Deployment-Änderungen die Kanonische URL, Sitemap, Robots-Sitemap-URL, strukturierte Daten-URLs, Social-Image-URLs und die Search Console-Eigenschaft.
• Fälschen Sie keine Bewertungen, Rezensionen, Garantien, Rankings, Indexierungsstatus, Core Web Vitals, Lighthouse/PageSpeed-Ergebnisse, Deployment-Status, KI-Übersichts-/KI-Zitierungsstatus oder API-Ergebnisse.
• FAQ- und HowTo-Schema erzeugen keine Google Rich Results mehr (FAQ entfernt am 7. Mai 2026; HowTo 2023 entfernt); behalten Sie FAQPage-Schema für das Verständnis durch KI/Antwortmaschinen bei, nicht für ein versprochenes SERP-Feature.
• Fragen Sie den Seitenbetreiber, bevor Sie den KI-Bot-Zugriff in robots.txt ändern; dies ändert die tatsächliche Exposition gegenüber Assistenten-Zitaten und Modelltraining. Beachten Sie, dass Google AI Overviews/AI Mode durch normalen Googlebot-Zugriff und Search Console-Steuerungen geregelt werden, nicht durch KI-Bot-Tokens.
• llms.txt ist optionale Hygiene ohne nachgewiesenen Ranking- oder Zitierungsvorteil, und Google gibt an, dass es für KI-Features nicht benötigt wird; bieten Sie es an, verkaufen Sie es nicht als KI-Sichtbarkeitsgewinn.
• Passen Sie das Design an den Seitentyp und die Zielgruppe an; priorisieren Sie Klarheit, Vertrauen, mobile Benutzerfreundlichkeit und Conversion vor Dekoration.

Wann Referenzen gelesen werden sollten

• Für Build-Fluss und Seitenstruktur lesen Sie references/landing-page-workflow.md.
• Für frameworkspezifische Implementierungsdetails lesen Sie references/framework-implementation.md.
• Für Landing Page-Texte, CTAs und Vertrauenssignale lesen Sie references/content-conversion.md.
• Für SEO-, AEO-, GEO- und lokale Suchchecks lesen Sie references/seo-aeo-geo-checklist.md.
• Für lokale Business-Websites lesen Sie references/local-business-seo.md.
• Für JSON-LD- und Rich-Result-Probleme lesen Sie references/structured-data.md.
• Für Performance-, Barrierefreiheits- und CLS-Arbeiten lesen Sie references/performance-accessibility.md.
• Für Validierungsskripte, Lighthouse/PageSpeed, Search Console und Berichte lesen Sie references/validation-workflow.md.
• Für Deployment, Domains, Search Console und Google Business Profile lesen Sie references/deployment-domain-search-console.md.
• Für llms.txt, KI-Crawler-Zugriff und KI-Suchberichte lesen Sie references/ai-crawlers-and-llms-txt.md.
• Für WebMCP, agentenaufrufbare Tools und agentenbereite Formulare lesen Sie references/webmcp.md.

Vorlagen

Verwenden Sie Vorlagen nur als Ausgangspunkte. Passen Sie sie an das Projekt an, bevor Sie sie einfügen:

• templates/metadata-head.html
• templates/site.webmanifest
• templates/robots.txt
• templates/sitemap.xml
• templates/local-business-jsonld.html
• templates/website-jsonld.html
• templates/website-with-search-jsonld.html - Legacy; dessen SearchAction erzeugt kein Google-Feature mehr
• templates/organization-jsonld.html
• templates/person-jsonld.html
• templates/breadcrumb-jsonld.html
• templates/faq-jsonld.html
• templates/service-offer-catalog-jsonld.html
• templates/static-landing-page.html
• templates/launch-checklist.md
• templates/privacy-notice.md
• templates/llms.txt

Skripte

Skripte sind optionale Helfer. Führen Sie sie vom Stammverzeichnis des Zielprojekts aus, wenn die Umgebung es erlaubt:

• scripts/check-metadata.mjs [html-file] [--no-write] - statische Metadaten-, Überschriften-, Bild-, Favicon-, Manifest- und grundlegende SEO-Checks.
• scripts/check-structured-data.mjs [html-file] [--no-write] - JSON-LD-Parse- und Schema-Sanity-Checks.
• scripts/check-links.mjs [html-file] [--network] [--no-write] - lokale Links, Fragmente, Assets und optionale externe URL-Checks.
• scripts/check-site-files.mjs [site-root] [--no-write] - Prüft robots.txt, sitemap.xml, site.webmanifest, llms.txt und allgemeine Symbolprüfungen; übergeben Sie public für Framework-öffentliche Ordner.
• scripts/check-placeholders.mjs [paths...] [--no-write] - Prüft auf nicht ersetzte {{PLACEHOLDER}} nachdem Vorlagen angewendet wurden.
• scripts/run-lighthouse.mjs <url> [mobile|desktop] - Lighthouse-JSON-Bericht.
• scripts/summarize-lighthouse.mjs [lighthouse-json-report] [--no-write] - Markdown-Zusammenfassung aus einem Lighthouse-Bericht.
• scripts/run-pagespeed.mjs <url> [mobile|desktop] - PageSpeed Insights-JSON-Bericht.
• scripts/summarize-pagespeed.mjs [pagespeed-json-report] [--no-write] - Markdown-Zusammenfassung aus einem PageSpeed-Bericht.
• scripts/list-search-console-sites.mjs [--no-write] - Listet verifizierte Search Console-Eigenschaften auf.
• scripts/submit-sitemap.mjs <search-console-site-url> <sitemap-url> - Reicht eine Sitemap über die Search Console-API ein.
• scripts/inspect-url.mjs <inspection-url> <search-console-site-url> [language-code] - Überprüft URL-Indexierungsdaten über die Search Console-API.

Verwenden Sie PAGESPEED_API_KEY für PageSpeed-API-Aufrufe, wenn verfügbar.

Verwenden Sie GOOGLE_SEARCH_CONSOLE_ACCESS_TOKEN nur für unterstützte Search Console-API-Aktionen.

Wenn eine angeforderte API-gestützte Aktion Anmeldeinformationen benötigt und die Umgebungsvariable fehlt, bitten Sie den Benutzer, sie in seinem eigenen Terminal zu exportieren. Bitten Sie ihn nicht, das Geheimnis in die Konversation einzufügen, und geben Sie niemals selbst einen Schlüssel in einen Befehl ein: Ein eingefügter oder inline geschriebener Schlüssel landet im Transkript und in Protokollen, während eine exportierte Variable von diesen Skripten geerbt wird, ohne jemals in die Konversation zu gelangen. references/validation-workflow.md enthält die Befehle pro Shell.

Schreiben Sie keine Geheimnisse in .env, getrackte Dateien oder Projektkonfigurationen, es sei denn, der Benutzer fordert dies ausdrücklich an.

Wenn Anmeldeinformationen, Netzwerk, Abhängigkeiten oder Kontingente nicht verfügbar sind, täuschen Sie keinen Erfolg vor. Erklären Sie den Hinderungsgrund und geben Sie manuelle Schritte oder Fallback-Befehle an.

Wenn Sie bei der Verwendung unsicher sind, führen Sie das Skript mit fehlenden Argumenten aus, um den Verwendungstext zu sehen, oder lesen Sie references/validation-workflow.md.

Regeln

• Bevorzugen Sie konkrete Dateiänderungen gegenüber allgemeinen Ratschlägen.
• Bewahren Sie bestehende Projektkonventionen.
• Fragen Sie nach Anmeldeinformationen nur, wenn die angeforderte Aktion sie benötigt, und lassen Sie den Benutzer sie exportieren, anstatt sie einzufügen.
• Kein Keyword-Stuffing.
• Fügen Sie keine gefälschten Bewertungen, gefälschten Rezensionen oder nicht unterstützte Behauptungen hinzu.
• Versprechen Sie keine Ranking-, Indexierungs- oder Core Web Vitals-Ergebnisse.
• Vermeiden Sie layoutverschiebende Eingangsanimationen. Bevorzugen Sie bei Bedarf reine Transparenz-Enthüllungen.
• Frameworks sind nicht standardmäßig schlecht. Verwenden Sie statisches HTML für einfache Seiten und React, Next.js, Astro oder ähnliche Frameworks, wenn das Projekt sie bereits verwendet oder ihre Funktionen benötigt.
• Priorisieren Sie für lokale Unternehmen den genauen Geschäftsnamen, NAP-Konsistenz, Servicebereich, Öffnungszeiten, Kartenlink, Google Business Profile oder das lokale Äquivalent, Bewertungen und Anleitung zur benutzerdefinierten Domain.