Astro SEO

Was macht Astro SEO?

Auditiert und verbessert die SEO-Einrichtung einer Astro-Website anhand des vollständigen Stapels, der in Astro SEO: Der ultimative Leitfaden beschrieben wird. Die Fähigkeit deckt neun Bereiche ab – technische Grundlagen, strukturierte Daten, Inhalt, Seitenstruktur, Leistung, Sitemaps und Indexierung, Agentenerkennung, Weiterleitungen und Analysen – und erzeugt einsatzbereiten Code für alles, was fehlt oder schwach ist.

Das meinungsstarke Rückgrat dieser Fähigkeit ist @jdevalk/astro-seo-graph. Die meisten Korrekturen laufen darüber. Wenn das Projekt es noch nicht verwendet, ist die Installation die erste Empfehlung.

Code-Rezepte befinden sich in AGENTS.md – lesen Sie sie, wenn Sie eine bestimmte Korrektur implementieren müssen. Diese Datei enthält den Workflow und die Audit-Checkliste.

Workflow

1. Projekt erkennen – bestätigen, dass es sich um eine Astro-Website handelt und deren Struktur verstehen.
2. Auditieren – neun Kategorien bewerten und umsetzbare Ergebnisse liefern.
3. Verbessern – Dateien generieren oder ändern, um die Lücken zu schließen. Rezepte befinden sich in AGENTS.md.
4. Metadaten-Durchlauf – metadata-check für jede kurze Zeichenfolge aufrufen, die die Fähigkeit generiert hat (Titel, Beschreibungen, Schema-description-Felder, FAQ-Antworten, Frontmatter-Auszüge).
5. Überprüfen – den Build ausführen, prüfen, ob die Validierungen bestanden werden, den Benutzer an nicht-dateigebundene Aufgaben erinnern (Search Console, Bing Webmaster Tools, IndexNow-Schlüsselverifizierung).

---

Phase 0: Projekt erkennen

Bestätigen Sie die Grundlagen vor dem Audit:

• astro.config.mjs / astro.config.ts existiert.
• package.json hat astro als Abhängigkeit.
• site: ist in astro.config gesetzt – kanonische URLs, Sitemaps und OG-Bild-URLs leiten sich davon ab. Wenn es fehlt, leer ist oder http://localhost ist, markieren Sie es als blockierendes Problem vor allem anderen. Dies ist die häufigste Fehlkonfiguration.
• Inhaltskollektionen in src/content/ (oder veraltetes src/pages/ Markdown).
• Bereitstellungsziel – lesen Sie package.json, vercel.json, netlify.toml, wrangler.toml oder public/_headers, um den Host zu bestimmen. Dies bestimmt die Weiterleitungs- und Header-Syntax in Phase 2.
• Ist @jdevalk/astro-seo-graph bereits installiert? Wenn ja, notieren Sie die Version und welche Funktionen verdrahtet sind (grep nach <Seo, seoGraph(, createSchemaEndpoint, createSchemaMap, FuzzyRedirect, createIndexNowKeyRoute, createMarkdownEndpoint, createApiCatalog, gitLastmod). Überprüfen Sie die installierte Version mit der neuesten auf npm mit npm view @jdevalk/astro-seo-graph version. Wenn das Projekt zurückliegt, empfehlen Sie in Phase 2 ein Upgrade, bevor Sie Funktionslücken auditieren – das Paket liefert regelmäßig neue Standardeinstellungen und Korrekturen, und eine veraltete Version ist eine plausible Ursache für jedes Auditergebnis. Phase 2 verzweigt darauf.
• Ist die Website mehrsprachig? Prüfen Sie auf i18n in astro.config oder mehrere Gebietsschema-Verzeichnisse unter src/content/. Wenn ja, ist hreflang wichtig; wenn nein, überspringen Sie es.

Fragen Sie nur das, was Sie nicht erkennen können. Fragen Sie den Benutzer nicht, worum es auf der Website geht – lesen Sie astro.config.mjs und den Inhalt der Startseite.

---

Phase 1: Audit

Bewerten Sie jede Kategorie mit einer Punktzahl von 10. Geben Sie für jede 2–4 spezifische Ergebnisse an, die den tatsächlichen Code oder die Konfiguration zitieren. Innerhalb jeder Kategorie sind die Prüfungen gestaffelt:

• Muss – Auslieferungsblocker. Ein Fehler hier verursacht sichtbare SEO-Verschlechterung.
• Sollte – Standardpraxis. Das Überspringen kostet Reichweite.
• Nice – zukunftsorientiert oder situativ. Nützlich, aber nicht die Grundlage für jede Website.

Überspringen Sie Nice-Prüfungen für kleine persönliche Blogs, es sei denn, der Benutzer fragt nach der vollständigen Behandlung.

1. <Seo>-Komponente und Kopf-Metadaten (/10)

• Muss – einzelne Komponente für alle Kopf-Metadaten (nicht über Layouts verstreut).
• Muss – site: in astro.config ist auf den Produktionsorigin gesetzt.
• Muss – kanonische URLs, die von der site-Konfiguration abgeleitet werden, mit entfernten Tracking-Parametern.
• Muss – kanonisch weggelassen, wenn noindex wahr ist (gemäß Googles Empfehlung).
• Muss – Fallback-Kette für fehlende SEO-Felder: seo.title → title → siteName; seo.description → excerpt → first paragraph. Seiten mit leeren Titeln oder Beschreibungen sind das häufigste Symptom einer defekten Fallback-Kette.
• Sollte – robots-Meta enthält max-snippet:-1, max-image-preview:large, max-video-preview:-1.
• Sollte – Twitter-Tags unterdrückt, wenn sie Open Graph duplizieren (Twitter greift automatisch zurück).
• Sollte – hreflang-Alternativen auf mehrsprachigen Websites vorhanden. Überspringen, wenn einsprachig.
• Nice – verwendet die <Seo>-Komponente von @jdevalk/astro-seo-graph anstelle einer handgemachten. (Eine handgemachte, die alles oben Abgedeckte enthält, ist in Ordnung; diese Fähigkeit drängt zum Paket, weil es die Fallback-Kette und Robots-Regeln standardmäßig handhabt.)

2. Strukturierte Daten / JSON-LD-Graph (/10)

• Einzelnes flaches Article-Objekt oder ein verknüpfter @graph mit mehreren Entitäten?
• Entitäten mit @id-Referenzen verdrahtet?
• WebSite, Blog/WebPage, Person/Organization, BlogPosting/Article, BreadcrumbList, ImageObject alle vorhanden, wo relevant?
• Vertrauenssignale: publishingPrinciples, copyrightHolder, copyrightYear, knowsAbout, SearchAction?
• Validiert im Rich Results Test und ClassySchema?

3. Inhaltskollektionen und SEO-Schema (/10)

• Inhaltskollektionen mit Zod-Schemas definiert?
• seoSchema von @jdevalk/astro-seo-graph erzwingt Titel-Längen (5–120) und Beschreibungs-Längen (15–160)?
• Erforderliche Felder (publishDate, title, excerpt) zur Build-Zeit erzwungen?
• Markdown-bereinigtes articleBody in Schema-Endpunkten verfügbar gemacht (bis zu 10K Zeichen)?

4. Open-Graph-Bilder (/10)

• Jede Seite hat ein OG-Bild, oder viele fehlen?
• 1200×675 (Google Discover mindestens 1200px breit, 16:9-Verhältnis)?
• Zur Build-Zeit via satori + sharp generiert oder manuell?
• JPEG (soziale Plattformen unterstützen WebP/AVIF nicht zuverlässig)?
• Leitet die Route die OG-URL automatisch vom Slug ab?
• Jedes <img> im gerenderten HTML hat ein alt-Attribut (oder alt="" / role="presentation" für dekorative Bilder)? validateImageAlt auf seoGraph() fängt dies zur Build-Zeit in ≥ 1.1.0 ab.

5. Sitemaps und Indexierung (/10)

• Muss – @astrojs/sitemap installiert, Sitemap-Index erreichbar.
• Muss – robots.txt verweist auf den Sitemap-Index.
• Muss – RSS-Feed vorhanden (@astrojs/rss), beworben via <link rel="alternate" type="application/rss+xml">, enthält vollständigen Artikelinhalt (nicht gekürzte Auszüge).
• Sollte – pro Kollektion aufgeteilt via chunks-Option (sitemap-posts-0.xml, usw.) – viel einfacher, die Indexierung in der GSC zu debuggen.
• Sollte – lastmod aus Git-Commit-Zeitstempeln, nicht aus Frontmatter-Daten oder CI-Dateizeitstempeln. @jdevalk/astro-seo-graph ≥ 1.4.0 exportiert gitLastmod(filePath, { excludeCommits, depth }) dafür – es gibt das Committer-Datum des letzten nicht ausgeschlossenen Commits zurück, der die Datei berührt hat, oder null, wenn git nicht verfügbar ist. Verdrahten Sie es in den Sitemap-serialize-Callback. Wenn die Codebasis einen handgemachten execSync('git log ...')-Helper hat, ersetzen Sie ihn durch den Paket-Export – der Export handhabt den Ausschluss von Bulk-Commits (Importe, Neuformatierungen), den eine naive -1-Suche nicht kann.
• Sollte – IndexNow integriert und bei jedem Build einreichend, mit Schlüsselverifizierungsroute unter /[key].txt. ≥ 1.0.1 schließt /404 standardmäßig von Einreichungen aus. Tor für Einreichung auf den Produktionshost beschränken (z.B. process.env.CF_PAGES === '1' && CF_PAGES_BRANCH === 'main', VERCEL_ENV === 'production', CONTEXT === 'production'). Bedingungslose Einreichung pingt den Endpunkt bei jedem lokalen npm run build und Preview-Deployment mit URLs, die der Produktionshost noch nicht bedient hat, was den Schlüssel als ungültig markiert (403) und eine Rotation erzwingt.

6. Agentenfindung (/10)

• Sollte – Schema-Endpunkte (/schema/*.json), die korpusweites JSON-LD bereitstellen.
• Sollte – Schema-Map (/schemamap.xml), die alle Endpunkte auflistet, mit Schemamap:-Direktive in robots.txt.
• Sollte – llms.txt im Stammverzeichnis der Website, das Seiten (Titel + Beschreibung) für LLM-Konsumenten auflistet. @jdevalk/astro-seo-graph ≥ 0.9.0 generiert dies über die llmsTxt-Integrationsoption.
• Sollte – Markdown-Alternativ-URLs (/blog/post.md neben /blog/post/), die sauberes Markdown mit YAML-Frontmatter für KI-Agenten bereitstellen, ohne HTML-Parsing. @jdevalk/astro-seo-graph ≥ 1.2.0 liefert createMarkdownEndpoint für die Route und eine markdownAlternate: true-Integrationsoption, die <link rel="alternate" type="text/markdown"> auf jeder Seite ausgibt. ≥ 1.3.0 fügt Post-Build-Validierung hinzu: Die Integration durchläuft die Build-Ausgabe und entfernt jeden Link, dessen .md-Ziel nicht auf der Festplatte ist (mit einer warn pro Vorkommen) – so wird ein falsch konfigurierter Endpunkt als Build-Warnung statt als ausgelieferter 404 angezeigt. Kombinieren Sie dies mit einer Cloudflare-Transform-Regel (URL-Umschreibung via wildcard_replace, kein Vary: Accept-Header – CF entfernt benutzerdefinierte Vary-Werte) für Inhaltsaushandlung auf Accept: text/markdown ohne SSR.
• Sollte – API-Katalog unter /.well-known/api-catalog gemäß RFC 9727. @jdevalk/astro-seo-graph ≥ 1.4.0 liefert createApiCatalog, das Schema-Endpunkte automatisch ihren https://schema.org/<Type>-URLs zuordnet und Pfade gegen siteUrl absolutisiert. Listen Sie die Schema-Endpunkte, die Schema-Map und alle seitenbezogenen APIs (/ask, /feed.xml, usw.) auf. Der RFC ist abgeschlossen, daher ist das Format stabil; die Einführung ist früh, aber die Kosten sind eine Routendatei.
• Sollte – Content-Signals-Direktive in robots.txt (z.B. Content-Signal: ai-train=yes, search=yes, ai-input=yes). Deklariert Präferenzen für KI-Training, Suchfundierung und KI-Eingabe unabhängig vom Crawl-Zugriff. Die Spezifikation ist ein IETF-Entwurf und die Einführung ist früh, aber es ist eine Zeile in einer Datei, die jede Website bereits hat.
• Sollte – Link-Header auf /*, der auf Erkennungsdateien verweist (Sitemap, llms.txt, api-catalog, schemamap und alle MCP/A2A-Karten, die die Website veröffentlicht). Agenten, die Antwort-Header lesen, finden sie ohne HTML-Parsing. Auf Cloudflare Pages / Netlify ist dies public/_headers; auf Vercel ist es vercel.json.
• Nice – MCP-Server-Karte unter /.well-known/mcp/server-card.json (SEP-1649) und/oder A2A-Agenten-Karte unter /.well-known/agent-card.json (A2A-Protokoll). Nur relevant, wenn die Website tatsächlich einen MCP-Server oder A2A-Agenten bereitstellt. Beides sind statische JSON-Dateien, die den Endpunkt, Fähigkeiten und Fähigkeiten deklarieren. Sonst überspringen.
• Nice – <link rel="nlweb">, der auf einen Konversationsendpunkt verweist. NLWeb ist früh; der Tag ist eine Zeile und wertvoll, aber es ist kein Bewertungsblocker im Jahr 2026.
• Nice – ARD (Agentic Resource Discovery)-Katalog unter /.well-known/ai-catalog.json, der auflistet, was die Domain bietet (MCP-Server, A2A-Agent, OKF-Bundle, seitenbezogene APIs). v0.9-Entwurf, also optional – aber es ist die Erkennungsschicht, durch die sich die MCP-/A2A-Karten und das OKF-Bundle auszahlen. Zwei Fallstricke: Die Basis-Spezifikation (Agent-Card/ai-catalog) benennt das Media-Type-Feld mediaType, während die ARD-Schicht (ards-project/ard-spec) es type nennt – geben Sie beide Schlüssel mit demselben Wert aus, damit der Eintrag unter beiden Lesarten validiert (beide Spezifikationen erfordern, dass Konsumenten unbekannte Schlüssel ignorieren). ARD fügt außerdem ein optionales representativeQueries-Array mit Beispiel-Prompts pro Eintrag hinzu.
• Nice – OKF (Open Knowledge Format)-Bundle: ein Baum von typisierten Markdown-Konzeptdateien (eine pro Seite, Pfade spiegeln kanonische URLs wider), verpackt als einzelnes .tar.gz, mit Indexdateien dazwischen. Bereitstellung und Erkennung sind explizite Nicht-Ziele von OKF – dafür ist der ARD-Katalogeintrag da. v0.9-Entwurf, optional. Es gibt noch keinen registrierten Media-Type, daher ist der Zwischenstring application/okf-bundle+gzip (verfolgt in knowledge-catalog#111 und ard-spec#27); markieren Sie ihn als vorläufig, er kann sich ändern. Am besten als eine weitere Ausgabe einer bestehenden Content-Pipeline generiert anstatt als manuell gepflegte Kopie.

7. Leistung (/10)

• Statische Ausgabe standardmäßig (kein SSR auf Seiten, die es nicht benötigen)?
• Null clientseitiges JavaScript, es sei denn, eine Insel erfordert es?
• Astro <Image>-Komponente für alle Inhaltsbilder verwendet (responsives srcset, WebP, lazy, async)?
• Primäre Webschriftart in woff2 vorgeladen?
• <ClientRouter /> mit defaultStrategy: 'viewport' für Prefetch?
• Gehashte Assets unter /_astro/ dienen Cache-Control: public, max-age=31536000, immutable?
• No-Vary-Search-Antwort-Header entfernt UTM-Parameter aus dem Cache-Schlüssel?

8. Weiterleitungen und Fehlerbehandlung (/10)

• public/_redirects (oder Äquivalent) für jede URL gepflegt, die jemals existiert hat und verschoben wurde?
• 301 nicht 302 für dauerhafte Verschiebungen?
• FuzzyRedirect-Komponente von @jdevalk/astro-seo-graph in die 404-Seite eingebunden?
• Die 404-Seite selbst gibt einen 404-Status zurück, nicht 200?

9. Build-Zeit-Validierung und Inhaltsqualität (/10)

• Muss – seoGraph()-Integration läuft bei jedem Build mit aktiviertem validateH1 und validateUniqueMetadata. Für die JSON-LD-Validierung übergeben Sie warnOnDanglingReferences: true an assembleGraph() in seo-graph-core – das ist die Zusammenstellungszeitprüfung, keine Integrationsoption.
• Sollte – validateImageAlt, validateMetadataLength und validateInternalLinks sind auf seoGraph() aktiviert (alle standardmäßig true in ≥ 1.1.0). Sie fangen fehlende Alt-Texte, Titel oder Beschreibungen außerhalb der SERP-Grenzen (Standard: Titel 30–65, Beschreibung 70–200) und interne Links, die auf einen 404 oder einen Trailing-Slash-Konflikt stoßen. Aktualisieren Sie auf ≥ 1.1.1, wenn das Projekt auf 1.1.0 ist – diese Patch-Version behebt zwei Validator-Fehler: validateInternalLinks erkennt jetzt public/-Assets als gültige Ziele (keine Fehlalarme mehr bei /images/* oder /fonts/*), und validateMetadataLength kürzt Beschreibungen nicht mehr, die Sonderzeichen enthalten (verfolgt in seo-graph#42).
• Sollte – validateHeadings aktiviert auf seoGraph() (standardmäßig true in ≥ 1.1.3)? Erzwingt eine einzelne <h1> und eine konsistente Hierarchie (h2 > h3, keine Sprünge). 1.1.3 fügt die Fähigkeit hinzu, <Astro.Head>-Injektionen von <ClientRouter /> (<title>, <meta>, <link>-Tags) zu ignorieren – dadurch werden falsche Positivmeldungen bei Seiten vermieden, die auf clientseitiges Routing angewiesen sind.
• Sollte – Inhaltskollektionen haben einen modifiedAt-Index in ihrer Frontmatter? Führt git log -1 --format=%cI <file> bei jedem Build aus und speichert das Ergebnis. Ohne ihn sind Sitemap- oder RSS-lastmod-Wert