RH SEO self-updates

SEO-Grundgerüst auf Basis zentraler Firmen-Stammdaten. Teil der rh-blueprint Kollektion.

Die Firmendaten werden einmal gepflegt, daraus baut das Plugin den strukturierten Datensatz und die Meta-Tags, statt alles im Theme zu hardcoden.

Was es macht

• Stammdaten als Single Source: Name, Typ, Adresse, Geo, Kontakt, Öffnungszeiten, Social-Profile, Logo.
• JSON-LD @graph mit @id-Verknüpfung: Organization, LocalBusiness (oder gewählter Typ), WebSite, WebPage, BreadcrumbList auf Unterseiten. Eine Kern-Entity, alles referenziert sie statt zu duplizieren.
• Meta-Tags: Meta-Description, Open Graph, Twitter Cards, Canonical (eigenes rel_canonical, trailingslashit-konsistent).
• SEO-Meta-Box pro Seite: eigener Browser-Title, eigene Meta-Description und ein noindex-Schalter, unabhängig vom redaktionellen Auszug. Der Schalter wirkt an beiden Stellen, an denen er wirken muss: im robots-Tag und in der XML-Sitemap.
• Seiten-Schema pro Seite: was diese eine Seite darstellt, in Endkundensprache (normale Seite, Leistung, Standort) plus ein unabhängiger Schalter für Fragen und Antworten. Siehe unten.
• Technik-Cleanup: Autoren/Beiträge/Taxonomien aus der Sitemap, erweiterte Robots-Direktiven (max-snippet:-1 etc.), konfigurierbares lang-Attribut.
• Weiterleitungen: 301/302/410 mit exaktem Pfad-Match, automatischer 301 bei Slug-Änderung, 404-Monitor (ohne IP) mit Ein-Klick-Weiterleitung, Loop-/Self-Warnung, CSV-Import. Gedacht für Strukturumbauten ohne SEO-Verlust.

Seiten-Schema (pro Seite)

Das Schema-Mapping im SEO-Tab beschreibt einen ganzen Inhaltstyp. Für Seiten, die sich untereinander unterscheiden, reicht das nicht: fünf Standortseiten sind alle page, brauchen aber je eine eigene Adresse. Dafür gibt es im Editor die Box Seiten-Schema.

Was ist diese Seite? Drei Begriffe statt 31 schema.org-Typen, damit der Endkunde sie ohne Vorwissen bedienen kann:

• Normale Seite: kein zusätzlicher Knoten.
• Leistung: Name und Kategorie der Leistung, ergibt einen Service mit deinem Betrieb als Anbieter und dem Einzugsgebiet aus den Stammdaten.
• Standort: eigener Name, Adresse, Telefon, Koordinaten, Einzugsgebiet und Öffnungszeiten, ergibt ein eigenes LocalBusiness mit parentOrganization auf deine Organisation. Der Hauptsitz aus den Stammdaten bleibt daneben bestehen, das ist die übliche Struktur aus Mutter und Filialen.

Adresse und Koordinaten eines Standorts fallen nie auf die Stammdaten zurück. Eine Filiale mit der Anschrift des Hauptsitzes wäre über alle Verzeichnisse hinweg falsch, schlimmer als gar kein Markup. Ohne Ort und ohne Straße oder Koordinaten entsteht deshalb kein Standort. Zurückfallen dürfen nur ortsunabhängige Angaben: Telefon, Öffnungszeiten, Preisniveau, Bild, Land.

Auf der Startseite entsteht kein eigener Standort, dort steht der Hauptsitz bereits.

Fragen und Antworten

Ein davon unabhängiger Schalter, weil eine Seite Standort UND Fragensammlung sein kann und die Fragen kein einziges Eingabefeld brauchen: rh-seo liest sie aus dem Seiteninhalt. Der Kunde pflegt sie einmal, im Editor. Die Box zeigt, was gefunden wurde, weist auf Auffälligkeiten hin (doppelte Frage, sehr kurze Antwort) und blendet auf Wunsch die erzeugte Auszeichnung ein.

Technisch wird der vorhandene WebPage-Knoten zu ["WebPage","FAQPage"] erweitert statt ein zweiter Knoten unter derselben URL angelegt. Ist auf einer Seite beides gesetzt, bekommt die Fragensammlung den mainEntity-Platz (Pflicht-Eigenschaft von FAQPage), der Standort hängt dann über mainEntityOfPage an der Seite.

Erkannt werden von Haus aus core/accordion und core/details. Bringt ein Theme einen eigenen FAQ-Block mit, wird er im Schema-Bereich unter FAQ-Quellen eingetragen, ohne eine Zeile Code. Frage und Antwort beschreibt ein Kürzel:

Zwei Kürzel lassen sich verbinden: mit > sucht das zweite nur noch innerhalb des ersten, mit || gilt das erste, das etwas findet. Für ganz eigene Bauweisen bleibt der Filter rhseo/faq/items.

Blöcke, die alle Fragen als Liste halten. Ein selbstgebauter FAQ-Block speichert seine Paare oft als Array in einem einzigen Attribut, statt pro Frage einen eigenen Block anzulegen:

<!-- wp:theme/faq {"faqs":[{"question":"…","answer":"…"}, …]} /-->

Dafür gibt es die Spalte Liste: dort steht das Attribut, das die Liste hält (attr:faqs, die Schreibweise attr:faqs[] geht auch), und Frage und Antwort greifen mit field: in jeden Eintrag. Die Feldnamen sind frei, sie müssen nur zu denen im Array passen. Bleibt die Spalte leer, gilt wie bisher ein Block als genau ein Paar. Einträge, denen Frage oder Antwort fehlt, fallen raus, wie bei jeder anderen Bauweise auch.

Hinweis: Google zeigt seit dem 7. Mai 2026 keine FAQ-Rich-Results mehr. Das Markup bleibt gültig und wird von KI-Suchsystemen weiter gelesen, in der Trefferliste erscheint es aber nicht mehr.

Weiterleitungen

Eigener Tab RH Blueprint → Weiterleitungen mit zwei Bereichen:

• Weiterleitungen: Liste der aktiven Regeln (Quelle → Ziel, Typ, Treffer). Anlegen über das Formular oder den CSV-Import (source,target,code, eine Zeile pro Regel, Kopfzeile optional). Ziel per Seiten-Suche oder freier URL. Typen: 301 dauerhaft (Standard), 302 temporär, 410 gelöscht (kein Ziel). Query-Parameter optional mitnehmen. Beim Speichern werden Self-Redirects und Loops geblockt, Ketten gewarnt (mit "direkt aufs Endziel"-Aktion).
• 404-Fehler: automatisch gesammelte 404 (URL, Treffer, letztes Auftreten), nach Häufigkeit sortiert. Pro Eintrag "Weiterleiten" (öffnet das Formular vorbefüllt) oder "Ignorieren". Speichert keine IP. Alte Einträge werden nach einer einstellbaren Frist automatisch gelöscht (ignorierte bleiben).

Konfiguration (Auto-Slug-Redirect, 404-Monitor, Query-Default, Aufbewahrungsdauer) im Zahnrad-Modal oben rechts. Die Weiterleitung greift früh (parse_request), damit sie vor dem WordPress-eigenen Canonical-Redirect liegt.

Einstellungen

Im Backend unter RH Blueprint → SEO, zwei Gruppen:

• Stammdaten: Firmenname, Rechtsname, Unternehmenstyp (LocalBusiness, Dienstleister, Handwerk, Gastronomie, reine Organisation), E-Mail, Telefon, USt-IdNr., Gründer, Adresse, Geo-Koordinaten, Einzugsgebiet-Radius, Logo-URL, Open-Graph-Bild, Preisniveau, Öffnungszeiten (eine Zeile pro Eintrag), Social-Profile (eine URL pro Zeile).
• Technik: Sitemap-Bereinigung (Autoren/Beiträge/Taxonomien), Robots-Erweiterung, lang- und og:locale-Wert.

Pro Seite zusätzlich die SEO-Box (Meta-Description + noindex). Weiterleitungen liegen im eigenen Tab (siehe oben).

noindex, Canonical und geschützte Inhalte

Drei Regeln, die keinen Schalter haben, weil sie kein Geschmack sind:

• Ein noindex-Haken schließt die Seite überall aus. Sie verschwindet aus der XML-Sitemap (jeder Inhaltstyp, auch aus dem Sitemap-Index) und bekommt genau ein robots-Tag mit noindex, follow. Die Direktiven zur Trefferdarstellung (max-snippet, max-image-preview) fallen dort weg, sie beschrieben einen Treffer, den es nicht geben soll. Wer den Sitemap-Ausschluss für eine Site nicht will, hängt sich an den Filter rhseo/sitemap/exclude_noindex.
• Die Canonical zeigt auf die aufgerufene Adresse. Einzelinhalte über die Core-Rechnung (wp_get_canonical_url), also mit der Blätterung mehrseitiger Beiträge und dem get_canonical_url-Filter. Alles andere über den aufgelösten Pfad der Anfrage. Suchergebnisse und 404 bekommen keine Canonical und kein JSON-LD, beide sind ohnehin auf noindex.
• Passwortgeschützter Text bleibt hinter dem Passwort. Weder Meta-Description noch Open Graph noch die FAQ-Auszeichnung noch die Beschreibung aus dem Schema-Mapping lesen den Inhalt einer geschützten Seite. Übrig bleibt, was ausdrücklich als öffentlicher Text gepflegt ist: das SEO-Feld, ein zugeordnetes Meta-Feld, sonst die Firmen-Kurzbeschreibung.

Installation

ZIP unter Plugins → Plugin hochladen installieren und aktivieren, dann unter SEO die Stammdaten eintragen. Der geteilte Core ist gebündelt.

Voraussetzungen

WordPress 6.5+, PHP 8.1+.