Lokale SEO, die Conversions bringt: vorab erzeugte Stadtseiten, JSON-LD und Search-Console-Abläufe

Das Problem, das wir gelöst haben

AAA Midea bedient die gesamte Slowakei. Das Unternehmen brauchte Seiten für die Städte, die es tatsächlich anspricht, eine klare Struktur für Suchmaschinen und ein CMS, das das Team ohne Hilfe eines Entwicklers nutzen kann. Inhaltlich dünne oder doppelte Seiten bringen keine Conversions. Große Überarbeitungen kommen ins Stocken, wenn die Redaktion nicht mithalten kann. Unser Ziel war, den Ortsbezug für Nutzer hilfreich und für Suchmaschinen glaubwürdig zu machen.

Unser Ansatz in drei Teilen

1. Ein typisiertes Ortsmodell, das programmatisch erzeugte Seiten ermöglicht, ohne Brückenseiten zu schaffen.
2. Strukturierte Daten (JSON-LD), die den sichtbaren Inhalten entsprechen und konsistente Signale liefern.
3. Ein wöchentlicher Ablauf in Search Console, der Probleme früh erkennt und Verbesserungen lenkt.

1) Ein typisiertes Ortsmodell, mit dem die Redaktion arbeiten kann

Wir haben slowakische Städtenamen gemeinsam mit ihren Formen für „in“, Slugs und Anzeigetexten modelliert. So lesen sich Inhalte natürlich und URLs bleiben vorhersehbar.

type CityEntry = {
  name: string // "Bratislava"
  in: string // "v Bratislave" for headings and leads
  slugCity: string // "bratislava"
  slugIn: string // "v-bratislave"
}

• Eine kanonische Menge von Stadt-Slugs steuert generateStaticParams und die Sitemap.
• Eine Hilfsfunktion ordnet jedem Slug den passenden Anzeigetext zu und verhindert damit Textfehler.
• Wir lassen nur Städte indexieren, die wir tatsächlich bedienen. Eine landesweite Seite deckt den Rest ab.

2) Programmatisch erzeugte Seiten mit Substanz

Jede Stadtseite folgt derselben Vorlage, ist aber nie eine leere Kopie. Wir kombinieren wiederverwendbare Komponenten mit Belegen und Medien:

• Leistungen, die in dieser Stadt angeboten werden, mit klaren Handlungsaufforderungen
• Aktuelle Projekte oder Fallstudien als Belege
• Einheitliche Überschriften mit der passenden Form für „in“
• Optimierte und zutreffend beschriebene Bildvarianten

Das CMS verlangt einen Einleitungstext, mindestens einen Beleg und Alternativtexte für Bilder. Entwürfe erscheinen weder in der Sitemap noch in der Navigation, solange sie die Qualitätsprüfungen nicht bestehen.

3) JSON-LD, auf das Suchmaschinen sich verlassen können

Wir binden typisiertes JSON-LD mit einer kleinen, durch DTS-Typdefinitionen abgesicherten Hilfsfunktion ein, damit die Eigenschaften gültig bleiben:

• Service oder branchenspezifische Untertypen für das Angebot
• BreadcrumbList, die den tatsächlichen Links entspricht
• Angaben zu LocalBusiness, wo passend, und areaServed für die Stadt
• Stabile url- und Canonical-Regeln, die die Route abbilden

Da JSON-LD aus demselben Datenmodell wie die Seite erzeugt wird, weichen die sichtbaren Inhalte und die von Crawlern gelesenen Daten nicht voneinander ab.

Die Umsetzung in Next.js

// generate valid routes only
export function generateStaticParams() {
  return ALL_CITY_SLUGS.map((city) => ({ city }))
}

// consistent, city-aware metadata
export async function generateMetadata({ params }) {
  const { city } = await params
  const entry = getCityBySlug(city) ?? DEFAULT_LOCATION
  return constructServiceLocationMetadata({
    service: 'Klimatizácia, rekuperácia a tepelné čerpadlá',
    city: entry.name,
    canonicalPath: `/lokality/${city}`,
  })
}

Und innerhalb der Seite:

<JsonLd id="jsonld-breadcrumbs" data={withContext(breadcrumbJsonLd([...]))} />
<JsonLd id="jsonld-service" data={withContext(serviceJsonLd({
  serviceName: 'Montáž a servis klimatizácie',
  url: pageUrl,
  providerName: 'AAA Midea',
  areaServed: [entry.name],
}))} />

Sitemaps, die den tatsächlichen Stand abbilden

Wir erzeugen eine Grundmenge von Routen und ergänzen ausschließlich die kanonischen Stadt-Slugs. Die Aktualisierung erfolgt nach Zeitplan. So bleibt der Index übersichtlich und vorhersehbar.

export const revalidate = 3600 // sitemap freshness
const localitySlugs = new Set([
  ...ALL_CANONICAL_CITY_SLUGS,
  DEFAULT_LOCATION.slugCity,
])

Die Seiten übernehmen eine monatliche Änderungsfrequenz. Die landesweite Seite kann eine etwas höhere Priorität als einzelne Stadtseiten erhalten, um Crawler sinnvoll zu lenken.

Search Console als wöchentliche Routine

Wir verwenden eine Domain-Property in Search Console und prüfen jede Woche vier Bereiche:

• Abdeckung: unerwartete Ausschlüsse, Soft-404s und Canonical-Konflikte finden
• Verbesserungen: Schema-Warnungen für Service, Breadcrumb oder LocalBusiness prüfen
• Links: sicherstellen, dass die interne Verlinkung auf die richtigen Städte hinweist
• Leistung: Suchanfragen pro Stadtseite, Klickrate bei ortsbezogenen Suchbegriffen und Verteilung nach Gerät untersuchen

Wenn Probleme auftreten, korrigieren wir zuerst die maßgebliche Quelle, also das Ortsmodell oder die Vorlage. Anschließend beantragen wir die Validierung. Redakteure sehen ein einfaches Dashboard im CMS. Verantwortliche können bei Bedarf weiterhin direkt in GSC auf die Detaildaten zugreifen.

Regeln gegen Brückenseiten

• Nur Städte indexieren, die wir tatsächlich bedienen können
• Eigene Einleitungstexte und Belege für jede Stadt, keine Wände aus austauschbaren Standardtexten
• Strenge Canonical-Regeln zwischen Leistungsseiten und Stadtseiten
• Keine Entwürfe in der Sitemap

Diese Regeln erhalten den Nutzen für Besucher und helfen der Website, die Anforderungen der Suche einzuhalten.

Core Web Vitals und Medien

Stadtseiten laden schnell, weil die aufwendige Verarbeitung im Voraus erfolgt. Wir skalieren Bilder beim Hochladen, liefern responsive Varianten aus und cachen nah an den Nutzern. Videos setzen wir sparsam ein und nur dort, wo sie etwas belegen. Gemessen an unseren Leistungsbudgets sehen wir stabile CWV-Werte und schnelle Reaktionen auf die erste Eingabe.

A/B-Tests und Feature Flags

Verantwortliche können Varianten von Überschriften, Belegblöcken und Handlungsaufforderungen ohne Deployment umschalten. Damit testen wir Änderungen sicher und planen Einführungen. Die technische Umsetzung beschreiben wir ausführlicher in Von Wix zur eigenen Lösung ohne Ausfallzeit: parallele Migration mit Feature Flags.

Die bisherigen Ergebnisse

Wenige Wochen nach dem Start des neuen Ortssystems verbesserten sich die durchschnittlichen Positionen für priorisierte Suchanfragen von etwa Rang 60 auf die Top 15. Der Prozess ist noch jung. Wir erwarten weitere Fortschritte, wenn mehr Belege hinzukommen und die interne Verlinkung ausgebaut wird.

Checkliste zum Übernehmen

• Eine typisierte, maßgebliche Datenquelle für Städte und ihre Formen für „in“
• Programmatisch erzeugte Seiten mit verpflichtenden Belegen und Medien
• JSON-LD aus denselben Daten wie die Seite
• Saubere Sitemaps und vorhersehbare Canonicals
• Ein wöchentlicher Search-Console-Ablauf mit klaren Zuständigkeiten
• Flags für A/B-Tests und sichere Einführungen