SEO

Jede Seite gibt einen vollständigen Head aus, eine strukturierte Beschreibung ihrer selbst, eine Social Card und einen Eintrag in der Sitemap. Das meiste davon schreibt Nuxt SEO, das die Ebene als ein Bündel installiert; der Rest ist der Teil, der von Versionen und Übersetzungen abhängt, und der gehört der Ebene selbst. Ein Wert muss von dir kommen.

#Je Seite

• Meta — der Titel mit angehängtem Namen der Seite, die Beschreibung und das daraus abgeleitete Paar aus og: und twitter:. og:type und og:url werden je Seite gesetzt; og:locale und seine Alternativen stammen aus den Locales, die die Seite bedient.
• JSON-LD — ein Graph je Seite: eine WebSite (und deine Organization, sobald gesetzt), seitenweit deklariert, dazu ein TechArticle und eine BreadcrumbList, gebaut aus derselben Spur, die auch der Breadcrumb zeichnet.
• Ein Open-Graph-Bild, gerendert aus der Vorlage der Ebene — auch auf der Startseite. Liefere eine Komponente gleichen Namens, um sie zu ersetzen.
• canonical und robots, die die Versionshälfte sind — siehe URLs und Versionen. Das canonical einer alten Version zeigt auf die aktuelle; darum schreibt die Ebene es selbst, statt das automatische des Moduls stehen zu lassen.

Die Fehlerseite trägt noindex, follow: Eine indexierte 404 konkurriert mit der Seite, die die Lesende gesucht hat, und die Vorschläge darauf sind echte Seiten, die ein Crawler weiterhin erreichen soll.

#Seitenweit

/sitemap.xml listet die Seiten der Standardversion, je Locale. Eine Nicht-Standardversion ist ausgeschlossen, weil ihre Seiten ohnehin noindex tragen, und eine eol-Version ist ausgeschlossen, ob sie der Standard ist oder nicht: Eines von beidem aufzulisten hieße, einen Crawler genau das abrufen zu lassen, was die Seite ihm dann zu verwerfen sagt. /robots.txt wird daneben erzeugt.

duxt.organization benennt die Herausgeberin — siehe Konfiguration. Ungesetzt beschreibt sich die Seite weiterhin als WebSite; was fehlt, ist die Instanz dahinter, und genau die liest ein Wissenspanel oder eine KI-Zusammenfassung, um eine Quelle zu nennen.

#Was geprüft und was nur berichtet wird

pnpm check:seo liest die gebauten Seiten und schlägt fehl über ein zweites canonical, ein fehlendes hreflang, eine indexierbare Fehlerseite, ein og:locale im falschen Format oder einen Graphen, der nicht parst. Es läuft in pnpm check nach dem Build, weil diese Tags nur im gerenderten HTML existieren.

Die Link-Prüfung berichtet, statt fehlzuschlagen. Ein ins Leere zeigender Link lässt den Build bereits über die eigenen Build-Prüfungen der Ebene scheitern — sie sind es, die Versionen und Sprach-Rückfälle verstehen. Der Wert des Moduls liegt hier im Devtools-Panel und in der laufenden Prüfung beim Schreiben.

#Der eine Wert, den du angeben musst

Der Ursprung. hreflang, canonical, die Sitemap und die Open-Graph-Bilder sind allesamt absolute URLs, und eine Ebene kann die Domain nicht kennen, auf die sie ausgerollt wird. Setze i18n.baseUrl oder NUXT_PUBLIC_I18N_BASE_URL; die Ebene kopiert es nach site.url, wo die SEO-Module nachsehen.

Bleibt er ungesetzt, fällt jedes von ihnen auf relative Ausgabe zurück, statt eine Domain zu erfinden. Das ist die bewusste Wahl: Ein relatives canonical löst weiterhin korrekt auf, und ein geratenes ist aktiv falsch — es würde einen Crawler auf die Seite eines anderen zeigen.

#Noch eine Variable für ein rollierendes Deployment

NUXT_OG_IMAGE_SECRET signiert die URLs der Open-Graph-Bilder. Ohne sie wird je Build ein Geheimnis erzeugt, was bei einer Instanz in Ordnung und bei zweien falsch ist: Eine Card, deren URL von einer Instanz signiert wurde, wird von der nächsten abgelehnt — ein während eines rollierenden Deployments geteilter Link verliert also sein Bild. Erzeuge sie einmal; sie rotiert nicht.