App-Landing-SEO — Store-Listing → Keyword-Seiten

SEO für App-Landingpages

End-to-End-Workflow zur Umwandlung einer App-Store-Liste in eine konvertierungsstarke, SEO-optimierte Landingpage mit Long-Tail-Guide-Seiten. Standard-Stack: Vite + React mit Buildtime-Prerendering (Architektur in Phase 3). Falls das Repository bereits ein Web-Framework (Next.js, Astro) enthält, bauen Sie stattdessen darin und passen Sie die Ausgabepfade an. Jede Phase endet mit einer Verifikation.

Diese Fähigkeit hängt von der separat installierten gpt-image-Fähigkeit ab, die im selben Repository enthalten ist. Wenn Leitfadenbilder benötigt werden, laden Sie diese Fähigkeit und befolgen Sie deren Anweisungen. Gehen Sie nicht davon aus, dass sich der Helfer im Verzeichnis dieser Fähigkeit befindet.

Phase 1 — Abrufen der Store-Liste (Quelle der Wahrheit)

1. Rufen Sie die vollständigen Metadaten von der iTunes-Lookup-API ab (keine Authentifizierung erforderlich):

   curl -s "https://itunes.apple.com/lookup?id=<APP_ID>&country=us"
   

   Extrahieren Sie: Name, bundleId, Beschreibung, Preis/IAP-Bedingungen, Genres, Bewertungsanzahl, Screenshots, Icon, Version, Verkäufer. Überprüfen Sie auch auf eine Google-Play-Liste (play.google.com/store/apps/details?id=<bundleId>) — gehen Sie nicht von iOS-exklusiv aus.

2. Laden Sie Assets in hoher Auflösung herunter, indem Sie das mzstatic-Thumbnail-Suffix umschreiben:

   • Icon: Ersetzen Sie 512x512bb.jpg durch 1024x1024bb.png
   • Screenshots: Ersetzen Sie 392x696bb.jpg durch 1284x2282bb.png (graceful Degradation; überprüfen Sie mit file)

3. Lesen Sie jeden Screenshot mit dem Read-Tool. Beschriftungen, Leitfaden-Themen und Landing-Text müssen beschreiben, was die Bilder tatsächlich zeigen. Extrahieren Sie außerdem die Markenfarbpalette und den Schriftstil daraus.

4. Schreiben Sie app.md im Repository-Stammverzeichnis: Identitätstabelle, wörtliche Beschreibung, aus der Liste und den Screenshots abgeleitete Funktionsliste, Asset-Manifest, dann die Keyword-Recherche (Phase 2) und die Platzierungskarte. Diese Datei ist der Vertrag für alles Folgende.

Phase 2 — Keyword-Recherche, die konvertiert

• Wenn die astro-MCP-Tools verbunden sind, verwenden Sie get_keyword_suggestions und search_app_store für die Beliebtheit/Schwierigkeit und den aktuellen Rang im App Store. Notieren Sie, wo die App heute rangiert.
• Verwenden Sie WebSearch, um Google-seitige Long-Tails zu validieren (die Landingpage rankt bei Google, nicht im App Store).
• Strukturieren Sie die Ausgabe in app.md:
  • Primäre Keywords (3–5 Head-Terme) → Title-Tag, H1, Hero-Text, Meta-Beschreibung
  • Sekundäre → Abschnitts-H2s, Funktionsbeschreibungen
  • Long-Tail (6–10 Frage-/Aufgabenphrasen) → jeweils eine Guide-Seite
• Wichtige Regeln:
  • Jeder Long-Tail muss auf ein Problem abzielen, das die App nachweislich löst — idealerweise sichtbar in einem Screenshot. Das ist es, was den Traffic konvertieren lässt.
  • Überprüfen Sie die tatsächlichen SERPs für jeden Head-Term und überspringen Sie vergiftete (z. B. „Aktien-Tracker" liefert Börsen-Apps; „Bestandsverwaltungssoftware" liefert Unternehmensanbieter).
  • Bevorzugen Sie How-To-Formulierungen, wo Blogs ranken — eine App-Seite mit HowTo/FAQ-Schema kann sie schlagen.

Phase 3 — On-Page-SEO der Landingpage

Vite + React SSG-Architektur (Standard)

Eine SPA ist für Crawler ohne JS-Rendering unsichtbar. Liefern Sie daher vorgerendertes statisches HTML aus. Kein SSG-Framework erforderlich — ein ~30-zeiliges Prerender-Skript erledigt das, und die Seiten benötigen normalerweise null Client-JS (FAQ-Akkordeons sind native <details>; hydrieren Sie nicht, was keine Interaktivität hat):

landing/
  package.json          # build: vite build --ssr src/entry-server.tsx --outDir dist-ssr && node scripts/prerender.mjs
  vite.config.ts        # plugins: [react()], ssr: { noExternal: true }  ← bündelt React in dist-ssr, damit prerender.mjs es standalone importiert
  index.html            # Dev-Only-Shell: <div id="root"> + /src/entry-client.tsx
  public/               # style.css, assets/ (wird unverändert nach dist/ kopiert)
  src/
    data.ts             # ALLE Inhalte: FAQ-Einträge, Guide-Texte, Titel, Beschreibungen. Einzige Quelle der Wahrheit.
    seo.ts              # PageMeta-Typ + JSON-LD-Builder (homeJsonld, guideJsonld, breadcrumbJsonld), die data.ts verwenden
    components.tsx      # Header, Footer, StoreBadge, FaqItem, GuideCard, CtaCallout
    pages/              # Home.tsx, GuidePage.tsx, GuidesIndex.tsx
    routes.tsx          # ROUTES: [{ meta: PageMeta, element }] — ein Eintrag pro Seite, Guides verteilt von data.ts
    entry-server.tsx    # renderRoute(route): vollständiger HTML-Dokumentstring — Head-Tags + JSON-LD + renderToStaticMarkup(body)
    entry-client.tsx    # Dev-Only: matchRoute(location.pathname) → createRoot().render()
  scripts/prerender.mjs # importiert dist-ssr/entry-server.js; schreibt dist/<path>/index.html pro Route + sitemap.xml + robots.txt; cpSync public/ → dist/

Wichtige Entscheidungen, die in diese Form eingebettet sind:

• renderToStaticMarkup, nicht renderToString — keine Hydrierungsmarker, sauberes HTML, da kein Client-Bundle ausgeliefert wird.
• Saubere URLs: Routenpfade enden auf / (/guides/<slug>/) und Prerender schreibt <path>/index.html. Interne Links sind site-absolut (/guides/…/), was auch die Navigation im Dev-Server ermöglicht.
• Entwicklererfahrung: vite bedient entry-client.tsx mit HMR; der Client-Eintrag wird niemals in der Produktion ausgeliefert.
• esc() attributwerte in der handgebauten Head-Vorlage; JSON-LD via JSON.stringify (keine Escaping-Probleme).
• Das React-Attribut ist fetchPriority (camelCase) — Kleinbuchstabe fetchpriority warnt.

On-Page-Regeln (jeder Stack)

Abschnitte: Hero, Download, Screenshots, So funktioniert's, Guides, FAQ, CTA, Footer.

• Genau eine H1, die das primäre Keyword trägt. Abschnittsüberschriften sind H2 („Verfügbar auf"-Überschriften dürfen keine H1s sein).
• <title> ≈ „Marke — Primäres Keyword für Zielgruppe" (max. 60 Zeichen). Meta-Beschreibung max. 155 Zeichen mit primärem Keyword + wichtigsten Unterscheidungsmerkmalen.
• Kanonische URL pro Seite, OG + Twitter Cards, apple-itunes-app-Meta (Smart App Banner). Im Vite-Setup leben diese in entry-server.tsx; Next.js: metadataBase, alternates.canonical, Titel template, itunes.appId.
• JSON-LD auf der Homepage: SoftwareApplication (mit offers, installUrl; aggregateRating unter ~50 Bewertungen überspringen), FAQPage, WebSite. Bauen Sie die Objekte in seo.ts aus data.ts, sodass Schema und sichtbarer Text eine gemeinsame Quelle haben.
• Store-Badges/Download-CTA above the fold, plus ein wiederholter CTA-Abschnitt weiter unten.
• Screenshots erhalten Keyword-tragende alt-Texte, die den tatsächlichen Bildschirm beschreiben. Komprimieren Sie Store-PNGs (oft 1–2 MB pro Stück) auf ≤200 KB JPEGs (sips -Z 1386 -s format jpeg -s formatOptions 80); behalten Sie die Originale in public/assets/full/.
• FAQ: 8–10 Fragen, jede eine echte Suchanfrage, in 2–3 Sätzen beantwortet, jede mit einem „Mehr erfahren →"-Link zum passenden Guide. Das FAQPage-JSON-LD muss denselben Q/A-Text enthalten wie das sichtbare FAQ — beide werden aus demselben data.ts-Array gerendert.
• sitemap.xml + robots.txt: generiert von scripts/prerender.mjs aus der ROUTES-Liste, sodass neue Guides automatisch erscheinen.

Phase 4 — Guide-Seiten (eine pro Long-Tail-Keyword)

Speichern Sie Guide-Inhalte im einen Datenmodul (src/data.ts im Vite-Setup; lib/guides.ts in Next.js) und rendern Sie sie durch eine einzelne Vorlagenkomponente, sodass Schema, Karten, Footer-Links und Sitemap alle aus derselben Liste abgeleitet werden. Modellieren Sie jeden Guide als strukturierte Daten, nicht als HTML-Blobs: { slug, title, description, h1, intro, featureImage: { src, alt, width, height }, howto?, sections: [{ h2, paras, cta?, figure? }], faq, related } — der CTA-Callout und die Abbildungen werden zu Komponenten, und Absätze bleiben durchsuchbare Strings (Inline-<em>-Level-HTML via dangerouslySetInnerHTML ist in Ordnung).

GPT-Image-Feature-Image-Workflow

Jeder Guide-Artikel erhält ein eigenes horizontales Feature-Image. Laden Sie die gpt-image-Fähigkeit und verwenden Sie sie; sie ruft OpenAIs gpt-image-2 auf. Ersetzen Sie sie nicht durch Stock-Bilder, CSS-Verläufe, Screenshots oder ein anderes Bildmodell, es sei denn, der Benutzer bittet explizit darum. Wenn gpt-image nicht installiert ist, stoppen Sie vor der Bilderstellung und teilen Sie dem Benutzer mit, die Schwesterfähigkeit aus diesem Repository zu installieren.

1. Nachdem Guide-Titel und Slugs final sind, erstellen Sie eine Bildkurzbeschreibung pro Guide aus seiner Suchintention, dem konkreten Thema und der visuellen Identität der App, die in app.md erfasst wurde. Die Konzepte müssen sich sinnvoll unterscheiden, nicht nur Palettentausch einer Komposition sein.
2. Prompten Sie für ein redaktionelles Feature-Image in der Markenfarbpalette der App. Beschreiben Sie das Motiv, die Umgebung, die Komposition, die Beleuchtung, die Materialien, die Kamera/den Blickwinkel und wo visueller Freiraum sein soll. Beenden Sie jeden Prompt mit: „Landscape editorial feature image, 3:2 composition. Absolutely no text, words, letters, numbers, captions, watermarks, interface labels, or logos." Bitten Sie das Modell nicht, den Artikel-Titel darzustellen.
3. Lösen Sie GPT_IMAGE_SKILL_DIR zum installierten Verzeichnis auf, das die SKILL.md der gpt-image-Fähigkeit enthält, und führen Sie dann dessen Generator mit einem deterministischen Ziel aus:

   "$GPT_IMAGE_SKILL_DIR/scripts/generate_image.py" "<guide-spezifischer Prompt>" \
     --model gpt-image-2 \
     --aspect-ratio 3:2 \
     --quality high \
     --background opaque \
     --format webp \
     --output "<site-public-dir>/assets/guides/<slug>-feature.webp"
   

   Dies erzeugt eine 1536×1024-Quelle im Querformat. Erstellen Sie das Zielverzeichnis bei Bedarf. Bewahren Sie die generierte Quelle; verwenden Sie die Bildpipeline des Frameworks für kleinere responsive Varianten, anstatt sie wiederholt zu komprimieren.
4. Überprüfen Sie jedes Bild in voller Größe, bevor Sie es einbinden. Achten Sie auf versehentliche Text-/Glyphen, fehlerhafte Objekte, kopierte App-UI, unbeabsichtigte Logos, irrelevante Motive und schlechte Beschnittsicherheit bei Desktop- und Karten-Seitenverhältnissen. Generieren Sie nur fehlgeschlagene Bilder neu, ändern Sie den Prompt, um den beobachteten Defekt zu beheben; stoppen Sie nach zwei erfolglosen Neugenerierungen für denselben Guide und melden Sie das verbleibende Problem, anstatt unbegrenzt Zeit zu investieren.
5. Fügen Sie das Bild mit width: 1536, height: 1024 und einem prägnanten, beschreibenden Alt-Text basierend auf dem tatsächlichen Bildinhalt zum strukturierten Datensatz des Guides hinzu. Rendern Sie es als Above-the-Fold-Feature-Image des Artikels, als Guide-Card-Thumbnail und als og:image/twitter:image der Seite. Fügen Sie es als absolute URL zu Article.image in JSON-LD hinzu. Verwenden Sie das Such-Keyword nicht als Standard-Alt-Text, wenn es die Pixel nicht beschreibt.

Pro Guide:

• URL-Slug = das Keyword (/guides/how-to-keep-track-of-inventory-small-business)
• Antwort-zuerst-Eröffnung: Der erste Absatz beantwortet direkt die gesuchte Frage (Featured-Snippet-Köder), dann lehrt der Text die Aufgabe mit der eingewobenen App als Werkzeug — erst lehren, dann bewerben.
• H2s tragen sekundäre Formulierungen des Keywords. 600–900 Wörter Substanz, keine Fülltexte.
• Ein relevanter App-Screenshot mit beschreibender Bildunterschrift, ein CTA-Callout in der Mitte der Seite und ein 2-Fragen-FAQ, das für diesen Guide einzigartig ist (FAQ-Fragen der Homepage nicht duplizieren — Schema-Duplikation).
• JSON-LD: Article + BreadcrumbList + FAQPage, plus HowTo, wenn der Guide schrittförmig ist.
• Verlinken Sie Guides untereinander und zurück zu den Abschnitten der Homepage.
• Das generierte GPT-Image-Feature-Asset ist vorhanden, für den Artikel einzigartig und in den Hero, die Karte, die sozialen Metadaten und das Article.image-JSON-LD eingebunden. Verwenden Sie responsives srcset/Framework-Bildoptimierung und setzen Sie explizite Dimensionen, um Layout-Verschiebungen zu verhindern; lazy-loaden Sie das Above-the-Fold-Feature-Image nicht.

Phase 5 — Entschlacken des Textes (Wikipedia: Anzeichen von KI-Schreibstil)

Führen Sie diesen Durchlauf für ALLE Inhalte durch, die Sie geschrieben haben (Guides, FAQ-Antworten, Hero-/Abschnittstexte), bevor Sie sie ausliefern. Die Erkennungsmerkmale, in absteigender Lautstärke:

1. Gedankenstriche — das häufigste Erkennungsmerkmal. Budget: eine Handvoll auf der gesamten Website, nicht pro Absatz. Ersetzen Sie sie durch Punkte, Kommas, Doppelpunkte, Klammern.
2. Negative Parallelismen — „Es ist nicht X, es ist Y", „nicht nur X, sondern Y", „X, nicht Y". Maximal eine auf der Website, und nur, wenn es seinen Platz verdient.
3. Dreierregel — „kein A, kein B, kein C", „Adj, Adj, Adj". Brechen Sie sie in Paare oder echte Listen auf.
4. Formelhafte Struktur — identische Eröffnungen über Seiten hinweg (z. B. jeder Guide, der mit derselben fettgedruckten These beginnt). Variieren Sie: direkte Antwort, Szenario, schlichte Behauptung.
5. Einheitlicher knackiger Rhythmus — Satz für Satz kurz, der einen Pointen setzt. Variieren Sie die Satzlänge; lassen Sie einige Sätze einfach Informationen tragen.
6. Vokabular-Blacklist: eintauchen, Teppich, Zeugnis, entscheidend, wesentlich, lebendig, nahtlos, mühelos, prahlt, nutzt, hervorheben, robust, akribisch, Landschaft, unterstreichen, präsentieren, fördern, transformativ, bahnbrechend, revolutionieren, befähigen, optimieren, „Killer-Funktion", „einzige Quelle der Wahrheit", „mit Zuversicht", wiederholte „So geht's/So ist das...".
7. Kopula-Vermeidung — „dient als", „steht als", „repräsentiert", wo „ist" funktioniert. Verwenden Sie „ist".
8. Oberflächliche Analyse-Partizipien — „...hervorhebend", „...unterstreichend", „...reflektierend"-Nebensätze, die an Satzenden angehängt werden.
9. Ersetzen Sie Aphorismen durch konkrete Details (einen Preis, einen Monat, ein benanntes Objekt). Details lesen sich menschlich; Allgemeinplätze lesen sich generiert.

Mechanische Überprüfung (Pfade anpassen):

grep -o "—" <Inhaltsdateien> | wc -l   # Ziel: einstellige Anzahl site-weit
grep -inE "eintauchen|Teppich|Zeugnis|entscheidend|wesentlich|lebendig|nahtlos|mühelos|prahlt|nutzt|hervorheben|robust|akribisch|Landschaft|unterstreichen|präsentieren|fördern|transformativ|bahnbrechend|revolutionieren|befähigen|optimieren|dient als|steht als|es ist nicht nur|ist nicht nur|nicht nur" <Inhaltsdateien>

CSS-Klassennamen (z. B. transition-transform) führen zu Fehlalarmen; ignorieren Sie diese. Was Sie behalten, muss der Frage „Würde ein vielbeschäftigter Mensch diesen Satz schreiben?" standhalten.

Behalten Sie beim Entschlacken intakt: Slugs, Überschriften/Keywords, interne Links, Schema (generieren Sie das Schema aus der neu geschriebenen Quelle neu, sodass sichtbarer Text und JSON-LD identisch bleiben).

Phase 6 — Verifizieren

• npm run build muss bestehen, dann führen Sie eine skriptgesteuerte Prüfung über dist/**/index.html durch: genau eine H1 pro Seite, kanonisch vorhanden, jedes <script type="application/ld+json"> parst, jeder interne href/src löst auf eine Datei in dist auf (trailing-slash URLs auf <path>/index.html abbilden), jede <loc> in der Sitemap zeigt auf eine echte Datei, und die sichtbaren FAQ-Fragen der Homepage entsprechen den names des FAQPage-JSON-LD.
• Überprüfen Sie, ob jeder Guide-Datensatz ein eigenes horizontales Feature-Image hat, jede Datei im Build-Output existiert, die intrinsischen Dimensionen breiter als hoch sind, die HTML-Attribute width/height mit der Quelle übereinstimmen und die Open Graph-, Twitter- und Article.image-URLs jedes Guides auf die tatsächlichen WebP-Assets verweisen.
• Überprüfen Sie die sichtbaren Texte der Homepage gegen das JSON-LD (FAQPage, SoftwareApplication). Nichtübereinstimmungen sind Fehler: entweder hat der Redakteur den sichtbaren Text geändert, ohne das Schema zu aktualisieren, oder umgekehrt.
• Führen Sie die Blacklist-Grep-Befehle aus Phase 5 auf dem Build-Output aus. Potenziell problematische Stellen müssen manuell überprüft und angemessen entschärft werden.
• Wenn das Image-Pipeline-Skript des Frameworks aktiv ist und Sie Bilder zur Build-Zeit verkleinern, überprüfen Sie nach dem Build, dass die generierten Feature-Bilder nicht abgeschnitten, in den Falschen umgewandelt wurden oder verschwunden sind.

Wenn Sie gegen eine der Nicht-Framework-Entscheidungen verstoßen müssen (weil das Repository beispielsweise Astro im SSG-Modus bereits definiert), notieren Sie die Abweichung in app.md und begründen Sie sie.

Hinweise zum Workflow

• Das GPT_IMAGE_SKILL_DIR wird dynamisch aus dem Pfad des gpt-image-Skills aufgelöst (der innerhalb des Repository-Strukturs des Agenten als separates Unterverzeichnis existiert). Führen Sie keine cd-Befehle aus. Verwenden Sie den absoluten Pfad, der aus <repo-root>/skills/gpt-image/ abgeleitet wird, es sei denn, der Benutzer gibt einen anderen Pfad an.
• Wenn Sie auf einen Build-Fehler stoßen, fahren Sie nicht fort, ohne dass er gründlich behoben ist. Falsches Verhalten auszubügeln ist teurer, als es richtig zu machen.
• Wenn Sie mit einem Framework arbeiten, das Asset-Pipelines optimiert, legen Sie das im jeweiligen Framework fest und nicht im generischen Skript.
• Schreiben Sie beim Erstellen von Inhalten natürlich und direkt. Streben Sie nach Klarheit, nicht nach einer „Stimme". Lassen Sie die Informationen für sich sprechen.