Eine Franchise-Website mit mehreren Standorten braucht eine gemeinsame WordPress-Infrastruktur mit Standortseiten auf Basis einer wiederverwendbaren Vorlage. Die richtige Architektur – ob Unterverzeichnisse in einer einzelnen WordPress-Installation oder ein Multisite-Netzwerk – ermöglicht es der Zentrale, Markenstandards durchzusetzen, und gibt den einzelnen Franchise-Standorten genug Spielraum, um in der lokalen Suche zu ranken. Wer diese Entscheidung am ersten Tag richtig trifft, spart sich später monatelange Nacharbeit.
Die meisten Franchise-Websites scheitern nicht an schlechtem Design, sondern an einer Architekturentscheidung, die zu früh getroffen wurde, ohne die Zielkonflikte bei SEO und Betrieb zu verstehen. Dieser Leitfaden zeigt, was Sie entscheiden sollten, in welcher Reihenfolge und warum.
Das Wichtigste in Kürze
- URL-Strukturen mit Unterverzeichnissen sind für die meisten Franchise-Websites der praktische Standard – sie vereinfachen Analytics, interne Verlinkung, Content-Governance und Crawling unter einer Domain. Google gibt an, Subdomains und Unterverzeichnisse gleichermaßen ranken zu können; die Wahl ist vor allem eine Architektur-, keine Ranking-Entscheidung.
- Eine einzelne WordPress-Installation bewältigt die meisten Franchise-Netzwerke effizient. Multisite ist sinnvoll, wenn Standorte wirklich operativ getrennt sein müssen – eigene Administratoren, eigene Berechtigungen oder mehrere Franchise-Marken, die sich eine WordPress-Engine teilen, statt getrennte Codebasen zu pflegen.
- Standortseiten brauchen wirklich unterschiedliche Inhalte – nicht nur ausgetauschte Städtenamen. In den Umsetzungen von IMADO bauen wir jede Standortseite um mindestens fünf standortspezifische Elemente auf, damit sich die Seiten spürbar voneinander unterscheiden.
- Strukturierte Daten vom Typ LocalBusiness liefern Google eindeutige, maschinenlesbare Informationen zu jedem physischen Standort und können geeignete lokale Suchfunktionen unterstützen. Auf Franchise-Websites werden sie durchweg zu wenig umgesetzt.
- Die Performance-Anforderungen von Franchise-Websites wachsen mit dem Traffic und der Komplexität der Abfragen, nicht mit der Zahl der Standorte. CDN und Object Caching werden wichtig, wenn Sie stark besuchte Standortseiten, aufwendige Geo-Abfragen oder dynamische Integrationen pro Standort haben – nicht einfach, weil eine bestimmte Seitenzahl überschritten ist.
URL-Struktur für Franchise-Websites: Unterverzeichnis, Subdomain oder eigene Domains?
Für die meisten Franchise-Websites sind Unterverzeichnisse die richtige Wahl. Die Pfadstruktur domain.com/locations/chicago/ hält alle Inhalte unter einer Domain, was Crawling, interne Verlinkung, Analytics und Content-Governance vereinfacht. Dabei geht es nicht in erster Linie um Rankings – Google gibt an, Unterverzeichnis- und Subdomain-Strukturen gleichermaßen ranken zu können.
Die Daten aus Fallstudien sprechen eher für Unterverzeichnisse. Als IWantMyName von einem Unterverzeichnis auf Subdomains umstieg, sank der organische Traffic laut einer von CognitiveSEO dokumentierten Fallstudie um 47 %. Pink Cake Box ging den umgekehrten Weg – von Subdomains zu Unterverzeichnissen – und gewann 40 % organischen Traffic. Das sind nützliche Anhaltspunkte, auch wenn Google selbst angibt, beide Strukturen gleichermaßen ranken zu können. Entscheiden Sie danach, was sich im Betrieb einfacher verwalten lässt.
Subdomains haben einen berechtigten Anwendungsfall: Franchise-Systeme, in denen einzelne Standorte rechtlich oder markenseitig eigenständig auftreten, jeweils mit eigenem Google-Unternehmensprofil, anderen Leistungen und Inhalten, die deutlich von der Zentrale abweichen. Selbst dann schneidet ein gut strukturiertes Unterverzeichnis-Setup aus reiner SEO-Sicht meist besser ab.
Eigene Domains pro Standort sind den Betriebsaufwand fast nie wert, es sei denn, Sie führen ein echtes Portfolio mehrerer Marken und kein Franchise-System mit einheitlicher Markenidentität.
| Faktor | Unterverzeichnis | Subdomain | Eigene Domain |
|---|---|---|---|
| Bündelung des SEO-Werts | Am besten | Zersplittert | Vollständig zersplittert |
| Steuerung durch die Zentrale | Am einfachsten | Mittel | Am komplexesten |
| Redakteure pro Standort | Möglich (rollenbasiert) | Einfacher | Am einfachsten |
| Einrichtungsaufwand | Gering | Mittel | Hoch |
| Empfohlen für Franchise-Systeme | Ja | Nur in Sonderfällen | Nur für Markenportfolios |
WordPress Multisite oder einzelne Installation: Welche Architektur passt zu Ihrem Franchise-System?
Die richtige Architektur hängt davon ab, wie stark die Standorte operativ getrennt sein müssen, nicht von ihrer Anzahl. Ein zentral verwaltetes Netzwerk mit 100 Standorten kann auf einer einzelnen Installation mit einem eigenen Beitragstyp Location (CPT) gut funktionieren. Acht Franchisenehmer, die eigene Administratoren, unabhängige Plugin-Konfigurationen oder eine eigene Markenführung auf einer gemeinsamen Engine brauchen – das ist ein Fall für Multisite.
Multisite bringt echten Betriebsaufwand mit sich. Jedes Plugin muss Multisite-kompatibel sein, und netzwerkweite Änderungen erfordern Super-Admin-Rechte. Theme-Updates wirken gleichzeitig auf alle Unterseiten – das ist mächtig, wenn es funktioniert, und störend, wenn nicht. In einem Netzwerk, in dem die Zentrale alle Inhalte steuert, bringt Ihnen dieser Aufwand nichts.
Damit sich WordPress-Multisite-Entwicklung lohnt, sollte mindestens eine dieser Bedingungen erfüllt sein: Franchisenehmer müssen ihre Inhalte selbstständig verwalten, einzelne Standorte brauchen eigene Plugin-Konfigurationen, oder Ihre Rechtsstruktur verlangt eine Datentrennung zwischen den Standortgesellschaften. Multisite passt außerdem gut zu Franchise-Gruppen, die mehrere eigenständige Marken auf einer WordPress-Engine betreiben – das ist deutlich günstiger, als für jede Marke eine eigene Codebasis zu pflegen.
Als grober Ausgangspunkt prüfen wir Multisite meist ab etwa 20 Standorten – diese Zahl ist aber zweitrangig gegenüber der Frage, wie das Netzwerk betrieben wird.
| Szenario | Empfohlene Architektur |
|---|---|
| Zentral verwaltete Inhalte, beliebige Zahl an Standorten | Einzelne Installation + Location-CPT |
| Redakteure pro Standort, unabhängige Konfigurationen | WordPress Multisite |
| Mehrere Franchise-Marken, gemeinsame WordPress-Engine | WordPress Multisite |
Was jede Standortseite enthalten muss
In unseren Franchise-Projekten bauen wir jede Standortseite um fünf standortspezifische Inhaltselemente auf. Googles Richtlinien zu Brückenseiten warnen vor „vielen ähnlichen Seiten, die jeweils leicht für eine andere Stadt abgewandelt sind“ – Ziel sind Seiten, die für Besucher an diesem Standort wirklich nützlich sind, nicht nur Vorlagen mit ausgetauschtem Städtenamen.
Die fünf Signale, die eine Standortseite wirklich eigenständig machen: eine standortspezifische Überschrift mit Bezug zur Umgebung (nicht nur der eingefügte Städtename), vollständige NAP-Daten (Name, Adresse, Telefonnummer), eine eingebettete Google-Karte, eine eigene Leistungsbeschreibung mit lokalem Kontext – Orientierungspunkte in der Nähe, Einzugsgebiet, Bezüge zu lokalen Kunden – und Bewertungen, die gezielt aus dem Google-Unternehmensprofil dieses Standorts stammen.
Kleine Formatunterschiede wie „Suite“ und „Ste.“ spielen selten eine Rolle – Google normalisiert Adressen zuverlässig. Achten Sie stattdessen darauf, dass die tatsächlichen Unternehmensdaten auf Ihrer Website und im GBP übereinstimmen: Unternehmensname, Adresse, Telefonnummer, Website-URL und Öffnungszeiten. Daran bemisst Google die Relevanz und baut die lokale Entität auf.
Um Google Maps einzubetten, ohne die Core Web Vitals zu verschlechtern, muss der iframe per Lazy Loading geladen werden. Laden Sie ihn erst, wenn der Nutzer zur Karte scrollt, nicht beim ersten Seitenaufruf. Eine Franchise-Website mit 30 Standortseiten, von denen jede sofort eine vollständige Google-Karte lädt, wird beim LCP durchgehend durchfallen.
Standortspezifische Bewertungen dynamisch einzubinden, erfordert eine Anbindung an die Google Business Profile API oder einen Bewertungsaggregator. Die Bewertungen auf jeder Standortseite sollten aus dem GBP-Eintrag genau dieses Standorts stammen, nicht aus einem allgemeinen Feed der Zentrale.
Marken-Governance: Wie die Zentrale die Vorlage steuert, ohne Franchisenehmer auszubremsen
Das klarste Governance-Modell sperrt globalen Header, Footer, Typografie und Farbpalette auf Ebene des WordPress-Themes und gibt Franchisenehmern eine ACF-basierte Bearbeitungsoberfläche mit vordefinierten Feldgruppen. Franchisenehmer bearbeiten Inhalte, nicht die Struktur. Sie haben keinen Zugriff auf die vollständige Blockbibliothek des Gutenberg-Editors und können das Theme nicht verändern.
Das ist eine technische Entscheidung, keine Frage von Richtlinien. Markenwildwuchs lässt sich nicht mit einem Styleguide als PDF lösen. Sie lösen ihn, indem Sie ein CMS bauen, in dem die falsche Wahl gar nicht verfügbar ist.
Rollen und Berechtigungen in WordPress ermöglichen eine feingranulare Steuerung. Eine Redakteursrolle für Franchisenehmer lässt sich so konfigurieren, dass sie nur auf bestimmte Beitragstypen (ihre Standortseite) und nur auf bestimmte ACF-Feldgruppen zugreift und keinen Zugriff auf Theme-Anpassungen, Plugin-Einstellungen oder Inhalte anderer Standorte hat. Mit dem WordPress-Filter map_meta_cap lässt sich das beliebig verfeinern, falls die Standardrollen nicht ausreichen.
Die Synchronisierung von Marken-Assets über alle Standorte erfolgt auf Theme-Ebene. Farb-Tokens, Typografie-Definitionen und Logodateien liegen in der Theme-Konfiguration, nicht in den Einstellungen einzelner Standortseiten. Wenn die Zentrale die primäre Markenfarbe ändert, ändert sie sich überall gleichzeitig. Franchisenehmer bekommen kein Feld, um sie zu überschreiben.
Verstößt ein Franchisenehmer doch gegen die Markenstandards – lädt ein unpassendes Foto hoch oder überschreibt eine Überschrift mit Werbesprache, die der Kommunikation der Zentrale widerspricht –, kommt es auf den Wiederherstellungsprozess an. Das Revisionssystem von WordPress deckt Beitragsinhalte ab; für ACF-Felder hat ACF 6.8.1 einen Datenspeicher eingeführt, der Feldwerte mit den WordPress-Revisionen verknüpft, sodass Redakteure frühere Feldwerte über den nativen Revisionen-Bildschirm einsehen und wiederherstellen können. Für eine detaillierte Protokollierung, wer was getan hat, ergänzen Sie ein eigenes Aktivitätsprotokoll-Plugin. Erkennen Sie den Verstoß, stellen Sie die zuletzt freigegebene Version wieder her und teilen Sie dem Franchisenehmer mit, wie der korrekte Inhalt lauten sollte.
Bei Projekten, in denen die Designebene neben der technischen Architektur volle Aufmerksamkeit braucht, umfasst unsere Arbeit im Bereich UI/UX-Design für WordPress sowohl die Definition des Designsystems als auch die Umsetzung von Figma nach WordPress für Franchise-Kunden.
Für Franchise-Gruppen, die diese Infrastruktur nicht von Grund auf entwickeln möchten, bietet die IMADO Location Engine eine produktionsreife WordPress-Architektur für Websites mit mehreren Standorten. Sie bündelt Standortdaten wie Öffnungszeiten, Preise, Veranstaltungen, Aktionen und Buchungsinformationen zentral und gibt jedem Standort kontrollierten Zugriff auf seine eigenen Inhalte. Neue Standorte starten nach einem bewährten Muster, bei dem lokale Seiten, strukturierte Daten, Navigation, Berechtigungen und Integrationen bereits in die Plattform eingebaut sind – so kann ein Netzwerk wachsen, ohne für jeden neuen Standort dieselben Funktionen neu zu bauen.
Lokales SEO umsetzen: Schema, GBP und interne Verlinkung
Jede Standortseite braucht ein LocalBusiness-Schema mit korrekter Adresse, Öffnungszeiten, Telefonnummer und Geokoordinaten. Strukturierte Daten vom Typ LocalBusiness liefern Google eindeutige, maschinenlesbare Informationen zu jedem physischen Standort und können geeignete lokale Suchfunktionen unterstützen. Auf Franchise-Websites werden sie durchweg zu wenig umgesetzt.
Das Schema sollte als JSON-LD umgesetzt und in den <head> jeder Standortseite eingefügt werden. WordPress fügt standardmäßig kein LocalBusiness-Schema hinzu – RankMath und Yoast SEO unterstützen es über ihre Local-SEO-Module, oder Sie setzen es über ein eigenes Plugin um, das die Felddaten der Standortseite ausliest. @type sollte auf den spezifischsten passenden Untertyp gesetzt werden: LocalBusiness, FoodEstablishment, AutoRepair, LegalService usw. Spezifischere Typen verbessern die Erkennung der Entität.
Jede Standortseite sollte einen selbstreferenzierenden Canonical-Tag tragen, der auf ihre eigene URL zeigt – gängige Praxis, um Duplicate-Content-Probleme zu vermeiden, falls die Seite einmal über mehrere Pfade erreichbar ist. Unabhängig davon setzen Sie im Google-Unternehmensprofil jedes Standorts das Feld Website auf die URL der passenden Standortseite. So verknüpft Google den GBP-Eintrag mit Ihrer Website, nicht über den Canonical-Tag. Googles Dokumentation zu strukturierten Daten für LocalBusiness beschreibt die erforderlichen und empfohlenen Eigenschaften. Googles dokumentierte lokale Rankingfaktoren sind weiterhin Relevanz, Entfernung und Bekanntheit – das LocalBusiness-Schema ist kein direkter Rankingvorteil, liefert Google aber strukturierte Informationen und kann die Eignung für lokale Suchfunktionen verbessern.
Interne Links von der Root-Domain zu den Standortseiten geben Autorität in der Hierarchie nach unten weiter. Die Übersichtsseite der Standorte (domain.com/locations/) sollte auf jede einzelne Standortseite verlinken. Kategorieseiten (domain.com/locations/new-york/) sollten auf Unterseiten auf Stadtebene verlinken, wenn Ihr Netzwerk groß genug ist, um diese Tiefe zu rechtfertigen. Die Hauptnavigation der Root-Domain sollte einen Link „Standort finden“ enthalten, der zur Standortübersicht führt. Das ist eine Grundlage, fehlt aber auf erstaunlich vielen Franchise-Websites.
Keyword-Kannibalisierung zwischen Standortseiten ist ein echtes Risiko. Wenn Sie auf der Chicago-Seite auf „Sanitärdienst Chicago“ optimieren und ein Blogbeitrag dieselbe Phrase anvisiert, konkurrieren beide. Die Lösung ist eine klare Aufteilung: Standortseiten besetzen lokale transaktionale Keywords, Blog-Inhalte informationale Keywords. Schreiben Sie keinen Blogbeitrag mit dem Titel „Die besten Sanitärdienste in Chicago“, wenn Sie eine Standortseite für Chicago haben.
Performance im großen Maßstab: CDN und Caching für mehr als 50 Standortseiten
WordPress bewältigt Tausende Standortbeiträge ohne Performance-Probleme, wenn die Abfragen sauber aufgebaut und indexiert sind. Die Performance-Herausforderung bei Franchise-Websites ist nicht die Zahl der Standorte – sondern die Komplexität der Abfragen und das Traffic-Volumen.
CDN-Caching und ein WordPress-Object-Cache (Redis oder Memcached) werden wichtig, wenn Sie Folgendes haben: viel Traffic auf einzelnen Standortseiten, aufwendige Geo- oder Umkreisabfragen in einer Standortsuche, Aufrufe externer APIs pro Standort (Bewertungs-Feeds, Bestand, Verfügbarkeit) oder dynamische Inhalte, die vom Standort des Nutzers abhängen. Googles Untersuchung zur mobilen Ladegeschwindigkeit ergab, dass 53 % der mobilen Nutzer Websites verlassen, die länger als 3 Sekunden laden – Standortseiten mit nicht optimierten Karten und Bewertungs-Widgets sind oft die langsamsten Seiten einer Franchise-Website. Ergänzen Sie diese Caching-Ebenen, wenn die Last sie rechtfertigt.
Vollständiges Page Caching für Standortseiten wird durch dynamische Inhalte erschwert. Seiten mit Echtzeit-Bewertungen, aktuellen Öffnungszeiten oder Live-Bestand lassen sich am Edge nicht vollständig cachen, ohne zu veralten. Der richtige Ansatz ist, das statische Gerüst jeder Standortseite im CDN zu cachen und dynamische Inhalte (Bewertungen, Öffnungszeiten) nach dem ersten Rendern per JavaScript nachzuladen. So bleibt der Largest Contentful Paint schnell, und die Inhalte sind dort aktuell, wo es darauf ankommt.
Unser Service zur WordPress-Geschwindigkeitsoptimierung kümmert sich genau um diese Ebene: CDN-Konfiguration, Redis-Object-Caching, Abfrageoptimierung für WordPress-Websites mit vielen Standorten und Messung der Core Web Vitals pro Standort statt nur auf der Startseite.
Zielwerte der Core Web Vitals für Standortseiten: LCP unter 2,5 Sekunden, CLS unter 0,1, INP unter 200 Millisekunden. Eingebettete Karten sind auf Standortseiten die häufigste Ursache für LCP- und CLS-Probleme. Laden Sie sie per Lazy Loading. Liefern Sie Standortfotos im WebP-Format mit expliziten Abmessungen aus, um Layoutverschiebungen zu vermeiden.
Überwachen Sie die Performance pro Standort, nicht nur auf der Startseite. Ein Franchise-System mit 40 Standortseiten, von denen drei die Core Web Vitals dauerhaft verfehlen, hat ein Problem, das Sie beim Blick auf die Startseite nicht finden. Nutzen Sie den Core-Web-Vitals-Bericht in der Google Search Console, gefiltert nach URL-Muster, oder richten Sie regelmäßige Lighthouse-Tests für eine Stichprobe von Standortseiten ein.
Analytics-Tracking pro Standort in GA4
Google Analytics 4 unterstützt die Segmentierung nach Standort über benutzerdefinierte Dimensionen. Dazu wird jede Standortseite in der GA4-Konfiguration mit einem Parameter location_id versehen; anschließend erstellen Sie Explorative Datenanalysen, die Traffic, Interaktionsrate und Conversion-Ereignisse nach Standort aufschlüsseln.
Legen Sie in GA4 eine benutzerdefinierte Dimension namens location_id mit dem Bereich „Ereignis“ an. Übergeben Sie den Parameter über die gtag-Konfiguration oder über den Google Tag Manager mit einer Variablen, die die Standortkennung aus der Seiten-URL oder aus einem Data-Layer-Push ausliest. Sobald die Dimension befüllt ist, können Sie jeden Standardbericht in GA4 nach Standort segmentieren.
Das Zieltracking pro Standort sollte mindestens Folgendes abdecken: Formularübermittlungen (Kontakt- oder Angebotsanfragen), Klicks auf die Telefonnummer und Klicks auf „Route berechnen“ in der eingebetteten Google-Karte. Jedes davon sollte in GA4 als Conversion-Ereignis mit der Dimension location_id erfasst werden. So sieht die Zentrale klar, welche Standorte konvertieren und welche Aufmerksamkeit brauchen.
Richten Sie in der Search Console eine GSC-Property für die Root-Domain ein und segmentieren Sie über den Seitenfilter im Leistungsbericht nach dem URL-Muster der Standorte (/locations/). Separate GSC-Properties pro Standort brauchen Sie nur, wenn Sie eigene Domains verwenden. Die Property der Root-Domain erfasst die Daten aller Unterverzeichnisse automatisch.
FAQ: Häufige Fragen
Sollte ein Franchise-Unternehmen WordPress Multisite oder separate Installationen pro Standort nutzen?
Die Entscheidung hängt davon ab, wie stark die Standorte operativ getrennt sein müssen, nicht von ihrer Anzahl. Eine einzelne Installation genügt für die meisten Franchise-Netzwerke, auch für große. Multisite ist sinnvoll, wenn Standorte eigene Administratoren oder unabhängige Plugin-Konfigurationen brauchen oder wenn Sie mehrere eigenständige Franchise-Marken auf einer WordPress-Engine betreiben. Als grober Ausgangspunkt prüfen wir Multisite meist ab etwa 20 Standorten – die Anzahl der Standorte allein sollte die Entscheidung aber nicht bestimmen.
Welche URL-Struktur ist für eine Franchise-Website am besten?
Unterverzeichnisse sind die Standardempfehlung für Franchise-Websites. Die Struktur domain.com/locations/stadtname/ bündelt die Domain-Autorität unter einer Root-Domain, lässt sich von der Zentrale leichter steuern und vermeidet die Zersplitterung des SEO-Werts, die Subdomains verursachen.
Wie sichern Franchise-Websites eine einheitliche Marke über alle Standorte hinweg?
Markenkonsistenz wird auf CMS-Ebene durchgesetzt, nicht über Richtliniendokumente. Sperren Sie globale Designelemente (Header, Footer, Schriften, Farben) im WordPress-Theme und geben Sie Franchisenehmern nur Zugriff auf vordefinierte ACF-Feldgruppen für die Inhalte ihrer Standortseite. So sind regelwidrige Änderungen technisch gar nicht möglich, statt nur unerwünscht.
Welches Schema-Markup sollte eine Franchise-Website für jeden Standort verwenden?
Verwenden Sie das LocalBusiness-Schema (oder den spezifischsten passenden Untertyp) als JSON-LD im <head> jeder Standortseite. Geben Sie Adresse, Telefonnummer, Öffnungszeiten, Geokoordinaten und die URL der Standortseite selbst an (z. B. example.com/locations/chicago/). Die Eigenschaft url im LocalBusiness-Schema sollte auf die Webseite verweisen, nicht auf die URL des Eintrags in Google Maps oder im GBP.
Wie verhindern Sie, dass Standortseiten als Duplicate Content eingestuft werden?
Jede Standortseite braucht mindestens fünf eindeutige inhaltliche Signale: eine standortspezifische Überschrift, eine Beschreibung der lokalen Leistungen, NAP-Daten, eine eingebettete Google-Karte für diese Adresse und Bewertungen aus dem GBP-Eintrag dieses Standorts. Dünne Seiten, die in einer gemeinsamen Vorlage nur den Städtenamen austauschen, riskieren eine Abwertung durch Google als Brückenseiten (Doorway Pages).
Fazit
Website-Design für Franchise-Unternehmen mit mehreren Standorten ist in erster Linie eine Architektur- und keine Designentscheidung. Legen Sie zuerst die richtige URL-Struktur fest (Unterverzeichnisse), wählen Sie dann je nach Zahl der Standorte und danach, wer die Inhalte steuert, zwischen einzelner Installation und Multisite, und bauen Sie anschließend Standortseiten, die wirklich einzigartig sind, statt nur den Städtenamen auszutauschen. Marken-Governance, lokales SEO und Performance im großen Maßstab ergeben sich aus diesen grundlegenden Entscheidungen.
Die WordPress-Entwicklungsleistungen von IMADO decken dieses gesamte Spektrum ab: Architekturplanung, Multisite-Einrichtung, ACF-basierte Redaktionsoberflächen, Umsetzung des LocalBusiness-Schemas, CDN-Konfiguration und GA4-Tracking pro Standort. Wir bauen Franchise-Plattformen für Netzwerke mit 5 bis über 100 Standorten.
Sprechen Sie mit unseren WordPress-Entwicklern für Franchise-Systeme, um den Umfang Ihres Projekts zu klären.
