umairmsm/wp-seo

Phase 5: SEO und Sprachen

Ziel: Suchmaschinen und KI-Assistenten verstehen jede Seite. Alte URLs landen an der richtigen Stelle. Jede zusätzliche Sprache ist genauso korrekt wie das Original.

SEO-Schritte

1. Ein Besitzer pro Aufgabe.
   • Das SEO-Plugin (standardmäßig Rank Math) besitzt Titel, Meta, Sitemaps und das Haupt-Schema-Graph.
   • Der Core (schema.php) fügt die eigenen Typen der Seite zu diesem Graph hinzu.
   • Stelle jedes Domain-Plugin stumm, das sein eigenes Schema ausgibt, damit es einen einzigen Graphen gibt, nicht zwei, die sich widersprechen.
2. Jede Seite in tests/helpers/site.ts besteht npm run test:seo:
   • Titel 10–65 Zeichen;
   • Beschreibung 50–160;
   • absolute Kanonische;
   • eine H1;
   • lang-Attribut;
   • null Google Fonts-Anfragen. Checkliste und Schreibregeln: references/seo-checklist.md.
3. Strukturierte Daten:
   • Organisation (oder LocalBusiness) einmal.
   • Der Item-Typ pro Seite (Service, Product, TouristTrip, Course, …).
   • Breadcrumbs.
   • FAQ nur für Fragen, die wirklich auf der Seite beantwortet werden.
   • Niemals ein Offer ohne Preis.
   • Mit dem Google Rich Results Test und dem Schema.org-Validator validieren.
4. Robots, Sitemap, llms.txt:
   • Live erlaubt Crawling und listet die Sitemap; Staging blockiert alles (das macht der Core);
   • /llms.txt wird vom Core ausgeliefert;
   • Entscheide bewusst, ob KI-Crawler die Seite lesen dürfen, und prüfe dann, ob der Edge sie nicht standardmäßig blockiert (wp-ship > cloudflare-edge.md).
5. Weiterleitungen: Folge dem Projekt docs/reference/REDIRECT_RULES.md. Bilde jede alte URL, die Traffic oder Backlinks hat, auf ihre nächstgelegene neue Seite ab (301, ein Hop) und teste jede einzelne.
6. Parität vor großen Änderungen. Vor einem Design-Relaunch, einer Migration oder einem Sprachstart, erfasse Titel, Beschreibung, Kanonische und H1 für jede URL. Vergleiche nach jedem Schritt. Erfasse nur für beabsichtigte Änderungen erneut, mit Grund im Commit.
7. Search Console und Bing:
   • Beide verifizieren;
   • Sitemap einreichen;
   • Seiten-Indexierung wöchentlich im ersten Monat überwachen;
   • Search Console speichert nur 16 Monate Daten, also exportiere oder aktiviere frühzeitig den Bulk-Export.

Sprachschritte (jede Sprache ist zuerst ein Pilot)

Folge references/multilingual.md. Kurz gefasst:

1. Regel Null: Die Originalsprache ändert sich nicht. Ihre URLs, Titel, kanonischen Tags und Texte bleiben identisch (der Paritätstest beweist es).
2. Pilot: Die Sprachgrundlage (Polylang, der Umschalter, hreflang, Strings in .po/.mo), dann die wichtigsten Seiten und die Top-Elemente. Dann ein Muttersprachler-Review auf Staging, dann veröffentlichen.
3. Der Rest kommt in Batches, jeder durch dasselbe Review.
4. Eine noch nicht veröffentlichte Sprache antwortet mit 302 auf die Originalsprache und taucht nirgendwo auf: nicht in Sitemaps, hreflang, Menüs oder Umschalter.

Gate (Häkchen in SITE_STATUS.md)

• npm run test:seo grün auf Staging; Rich-Results-Test sauber für eine Seite jedes Typs
• Sitemap, robots.txt und llms.txt korrekt für Live
• Alte-URL-Weiterleitungskarte vorhanden und getestet (oder "n/v")
• Jede zusätzliche Sprache: Pilot bestanden, Muttersprachler-Review erledigt, hreflang-Paare vollständig, Kanonische pro Sprache

Fehler, die wir schon einmal ausgeliefert haben (also prüfe darauf)

• Die kanonische der übersetzten Startseite zeigte auf die Original-Startseite, sodass Google /fr/ aus französischen Ergebnissen entfernt hätte. Die Kanonische einer übersetzten Seite ist die übersetzte URL.
• Englisches JSON-LD auf französischen Seiten: Das Schema muss der Sprache der Seite folgen oder weggelassen werden, bis es übersetzt ist.
• Ein Gate, das eine unveröffentlichte Sprache mit 301 auf die Startseite weiterleitete. Gates sind 302er.