Landing Generator · Servicio × Barrio

📚 Itinerario YinyangSEO Academy · Klasse 1 — Agentische Webs und effizientes SEO. Diese Skill ist Teil des Repos der Klasse 1. Klone oder lade das gesamte Repo herunter und gib es deinem Agenten als Kontext, bevor du die Skill ausführst. Das Repo wird während des Kurses aktualisiert.

Landing Generator · Service × Bezirk

Nimmt das Blueprint und erzeugt physische Dateien im Repo der Kundenwebsite. Astro standardmäßig (einfache Dateipfade, Standard-SSG, ideal für SEO), aber die Ausgabe kann an Next.js oder reines MDX angepasst werden.

Eingaben

• blueprint/{geschaeft-slug}/ ← von web-blueprint-generator.
• Zielordner · src/pages/ (Astro) oder app/ (Next.js).
• Locale · Standard es-ES.
• Modus · dry-run (zeigt an, was generiert würde) oder apply (schreibt + commitet).

Ablauf

1. Blueprint laden und prüfen, dass url-map.yaml, page-templates und schema-templates vorhanden sind.
2. Für jede Service × Bezirk-Kombination aus url-map.yaml:
   • Variablen auflösen ({servicio}, {barrio}, {ciudad}, usw.) mit echten Geschäftsdaten.
   • Minimalen, eindeutigen Inhalt pro Bezirk einfügen (KEINE Duplikate; siehe QA).
   • Entsprechendes JSON-LD-Schema hinzufügen.
   • Interne Links gemäß internal-linking.yaml berechnen.
   • Datei im richtigen Repo-Pfad schreiben.
3. Pillar-Seiten generieren (/servicios/{slug}/) mit Auflistung der abgedeckten Bezirke.
4. sitemap.xml generieren (oder @astrojs/sitemap konfigurieren) mit Prioritäten.
5. Konsistente robots.txt generieren.
6. Änderungen committen in einem neuen Branch: feat/landings-{servicio}-{N}-barrios.
7. Zusammenfassung anzeigen: N erstellte Seiten, Gesamtgröße HTML, Schema validiert, Dry-Run oder Anwendung.

Werkzeuge

• Dateisystem (Lesen/Schreiben/Bearbeiten) im Kundenrepo.
• Git für Commits.
• Astro + @astrojs/sitemap + astro-seo.
• LLM zur Generierung des eindeutigen Inhaltsblocks pro Bezirk (mit Guardrails für Länge und Eindeutigkeit).
• schema-dts zur Validierung von JSON-LD vor dem Schreiben.

Ausgabe

src/pages/{servicio}/{barrio}.astro      ← eine pro Kombination
src/pages/servicios/{servicio}.astro     ← Pillar
src/data/areas-served.json               ← Quelle der Wahrheit für Zonen
public/sitemap.xml                       ← neu generiert
public/robots.txt

Und ein sauberer Commit mit der Nachricht:

feat(landings): N Landings Service × Bezirk generieren

- Dienst: cerrajero-24h
- Bezirke: 12
- Pillar aktualisiert
- Sitemap neu generiert (Einträge: 13)
- Schema JSON-LD mit schema-dts validiert

Qualität / QA

• Inhaltseindeutigkeit: Jede Landing muss ≥ 30 % unterschiedliche Tokens im Vergleich zu ihren Geschwistern haben (Jaccard-Ähnlichkeit < 0.7). Falls nicht, den variablen Block neu generieren.
• Schema-Validierung: Keine Datei wird geschrieben, wenn das JSON-LD nicht validiert.
• Interne Verlinkung obligatorisch: Jede Landing hat mindestens 3 interne Links zu anderen Bezirken desselben Dienstes + 1 zur Pillar-Seite.
• Lighthouse-Budget: Wird nach der Generierung an landing-qa-runner delegiert.
• Kosten/Zeit: Warnen, wenn > 50 Kombinationen in einem Durchlauf.

Wofür es danach verwendet wird

→ Eingabe für landing-qa-runner, der Playwright + Lighthouse-CI auf allen generierten URLs ausführt und den Merge blockiert, wenn sie das vom Top 3 geerbte Budget nicht einhalten.