Strukturierte Daten für Dienstleister in Südtirol

Strukturierte Daten für Dienstleister bilden zwei verbundene Ebenen ab: LocalBusiness beziehungsweise einen passenden Untertyp für Deinen Betrieb und Service für jede konkrete Leistung. JSON-LD verknüpft Betrieb, Leistungen, Standort und Einsatzgebiet, damit Suchmaschinen und andere Systeme die Zusammenhänge maschinell zuordnen können.

In meiner Arbeit mit Südtiroler KMU begegnen mir häufig zwei Situationen: Entweder fehlen strukturierte Daten vollständig oder mehrere Werkzeuge erzeugen widersprüchliche Schema-Blöcke. Entscheidend ist nicht die Menge des Markups, sondern eine klare Architektur mit richtigen, sichtbaren und dauerhaft gepflegten Angaben.

Der Betrieb ist die zentrale Entität. Leistungen, Standorte, Sprachen und Einsatzgebiete werden eindeutig mit diesem Betrieb verbunden.

Strukturierte Daten für Dienstleister: Was Du auszeichnest

Strukturierte Daten sind zusätzliche maschinenlesbare Angaben im Quellcode einer Website. Das gemeinsame Vokabular dafür liefert Schema.org. Google unterstützt JSON-LD, Microdata und RDFa, empfiehlt für die meisten Umsetzungen jedoch JSON-LD, weil sich das Format vergleichsweise gut implementieren und pflegen lässt. Maßgeblich bleibt die Dokumentation der jeweiligen Suchfunktion bei Google Search Central.

Für einen lokalen Betrieb sind typischerweise folgende Ebenen relevant:

• Betrieb: Name, Website, Telefonnummer, Adresse, Koordinaten, Öffnungszeiten und offizielle Profile.
• Leistungen: eindeutig benannte Angebote mit eigener URL, Anbieter und Einsatzgebiet.
• Standort: eine reale Niederlassung mit einer tatsächlich nutzbaren Adresse.
• Einsatzgebiet: Orte oder Regionen, in denen der Betrieb seine Leistungen erbringt.
• Sprachen: Sprachen, in denen Interessierte beraten oder betreut werden.

Schema.org definiert LocalBusiness zugleich als Untertyp von Organization und Place. Der Typ beschreibt einen konkreten lokalen Betrieb oder eine Niederlassung. Für viele Branchen stellt Schema.org spezifischere Untertypen bereit.

Schritt 1: Datenkonsistenz herstellen

Bevor Du JSON-LD erstellst, brauchst Du verlässliche Stammdaten. Prüfe Firmenname, Anschrift, Telefonnummer, Öffnungszeiten und Leistungsbezeichnungen auf der Website, im Google-Unternehmensprofil und in weiteren offiziellen Profilen.

Ein Beispiel: Auf der Website steht „Elektro Hofer“, im Google-Unternehmensprofil „Elektrotechnik Hofer GmbH“ und auf einem Branchenportal „Hofer Elektroservice“. Ein Mensch erkennt wahrscheinlich den Zusammenhang. Ein maschinelles System muss dagegen erst ermitteln, ob es sich um einen oder mehrere Betriebe handelt.

Lege deshalb eine verbindliche Schreibweise fest und dokumentiere mindestens:

• den offiziellen und öffentlich verwendeten Firmennamen,
• die vollständige Anschrift einschließlich Postleitzahl und Provinz,
• die Telefonnummer im internationalen Format,
• die Hauptdomain und kanonische Standort-URL,
• reguläre und abweichende Öffnungszeiten,
• deutsche und italienische Leistungsbezeichnungen,
• reale Niederlassungen und tatsächliche Einsatzgebiete,
• offizielle Profile für sameAs.

Gerade für Handwerksbetriebe ist ein gepflegtes Google-Unternehmensprofil mit konsistenten Betriebsdaten ein wichtiger Teil dieser Grundlage. JSON-LD soll widersprüchliche Angaben nicht überdecken, sondern dieselben verlässlichen Fakten maschinenlesbar ausdrücken.

Schritt 2: Den passenden LocalBusiness-Untertyp wählen

Verwende nicht automatisch für jeden Betrieb nur LocalBusiness. Wähle den spezifischsten Schema.org-Typ, der den tatsächlichen Betrieb korrekt beschreibt.

• ProfessionalService: kann für lokal tätige professionelle Dienstleister passen, sofern kein genauerer Untertyp vorhanden ist.
• HomeAndConstructionBusiness: ist der übergeordnete Bereich für viele Bau- und Handwerksleistungen.
• Electrician: passt zu einem Elektrikerbetrieb.
• Plumber: passt zu einem Installateurbetrieb.
• RoofingContractor: beschreibt einen Dachdeckerbetrieb.
• GeneralContractor: eignet sich für einen entsprechenden Bau- oder Generalunternehmer.

Ein Elektriker kann als Electrician ausgezeichnet werden, statt nur den allgemeineren Typ HomeAndConstructionBusiness zu verwenden. Gibt es keinen fachlich passenden Untertyp, bleibt LocalBusiness eine sachliche Lösung.

Der gewählte Typ muss zum sichtbaren Inhalt passen. Nach den Google-Richtlinien müssen strukturierte Daten den Inhalt der Seite wahrheitsgemäß wiedergeben. Unsichtbare, irrelevante oder irreführende Angaben können die Eignung für Suchfunktionen beeinträchtigen.

Schritt 3: Betrieb und Leistungen über eindeutige IDs verbinden

Jede zentrale Entität erhält eine stabile @id. Für den Betrieb kann das beispielsweise die Website-Adresse mit einem Fragment sein:

https://www.example.org/#betrieb

Jede Leistung erhält ebenfalls eine eigene ID:

https://www.example.org/leistungen/elektroinstallation/#service

Die Eigenschaft provider der Leistung verweist anschließend auf die @id des Betriebs. Damit ist eindeutig definiert, welcher Betrieb die Leistung anbietet.

Diese Verknüpfung ist der Kern eines sauberen Service-Schemas für KMU. Wie einzelne Leistungsseiten inhaltlich und technisch aufgebaut werden, erkläre ich im Beitrag über Service Schema für konkrete Leistungsseiten.

Schritt 4: JSON-LD-Beispiel für einen Südtiroler Betrieb

Das folgende Beispiel beschreibt einen fiktiven Elektrikerbetrieb in Bozen. Domain, Telefonnummer, Adresse, Koordinaten, Profile und Leistungsseiten sind Beispieldaten. Ersetze alle Werte durch die tatsächlichen Angaben Deines Betriebs.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Electrician",
      "@id": "https://www.example.org/#betrieb",
      "name": "Muster Elektrotechnik Südtirol",
      "url": "https://www.example.org/",
      "telephone": "+39 0471 000000",
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "Musterweg 1",
        "postalCode": "39100",
        "addressLocality": "Bozen",
        "addressRegion": "Südtirol",
        "addressCountry": "IT"
      },
      "geo": {
        "@type": "GeoCoordinates",
        "latitude": 46.4983,
        "longitude": 11.3548
      },
      "openingHoursSpecification": [
        {
          "@type": "OpeningHoursSpecification",
          "dayOfWeek": [
            "https://schema.org/Monday",
            "https://schema.org/Tuesday",
            "https://schema.org/Wednesday",
            "https://schema.org/Thursday",
            "https://schema.org/Friday"
          ],
          "opens": "08:00",
          "closes": "17:30"
        }
      ],
      "areaServed": [
        {
          "@type": "City",
          "name": "Bozen"
        },
        {
          "@type": "City",
          "name": "Meran"
        },
        {
          "@type": "City",
          "name": "Brixen"
        },
        {
          "@type": "AdministrativeArea",
          "name": "Südtirol"
        }
      ],
      "contactPoint": {
        "@type": "ContactPoint",
        "telephone": "+39 0471 000000",
        "contactType": "customer service",
        "availableLanguage": [
          "de",
          "it"
        ]
      },
      "sameAs": [
        "https://example.com/muster-elektrotechnik",
        "https://example.net/muster-elektrotechnik"
      ],
      "hasOfferCatalog": {
        "@type": "OfferCatalog",
        "name": "Elektrotechnische Leistungen",
        "itemListElement": [
          {
            "@type": "Offer",
            "itemOffered": {
              "@id": "https://www.example.org/leistungen/elektroinstallation/#service"
            }
          },
          {
            "@type": "Offer",
            "itemOffered": {
              "@id": "https://www.example.org/leistungen/wallbox-installation/#service"
            }
          }
        ]
      }
    },
    {
      "@type": "Service",
      "@id": "https://www.example.org/leistungen/elektroinstallation/#service",
      "name": "Elektroinstallation für Wohngebäude",
      "serviceType": "Planung und Ausführung von Elektroinstallationen",
      "url": "https://www.example.org/leistungen/elektroinstallation/",
      "provider": {
        "@id": "https://www.example.org/#betrieb"
      },
      "areaServed": {
        "@type": "AdministrativeArea",
        "name": "Südtirol"
      },
      "offers": {
        "@type": "Offer",
        "url": "https://www.example.org/leistungen/elektroinstallation/"
      }
    },
    {
      "@type": "Service",
      "@id": "https://www.example.org/leistungen/wallbox-installation/#service",
      "name": "Installation von Wallboxen",
      "serviceType": "Montage und Inbetriebnahme von Wallboxen",
      "url": "https://www.example.org/leistungen/wallbox-installation/",
      "provider": {
        "@id": "https://www.example.org/#betrieb"
      },
      "areaServed": [
        {
          "@type": "City",
          "name": "Bozen"
        },
        {
          "@type": "City",
          "name": "Meran"
        }
      ],
      "offers": {
        "@type": "Offer",
        "url": "https://www.example.org/leistungen/wallbox-installation/"
      }
    }
  ]
}
</script>

Was die wichtigsten Eigenschaften bedeuten

name, url und telephone

name enthält die einheitlich verwendete Betriebsbezeichnung. url verweist auf die zentrale Website oder Standortseite. Die Telefonnummer sollte im internationalen Format angegeben werden, für Italien beispielsweise mit +39.

address und geo

address beschreibt eine reale Postanschrift. geo ergänzt die geografischen Koordinaten dieser Adresse. Verwende Koordinaten nicht für den Mittelpunkt eines Einsatzgebiets, wenn der Betrieb dort keine Niederlassung besitzt.

openingHoursSpecification

openingHoursSpecification bildet reguläre Öffnungs- oder Erreichbarkeitszeiten strukturiert ab. Die Zeiten müssen mit den sichtbaren Website-Angaben und dem Google-Unternehmensprofil übereinstimmen.

areaServed

areaServed bezeichnet das Gebiet, in dem eine Leistung angeboten wird. Beim Schema.org-Typ Service bezeichnen provider den Anbieter, areaServed das bediente Gebiet, serviceType die Art der Dienstleistung und offers das zugehörige Angebot.

Für einen Südtiroler Handwerksbetrieb können Bozen, Meran und Brixen einzeln genannt werden. Ist der Betrieb tatsächlich landesweit tätig, kann zusätzlich Südtirol als AdministrativeArea angegeben werden. Eine lange Liste von Orten ersetzt kein reales Leistungsgebiet.

availableLanguage

availableLanguage beschreibt im Beispiel die Sprachen des Kontaktpunkts. Bei vielen Südtiroler Betrieben sind das Deutsch und Italienisch. Die Eigenschaft bedeutet nicht automatisch, dass jede Seite der Website in beiden Sprachen verfügbar ist.

sameAs

sameAs verbindet den Betrieb mit verlässlichen offiziellen Profilen. Dazu können ein eindeutig zuordenbares Google-Unternehmensprofil oder ein gepflegtes LinkedIn-Unternehmensprofil gehören. Verwende keine beliebigen Verzeichniseinträge und keine Profile, die Du nicht kontrollierst. Eine ausführliche Einordnung findest Du in meinem Leitfaden zu sameAs und offiziellen Unternehmensprofilen.

hasOfferCatalog

hasOfferCatalog bündelt das Leistungsangebot des Betriebs. Ein Angebotskatalog ist sinnvoll, wenn mehrere klar definierte Leistungen vorhanden sind. Jede Leistung sollte über itemOffered auf eine konkrete Service-Entität verweisen.

Leistungen nicht als Keyword-Liste modellieren

Eine ungeeignete Modellierung sieht sinngemäß so aus: „Elektriker, Elektro, Installation, Notdienst, Wallbox, Smart Home, Südtirol, Bozen, Meran“. Eine solche Ansammlung erklärt weder die Leistung noch deren Umfang.

Eine klar modellierte Leistung beantwortet fünf Fragen:

• Was wird angeboten? Zum Beispiel „Installation von Wallboxen“.
• Wer bietet die Leistung an? Das beantwortet provider.
• Wo wird die Leistung angeboten? Das beschreibt areaServed.
• Wo wird die Leistung sichtbar erklärt? Darauf verweist url.
• Gibt es ein konkretes Angebot? Das kann über offers beschrieben werden.

Die Leistungsseite muss die ausgezeichnete Leistung nachvollziehbar erklären. Dazu gehören je nach Angebot Ablauf, Voraussetzungen, Zielgruppe, Einsatzgebiet und Kontaktmöglichkeit. Leistungen nur im JSON-LD anzulegen, obwohl sie auf der Seite nicht sichtbar sind, widerspricht den Google-Richtlinien.

Drei Standortmodelle für LocalBusiness Schema in Südtirol

1. Betrieb mit einem Standort und regionalem Einsatzgebiet

Ein Beratungsunternehmen hat ein Büro in Bozen und betreut Unternehmen in ganz Südtirol. Der reale Standort wird über address und geo beschrieben, das größere Tätigkeitsgebiet über areaServed.

2. Mobiler Handwerksbetrieb

Ein mobiler Installateur fährt zu Auftraggebern in Bozen, Meran und Umgebung. Das Einsatzgebiet wird über areaServed modelliert. Ob die Betriebsadresse öffentlich dargestellt wird, hängt vom tatsächlichen Betriebsmodell und den Regeln des jeweiligen Dienstes ab.

Für GEO für Handwerker ist diese Unterscheidung wichtig: GEO im Sinn von Generative Engine Optimization betrifft die verständliche Aufbereitung von Inhalten. Die Schema.org-Eigenschaft geo beschreibt dagegen konkrete geografische Koordinaten.

3. Betrieb mit mehreren echten Niederlassungen

Hat ein Unternehmen reale Niederlassungen in Bozen und Brixen, benötigt jeder Standort eine eigene Entität, eine eigene Adresse und idealerweise eine eigene Standortseite. Eine gemeinsame Organisation kann als übergeordnete Entität modelliert werden.

Lege keine fiktiven Niederlassungen an, nur um in mehreren Orten gefunden zu werden. Ein Einsatzgebiet ist kein Standort. Eine Postadresse ohne tatsächlichen Geschäftsbetrieb wird durch JSON-LD nicht zu einer Niederlassung.

Mehrsprachige Websites in Südtirol sauber behandeln

Eine mehrsprachige Website braucht stabile Sprachversionen und konsistente Daten. Deutsche und italienische Seiten sollten redaktionell geprüfte Texte, dauerhafte URLs und übereinstimmende Unternehmensangaben besitzen.

• Nutze für jede Sprachversion eine dauerhafte URL.
• Halte Firmenname, Telefonnummer und Standortdaten sprachübergreifend konsistent.
• Übersetze Leistungsnamen fachlich korrekt statt ungeprüft automatisch.
• Verwende dieselbe Betriebs-@id, wenn beide Sprachversionen denselben Betrieb beschreiben.
• Verknüpfe jede Service-Entität mit der passenden sichtbaren Leistungsseite.
• Prüfe, ob Öffnungszeiten, Preise und Einsatzgebiete in allen Sprachversionen übereinstimmen.

availableLanguage beschreibt die angebotenen Kontakt- oder Servicesprachen. Die Sprache einer konkreten Webseite wird dagegen auf Seitenebene und durch die technische Spracharchitektur kenntlich gemacht. Eine deutsch-italienische Website sollte deshalb redaktionell und technisch als zusammenhängendes System gepflegt werden.

JSON-LD in WordPress implementieren

In WordPress gibt es drei übliche Wege:

1. Ein SEO-Werkzeug: geeignet für grundlegende Unternehmensdaten, sofern die erzeugte Struktur zum Betrieb passt.
2. Das Theme: möglich, wenn das Markup sauber entwickelt und bei Theme-Änderungen mitgepflegt wird.
3. Ein eigenes Plugin: sinnvoll für individuelle LocalBusiness- und Service-Architekturen mit mehreren Leistungen oder Standorten.

Bei komplexeren KMU-Websites bevorzuge ich eine kontrollierte Lösung, bei der Stammdaten zentral gepflegt und konsistent ausgegeben werden. Im Rahmen unserer Webdesign- und Entwicklungsleistungen prüfen wir zuerst, welche Entitäten und Datenquellen vorhanden sind, bevor wir das Markup programmieren.

Besondere Vorsicht gilt bei mehreren gleichzeitig aktiven Werkzeugen. Ein SEO-Werkzeug, ein Branchen-Plugin und das Theme können parallel eigene Organization-, LocalBusiness– oder Service-Blöcke erzeugen. Abweichende Namen, URLs oder IDs führen dann zu Widersprüchen.

Schritt 5: Strukturierte Daten validieren

Die Prüfung besteht aus mehreren Ebenen. Ein fehlerfreies Testergebnis bestätigt die technische Struktur, aber nicht automatisch die inhaltliche Richtigkeit.

1. JSON-Syntax prüfen: Sind Klammern, Kommas, Anführungszeichen und Datentypen korrekt?
2. Schema Markup Validator verwenden: Der Schema Markup Validator prüft allgemeines Schema.org-Markup und zeigt die verwendeten Typen und Eigenschaften.
3. Rich Results Test verwenden: Der Rich Results Test zeigt, ob Google eine unterstützte Suchdarstellung erkennt. Nicht jeder gültige Schema.org-Typ erzeugt ein Rich Result.
4. Gerenderten Quellcode prüfen: Kontrolliere, ob der JSON-LD-Block tatsächlich im ausgelieferten oder gerenderten HTML vorhanden ist.
5. Zielseiten öffnen: Jede in url, offers oder sameAs genannte Adresse muss erreichbar und inhaltlich passend sein.
6. Sichtbaren Inhalt vergleichen: Name, Leistungen, Preise, Öffnungszeiten, Sprachen und Einsatzgebiet müssen auf der Seite belegbar sein.
7. Doppelte Entitäten suchen: Prüfe, ob mehrere Plugins denselben Betrieb mit unterschiedlichen IDs ausgeben.

Ein typischer Fall aus meiner Praxis: Der Validator meldet keine Syntaxfehler, aber im JSON-LD stehen veraltete Öffnungszeiten. Der Block ist technisch gültig und inhaltlich falsch. Eine verlässliche Prüfung muss deshalb Technik und sichtbaren Seiteninhalt berücksichtigen.

Was strukturierte Daten leisten – und was nicht

Strukturierte Daten helfen Systemen, Unternehmen, Leistungen und Beziehungen eindeutiger zuzuordnen. Sie können eine Voraussetzung für bestimmte Suchdarstellungen sein und Mehrdeutigkeit reduzieren.

Korrektes Markup garantiert weder ein Rich Result noch eine bessere Platzierung. Auch die Aufnahme in Google AI Overviews, AI Mode oder die Antwort eines anderen KI-Assistenten ist nicht garantiert. Google erklärt, dass für seine KI-Funktionen kein spezielles Schema.org-Markup erforderlich ist. Selbst regelkonforme Seiten werden nicht automatisch indexiert oder ausgespielt.

JSON-LD verbessert die maschinelle Zuordnung. Sichtbarkeit hängt zusätzlich von belastbaren Inhalten, konsistenten Unternehmensdaten, technischer Qualität und klarer Positionierung ab.

90-Tage-Plan für Service Schema bei KMU

Tag 1 bis 30: Stammdaten und Prioritäten klären

• Firmenname, Adresse, Telefonnummer und Website-URL festlegen.
• Google-Unternehmensprofil und Website abgleichen.
• Reale Standorte und Einsatzgebiete trennen.
• Die drei bis fünf wichtigsten Leistungen auswählen.
• Für jede Leistung eine belastbare Zielseite bestimmen.

Tag 31 bis 60: Architektur und technische Ausgabe umsetzen

• Passenden LocalBusiness-Untertyp auswählen.
• Stabile @id für Betrieb und Services vergeben.
• provider, areaServed und URLs verknüpfen.
• JSON-LD in WordPress ausgeben.
• Doppelte Schema-Blöcke entfernen.

Tag 61 bis 90: Prüfen und Pflege verankern

• Schema Markup Validator und Rich Results Test durchführen.
• Sichtbare Inhalte mit dem Markup vergleichen.
• Deutsche und italienische Angaben kontrollieren.
• Fehler dokumentieren und beheben.
• Eine verantwortliche Person für Änderungen bestimmen.

Nach den ersten 90 Tagen beginnt die laufende Pflege. Neue Leistungen, geänderte Öffnungszeiten oder zusätzliche Standorte müssen auf der Website, im Markup und in relevanten Unternehmensprofilen gleichzeitig aktualisiert werden.

Häufige Fragen zu LocalBusiness und Service Schema

Was kostet die Umsetzung strukturierter Daten?

Die Kosten hängen von der vorhandenen Website, der Zahl der Leistungen und der Standortstruktur ab. Ein einzelner Betrieb mit wenigen Leistungen ist einfacher umzusetzen als eine mehrsprachige Website mit mehreren Niederlassungen und individuell erzeugtem JSON-LD.

Wie oft muss ich JSON-LD aktualisieren?

Aktualisiere das Markup immer dann, wenn sich sichtbare Unternehmensdaten, Öffnungszeiten, Leistungen, Preise, Sprachen oder Standorte ändern. Zusätzlich empfehle ich mindestens einmal pro Jahr eine vollständige Prüfung der Datenkonsistenz.

Kann ich LocalBusiness ohne öffentlich sichtbare Adresse verwenden?

Das hängt vom realen Geschäftsmodell und vom verwendeten Untertyp ab. Erfinde keine Anschrift und veröffentliche keine Adresse allein für Suchmaschinen. Beschreibe bei einem mobilen Dienstleister stattdessen das tatsächliche Einsatzgebiet und beachte die Anforderungen der jeweiligen Plattform.

Wie zeichne ich mehrere Standorte aus?

Jede echte Niederlassung sollte eine eigene LocalBusiness-Entität mit eigener @id, Adresse, URL und passenden Öffnungszeiten erhalten. Die Niederlassungen können mit einer übergeordneten Organisation verbunden werden, dürfen aber nicht aus reinen Einsatzorten konstruiert werden.

Muss ich Preise im Service-Schema angeben?

Nein, nicht jede Dienstleistung braucht einen öffentlich ausgezeichneten Preis. Wenn Du einen Preis oder eine Preisspanne angibst, muss die Information auf der verlinkten Seite sichtbar, aktuell und eindeutig derselben Leistung zugeordnet sein.

Braucht jede Sprache ein eigenes Service Schema?

Jede Sprachseite sollte maschinenlesbare Angaben erhalten, die zu ihrem sichtbaren Inhalt passen. Betrieb und Leistung können über stabile IDs als dieselben Entitäten erkennbar bleiben, während Namen, Beschreibungen und URLs zur jeweiligen Sprachversion passen.

Ersetzt JSON-LD das Google-Unternehmensprofil?

Nein, JSON-LD und Google-Unternehmensprofil erfüllen unterschiedliche Aufgaben. Das Markup beschreibt Deine Website maschinenlesbar, während das Unternehmensprofil separat für die Darstellung in Google Search und Google Maps gepflegt wird.

Garantieren strukturierte Daten mehr Sichtbarkeit?

Nein, korrektes Markup garantiert weder bessere Rankings noch Rich Results oder Nennungen durch KI-Assistenten. Strukturierte Daten verbessern vor allem die Eindeutigkeit Deiner Angaben und schaffen eine belastbare technische Grundlage.

Abschluss-Checkliste für Deinen Betrieb

Daten und Inhalte

• Der gewählte Schema.org-Typ passt zur tatsächlichen Branche.
• Firmenname, Adresse und Telefonnummer sind überall konsistent.
• Jede wichtige Leistung ist als Service beschrieben.
• areaServed beschreibt reale Einsatzgebiete.
• address und geo stehen nur für echte Standorte.
• availableLanguage nennt tatsächlich angebotene Sprachen.
• sameAs verweist nur auf offizielle und gepflegte Profile.

Technik und Pflege

• Der Betrieb besitzt eine stabile und eindeutige @id.
• Jeder Service verweist über provider auf den Betrieb.
• openingHoursSpecification entspricht den sichtbaren Öffnungszeiten.
• hasOfferCatalog enthält klar benannte, belegbare Leistungen.
• Die mehrsprachige Website verwendet konsistente Unternehmensdaten.
• Es gibt keine widersprüchlichen Schema-Blöcke aus mehreren Werkzeugen.
• Schema Markup Validator und Rich Results Test wurden ausgeführt.
• Änderungen an Leistungen und Standorten werden dauerhaft nachgeführt.

Nach über 20 Jahren in Branding, Webentwicklung und Digitalisierung ist meine zentrale Erfahrung: Verlässliche strukturierte Daten beginnen bei klar gepflegten Unternehmensdaten. Wenn Menschen auf Deiner Website schnell verstehen, wer Du bist, was Du anbietest und wo Du arbeitest, lassen sich dieselben Angaben auch nachvollziehbar in JSON-LD abbilden.

Quellen

1. Google Search Central — Introduction to structured data markup (2025)
2. Google Search Central — General Structured Data Guidelines (2026)
3. Schema.org — LocalBusiness (2026)
4. Schema.org — Service (2026)
5. Google Search Central — AI features and your website (2025)