Lokales SEO für Unternehmen: WordPress Multisite Strategien 2026

Die organische Sichtbarkeit für einen einzelnen Standort zu steuern, ist eine überschaubare Aufgabe. Wächst ein Unternehmen aber auf 50, 100 oder 500 Filialen, Geschäftsstellen oder Praxen in Deutschland, Österreich und der Schweiz, entsteht ein komplexes Problem technischer Governance: die zentrale Kontrolle über die Marke zu behalten, ohne die hyperlokale Relevanz für Suchen nach “in meiner Nähe” aufzugeben.

Viele Marken mit mehreren Standorten setzen auf WordPress Multisite als Infrastruktur, um die nationale Autorität der Domain mit den Besonderheiten jedes physischen Standorts zu verbinden. Dieser Leitfaden beschreibt die Architektur und zeigt an jedem Punkt, was die Dokumentation von Google und WordPress tatsächlich sagt, denn vieles, was über lokales SEO im großen Maßstab kursiert, ist Folklore.

Lernen Sie unsere fortgeschrittenen SEO- und GEO-Leistungen kennen, ausgelegt auf mehrregionale Unternehmensarchitekturen.

#1. Warum WordPress Multisite für mehrere Filialen

Ein häufiger Fehler großer Filialnetze besteht darin, eines von zwei problematischen Extremen zu wählen: alle Geschäfte auf einer einzigen statischen Listenseite zu bündeln oder Dutzende völlig getrennte WordPress-Installationen anzulegen. Die erste Variante hat nicht genug Tiefe, um für konkrete geografische Suchbegriffe zu ranken; die zweite erzeugt einen Albtraum aus Sicherheit und Wartung mit Hunderten Datenbanken und isolierten Dashboards.

WordPress Multisite löst dieses Dilemma mit einer einheitlichen Plattform, die ein Netzwerk von Sub-Sites aus einer einzigen Codebasis betreibt:

• Zentrale Verwaltung von Themes und Plugins: Sicherheitsupdates, das Unternehmens-Theme und Analysewerkzeuge installiert der Super-Administrator einmal auf Netzwerkebene.
• Getrennte Datentabellen: Jede Sub-Site hat einen eigenen Satz Tabellen (wp_X_posts, wp_X_options), sodass lokale Einstellungen und Beiträge strikt voneinander getrennt bleiben.
• Fein abgestufte Berechtigungen: Lokale Leiter erhalten eingeschränkten Bearbeitungszugriff, um Sonderöffnungszeiten zu ändern oder Meldungen aus der Gemeinde zu veröffentlichen, ohne die Architektur des Portals zu gefährden.

Die WordPress-Dokumentation zu Multisite fasst das Datenmodell in einem Satz zusammen: Die Inhalte jeder Website haben “eigene Tabellen in der Datenbank, nur die Benutzertabelle wird zwischen den Instanzen geteilt” (eigene Übersetzung). Dieselbe Seite erinnert daran, dass für Multisite aktive URL-Rewrites nötig sind.

#2. Unterverzeichnisse oder Subdomains für Standortseiten

Die Adressstruktur legt fest, wo jede Filiale liegt und was ihr Betrieb kostet. Die Tabelle folgt dem Vergleich, den Google unter Mehrsprachige und mehrregionale Websites verwalten veröffentlicht, angewendet auf Stadtseiten:

Google gibt keinem dieser Modelle einen Ranking-Vorteil. Für ein Filialnetz in einem einzigen Land gewinnen Unterverzeichnisse meist aus betrieblichen Gründen: ein Zertifikat, ein Hosting, eine Cache-Konfiguration. Subdomains sind sinnvoll, wenn es technische Gründe gibt, Regionen von verschiedenen Servern aus zu bedienen.

Auf WordPress-Seite erklärt die Seite Netzwerk erstellen, dass die Wahl zwischen Subdomains und Unterverzeichnissen bei der Installation des Netzwerks fällt und dass sich das Netzwerk später auf die andere Variante umkonfigurieren lässt, auch wenn die Umstellung Arbeit macht. Dieselbe Seite stellt klar, dass Wildcard-DNS nur für bei Bedarf angelegte, domainbasierte Websites nötig ist, auch wenn der Installationsbildschirm etwas anderes nahelegt.

#3. LocalBusiness-Schema für jede Filiale einbinden

Strukturierte Daten teilen Suchmaschinen ausdrücklich mit, wie jeder Standort heißt, wo er liegt und wann er geöffnet hat. Laut der Dokumentation zu strukturierten Daten für LocalBusiness können Nutzer, die in der Google-Suche oder in Maps nach Unternehmen suchen, ein Knowledge Panel mit diesen Details sehen.

Jede Sub-Site des Multisite-Netzwerks sollte ein vollständiges, spezifisches JSON-LD-Markup dynamisch erzeugen. Das Beispiel verwendet eine fiktive Marke:

<!-- Beispiel für LocalBusiness-JSON-LD einer Filiale (fiktive Marke) -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Store",
  "name": "Marke Beispiel München",
  "url": "https://example.com/muenchen/",
  "telephone": "+49 89 0000000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Beispielstraße 100",
    "addressLocality": "München",
    "postalCode": "80000",
    "addressCountry": "DE"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 48.13743,
    "longitude": 11.57549
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "09:00:00",
      "closes": "18:00:00"
    }
  ]
}
</script>

Die Regeln von Google, denen dieses Beispiel folgt:

• Pflichtangaben: nur name und address, mit möglichst vielen Adresseigenschaften.
• Koordinaten: In geo sollen Breiten- und Längengrad eine Genauigkeit von “mindestens 5 Nachkommastellen” haben (eigene Übersetzung).
• Öffnungszeiten: opens und closes im Format hh:mm:ss; openingHoursSpecification akzeptiert ein Objekt oder eine Liste.
• Telefon: der wichtigste Kundenkontakt, mit Länder- und Ortsvorwahl.
• URL: die vollständige Adresse des konkreten Standorts, und sie muss ein funktionierender Link sein. In einem Multisite-Netzwerk ist das die Filialseite, nicht die Startseite der Marke.
• Untertyp: Google verlangt den spezifischsten möglichen Untertyp von LocalBusiness (im Beispiel Store).
• Abteilungen: Ein Geschäft mit Apotheke oder Werkstatt kann jeden Bereich mit department beschreiben.

Ein Punkt, den viele Leitfäden übergehen: aggregateRating und review empfiehlt Google nach eigenen Worten nur für Websites, die Bewertungen über andere lokale Unternehmen sammeln. Eine Kette, die die Bewertungen ihrer eigenen Filialen auszeichnet, fällt nicht darunter.

Über benutzerdefinierte Felder (zum Beispiel Advanced Custom Fields) oder die REST API werden diese Daten in der Datenbank jeder Filiale gepflegt und automatisch ins HTML eingefügt, ohne dass das lokale Team etwas programmieren muss.

#4. NAP-Daten mit dem Google Business Profile synchronisieren

Abweichungen bei den NAP-Daten (Name, Address, Phone) zwischen Website, strukturierten Daten und Google Business Profile erzeugen Zweifel, welche Angabe stimmt. Nennt die Adresse auf der Website eine andere Postleitzahl als die im Profil hinterlegte, erhalten Nutzer und Suchmaschine zwei Versionen derselben Filiale.

Damit die Daten dauerhaft übereinstimmen, dient WordPress als Stammdatenquelle:

1. Zentrale Datenbank: Adressen, Öffnungszeiten und Kontaktdaten aller Filialen liegen in einem kanonischen Format in WordPress.
2. API-Anbindungen: Geplante Aufgaben (WP-Cron oder crontab auf dem Server) senden Änderungen an die APIs des Google Business Profile, sofern Sie Zugriff darauf haben.
3. Weitergabe von Ausnahmen: Ändert ein Filialleiter die Öffnungszeiten für einen regionalen Feiertag, geht die Änderung von einer einzigen Stelle aus an Website, strukturierte Daten und Profil.

#5. Was die Richtlinien des Google Business Profile von einem Filialnetz verlangen

Die Richtlinien zur Darstellung Ihres Unternehmens bei Google legen fest, was jeder Datensatz in WordPress enthalten muss, bevor er an das Profil geht:

• Ein Profil pro Standort: Google bittet darum, nicht mehr als eine Seite pro Standort anzulegen, “in einem einzigen Konto oder in mehreren Konten” (eigene Übersetzung).
• Name: Er muss den echten Namen des Unternehmens wiedergeben, ohne unnötige Zusätze. In einer Kette “müssen alle Standorte denselben Namen haben”, außer wenn sich der tatsächliche Auftritt von Filiale zu Filiale unterscheidet (eigene Übersetzung). Ein Feld oeffentlicher_name pro Filiale, mit auf Netzwerkebene gesperrtem Markennamen, verhindert, dass ein Filialleiter Keywords anhängt.
• Adresse: Sie muss der tatsächliche physische Standort sein; Postfächer und virtuelle Büros sind nicht zulässig.
• Telefon: unter direkter Kontrolle des Unternehmens; Google bevorzugt nach Möglichkeit eine lokale Nummer gegenüber einer zentralen Callcenter-Leitung.
• Website: Sie soll den einzelnen Standort darstellen. In einem Multisite-Netzwerk zeigt sie natürlich auf die URL der Filiale.
• Abteilungen: Abteilungen mit Publikumsverkehr, die als eigenständige Einheiten arbeiten, können ein eigenes Profil haben, mit einem anderen Namen als das Hauptunternehmen.
• Unternehmen mit Einzugsgebiet: ein Profil für die Zentrale mit definiertem Einzugsgebiet und für Kunden ausgeblendeter Adresse.

Für die Verifizierung gilt die Seite zur Bestätigung mehrerer Standorte für Unternehmen mit “10 oder mehr Standorten desselben Unternehmens” (eigene Übersetzung). Der Antrag läuft über eine Tabelle aller verwalteten Profile, steht Unternehmen mit Einzugsgebiet nicht offen und kann eine Videoverifizierung mit einer bevollmächtigten Person vor Ort erfordern. Ein Export aus den Tabellen des Multisite-Netzwerks ist der direkteste Weg, diese Tabelle ohne Kopierfehler zu erstellen.

#6. Standortseiten ohne Duplicate Content erstellen

100 Stadtseiten anzulegen, indem man nur den Ortsnamen in einem statischen Text austauscht (“Die besten IT-Dienstleistungen in Leipzig”, “Die besten IT-Dienstleistungen in Nürnberg”), erzeugt Seiten mit geringem Wert.

Die Spam-Richtlinien von Google beschreiben dieses Muster ohne Umschweife. Zu den Beispielen für Doorway-Missbrauch gehört, “mehrere Domainnamen oder Seiten zu haben, die auf bestimmte Regionen oder Städte ausgerichtet sind und Nutzer auf eine Seite weiterleiten” (eigene Übersetzung). Dieselbe Seite definiert den Missbrauch skalierter Inhalte als das Erzeugen vieler Seiten mit dem Hauptziel, Rankings zu manipulieren, statt Nutzern zu helfen. Ein Multisite-Netzwerk mit 500 nahezu identischen Sub-Sites erfüllt beide Definitionen.

Jede lokale Sub-Site sollte mit echter Substanz angereichert werden:

• Team vor Ort: Vorstellung mit Foto, Name und Fachgebiet der Mitarbeitenden der Filiale.
• Projekte und Fallstudien aus der Region: kurze Hinweise auf Arbeiten für lokale Einrichtungen und Unternehmen, wenn es sie gibt und sie veröffentlicht werden dürfen.
• Anfahrt und Verkehr: konkrete Angaben zu U-Bahn-Stationen, Bushaltestellen oder Parkplätzen in der Nähe.
• Lokale Initiativen: Hinweise auf die Teilnahme an örtlichen Messen, Vorträgen oder Sportpartnerschaften in der Gemeinde.

Der Praxistest: Gäbe es die Filialseite nicht mehr, würde der Nutzer dann eine Information verlieren, die auf der nationalen Seite fehlt. Falls nicht, sollte die Seite nicht angelegt werden.

#7. Neue Filialen mit WP-CLI anlegen

Hunderte Filialen manuell im Dashboard anzulegen, kostet Hunderte Stunden und vervielfacht die Konfigurationsfehler. Die zentrale Administration sollte dafür die Kommandozeile mit WP-CLI nutzen.

#Multisite mit Unterverzeichnissen in der wp-config.php aktivieren

Der erste Schritt ist define( 'WP_ALLOW_MULTISITE', true );. Nach dem Anlegen des Netzwerks zeigt der Installationsbildschirm die endgültigen Zeilen, angepasst an Ihre Installation; für ein Netzwerk mit Unterverzeichnissen sehen sie so aus:

/* Konfiguration eines Multisite-Netzwerks mit Unterverzeichnissen */
define('WP_ALLOW_MULTISITE', true);
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', false);
define('DOMAIN_CURRENT_SITE', 'marke.de');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

#Neue Filialen mit Bash und WP-CLI klonen

Das Skript geht von einer Vorlagen-Website aus (ID 2, unter marke.de/vorlage/). Nach dem Kopieren der Vorlagentabellen zeigen die Optionen siteurl und home noch auf die Vorlage, deshalb korrigiert Schritt 3 sie mit einem search-replace, das auf die neue Website beschränkt ist:

#!/usr/bin/env bash
# Skript zur automatisierten Bereitstellung neuer Filialen in WordPress

STADT_SLUG="muenchen"
STADT_NAME="München"
EMAIL_LEITUNG="[email protected]"

# 1. Neue Sub-Site im Multisite-Netzwerk anlegen
NEUE_BLOG_ID=$(wp site create --slug="$STADT_SLUG" --title="Marke $STADT_NAME" --email="$EMAIL_LEITUNG" --porcelain)

# 2. Einstellungen und Blöcke aus der Standardvorlage klonen (site_id 2)
wp db export /tmp/vorlage.sql --tables=$(wp db tables "wp_2_*" --format=csv)
sed -i "s/wp_2_/wp_${NEUE_BLOG_ID}_/g" /tmp/vorlage.sql
wp db import /tmp/vorlage.sql
rm /tmp/vorlage.sql

# 3. Von der Vorlage geerbte URLs und Standort-Metadaten korrigieren
wp search-replace "marke.de/vorlage/" "marke.de/$STADT_SLUG/" --url="marke.de/$STADT_SLUG/"
wp option update blogname "Marke $STADT_NAME" --url="marke.de/$STADT_SLUG/"
wp post update 1 --post_title="Filiale $STADT_NAME" --url="marke.de/$STADT_SLUG/"

echo "Sub-Site unter marke.de/$STADT_SLUG/ mit ID $NEUE_BLOG_ID einsatzbereit"

Testen Sie das Skript in einer Staging-Umgebung, bevor Sie es in der Produktion einsetzen: Das Kopieren von Tabellen läuft nicht über die WordPress-Hooks, und Plugins, die Daten in eigenen Tabellen speichern, brauchen eine gesonderte Behandlung.

#8. Wer in der Administration eines Multisite-Netzwerks was kontrolliert

Die Aufteilung der Befugnisse, die die Dokumentation zur Netzwerkverwaltung beschreibt, macht das Modell für Hunderte lokaler Leiter sicher:

• Super-Administrator: Nur der Super-Administrator installiert Themes und Plugins. In den Worten der Dokumentation: “Website-Administratoren können keine neuen Themes oder Plugins installieren” (eigene Übersetzung).
• Plugins: Der Super-Administrator kann ein Plugin für das gesamte Netzwerk aktivieren (Netzwerkweit aktivieren), etwa das Plugin, das das LocalBusiness-JSON-LD erzeugt, damit keine Filiale ohne es bleibt.
• Themes: Ein Theme muss netzwerkweit aktiviert oder im Tab Themes der jeweiligen Website erlaubt sein. Das Unternehmens-Theme steht allen zur Verfügung; alternative Themes sehen die Filialen nicht.
• Plugin-Menü: Ob Website-Administratoren den Plugin-Bildschirm sehen, ist eine Option unter Netzwerk-Einstellungen. In einer Filialkette ist es sinnvoll, sie ausgeschaltet zu lassen.
• Dateien: Die erste Website speichert Uploads in /wp-content/uploads/, die weiteren in /wp-content/uploads/sites/, was Backups und Aufräumarbeiten pro Filiale ermöglicht.

Weil die Benutzertabelle gemeinsam genutzt wird, kann ein Regionalleiter mit einem einzigen Konto die Rolle Redakteur auf zehn Sub-Sites haben und ein Filialleiter nur auf seiner eigenen.

#9. Eigene Domains für Franchisenehmer per Domain-Mapping

Nicht jeder Standort liegt unter der Hauptdomain. Ein Franchisenehmer mit eigener Marke kann seine eigene Domain verlangen. Laut der Seite zum Domain-Mapping ist diese Funktion seit WordPress 4.5 fester Bestandteil von Multisite: Im Netzwerk-Dashboard bearbeitet man unter Websites die Sub-Site und trägt die vollständige URL in das Feld Website-Adresse (URL) ein.

Die praktischen Voraussetzungen, alle von derselben Seite:

• DNS: Zusätzliche Domains müssen vor dem Mapping auf die Hauptdomain des Netzwerks zeigen.
• SSL: ein Zertifikat auf der Hauptdomain und SNI für die übrigen; jede Domain sollte SSL haben, damit die Anmeldung im Dashboard verschlüsselt ist.
• Cookies: Schlägt die Anmeldung auf einer gemappten Sub-Site fehl, empfiehlt die Dokumentation, define( 'COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] ); in die wp-config.php einzufügen, nach dem Netzwerkcode.

Der Kompromiss ist der aus der Tabelle in Abschnitt 2: Jede eigenständige Domain muss ihre Präsenz von null aufbauen, deshalb dient das Mapping Fällen von Markenidentität, nicht dem SEO.

#10. Hreflang, wenn das Netzwerk mehrere Länder abdeckt

Ein Netzwerk mit Filialen in Deutschland, Österreich und der Schweiz hat oft dieselbe Leistungsseite in drei regionalen Fassungen für de-DE, de-AT und de-CH. Hier kommt hreflang ins Spiel, das Google unter Lokalisierte Versionen Ihrer Seite beschreibt:

• Drei Methoden: link-Tags im HTML, HTTP-Header oder die XML-Sitemap. In einem Multisite-Netzwerk ist die von jeder Sub-Site erzeugte Sitemap die am leichtesten zu pflegende Methode.
• Gegenseitigkeit: “Jede Sprachversion muss sich selbst und alle anderen Versionen auflisten” (eigene Übersetzung). Verweist die österreichische Sub-Site auf die deutsche und die deutsche nicht zurück, schlägt die Annotation fehl.
• x-default: der reservierte Wert für den Fall, dass keine Sprache oder Region zur Browsereinstellung passt, zum Beispiel eine Länderauswahlseite.
• Codes: Akzeptiert werden nur Sprachcodes nach ISO 639-1 und Regionscodes nach ISO 3166-1 Alpha 2, etwa de-DE, de-AT oder de-CH. Google ist eindeutig: Der Ländercode allein lässt sich nicht angeben.
• Spracherkennung: Google nutzt weder hreflang noch das lang-Attribut im HTML, um die Sprache einer Seite zu erkennen; der sichtbare Text muss tatsächlich in dieser Sprache sein.

Stadtseiten im selben Land und in derselben Sprache bekommen untereinander kein hreflang: München und Hamburg sind keine Sprachversionen voneinander.

#11. Warum Inhalte nicht nach IP oder Browsersprache angepasst werden sollten

In großen Netzwerken ist es verlockend, Besucher automatisch zur nächstgelegenen Filiale weiterzuleiten. Dieselbe Google-Seite zu mehrregionalen Websites rät aus zwei Gründen davon ab:

• Der Crawler sendet HTTP-Anfragen ohne den Header Accept-Language, daher werden Inhalte, die sich mit der Browsersprache ändern, möglicherweise nie gefunden.
• “Verwenden Sie keine IP-Analyse, um Ihre Inhalte anzupassen” (eigene Übersetzung), weil die Standortbestimmung per IP schwierig und im Allgemeinen unzuverlässig ist.

Google empfiehlt für jede Version eine eigene URL und ignoriert Standort-Meta-Tags wie geo.position. In der Praxis heißt das: eine sichtbare Filialauswahl mit crawlbaren Links zu jeder Sub-Site statt einer stillen Weiterleitung. Zu den Signalen, mit denen Google die Zielgruppe einer Website erkennt, gehören lokale Adressen und Telefonnummern auf der Seite, ein weiterer Grund, die NAP-Daten im HTML jeder Filiale anzuzeigen.

#12. Multisite mit Edge Caching und Redis beschleunigen

Eine WordPress-Installation mit Hunderten Sub-Sites im Produktivbetrieb braucht besondere Sorgfalt bei der Architektur:

• Edge Caching per CDN: Verteilen Sie den statischen Seiten-Cache auf die Points of Presence (PoP) eines CDN wie Cloudflare oder Fastly, nahe an den Nutzern jeder Region.
• Objekt-Cache mit Redis: Installieren Sie Redis Object Cache, um die Ergebnisse von Optionen und Metadaten aus den Hunderten Tabellen des Netzwerks im Arbeitsspeicher abzulegen.
• Datenbankindizierung: Halten Sie die Tabellen wp_blogs und wp_site optimiert, damit der Webserver Anfragen reibungslos weiterleitet.

Der Serverstandort gehört ebenfalls zu den Zielgruppensignalen, die Google nennt, aber Google selbst sagt, dass er kein eindeutiges Signal ist. Das CDN sorgt für Geschwindigkeit; die geografische Ausrichtung kommt aus den Daten der Seite und aus hreflang.

#13. Reifegradmodell für lokales SEO in Unternehmen

Wer das Netzwerk seines Unternehmens auf WordPress Multisite aufbaut, verbindet die Governance eines Unternehmensportals mit Standortseiten, die Suchenden jede Filiale zeigen, vorausgesetzt, jede Seite hat eigene Inhalte und Daten, die zum Google-Profil passen.