Lokales SEO mit schema.org: LocalBusiness- und Person-Markup für Verzeichnisseiten

Christopher Zechendorf

16.06.2026

Share:

Wie wir Verzeichnis- und Profilseiten der Weinplattform VINUM mit schema.org-JSON-LD ausgezeichnet haben -- ohne Datenmodell-Umbau, allein aus vorhandenen Feldern.

Wenn Suchmaschinen Ihre Verzeichniseinträge wirklich verstehen

Verzeichnis- und Mitgliederseiten sind oft die wertvollsten, aber am schlechtesten auffindbaren Seiten einer Website: hunderte Detailprofile mit echten Daten – Namen, Adressen, Telefonnummern, Bildern – die für Suchmaschinen jedoch nur Fließtext sind. Genau hier setzen strukturierte Daten an. Auf der Weinplattform VINUM haben wir in einer Arbeitswoche mehrere Detailseiten mit schema.org-Markup ausgezeichnet: Winzer-Profile aus dem Weingüter-Kompass und Mitglieder des Wine Trade Clubs als LocalBusiness, Autorinnen und Autoren als Person. Das Besondere daran: Es war kein einziger Umbau am Datenmodell nötig.

Die Herausforderung

Strukturierte Daten – maschinenlesbare Auszeichnungen im Format JSON-LD – sind die Eintrittskarte für Rich Results und für die lokale Suche. Eine Suchmaschine, die erkennt, dass es sich bei einem Eintrag um ein konkretes Unternehmen mit Adresse und Telefonnummer handelt, kann diesen Eintrag deutlich prominenter und in passenderen Kontexten ausspielen als eine reine Textseite.

Der typische Reflex lautet: “Dann brauchen wir erst einmal ein neues Datenmodell mit allen Feldern, die schema.org vorsieht.” Das ist teuer, langwierig und meistens unnötig. Unsere Ausgangslage war eine andere:

• Es existierten bereits gepflegte Profilseiten mit Namen, Adressen, Bildern und Kontaktdaten.
• Ein Umbau der Datenstruktur (neue Felder, Datenbankmigrationen, Backend-Masken) sollte vermieden werden.
• Trotzdem sollte das Markup valide sein – also kein halbfertiges JSON-LD, das Suchmaschinen verwerfen.

Die Aufgabe war damit weniger eine Frage des Datenmodells als eine Frage der sauberen Umsetzung: Wie erzeugt man aus vorhandenen Feldern ein gültiges, robustes und wartbares Markup?

Unsere Lösung

1. Ein wiederverwendbares Service-Muster

Statt das Markup verstreut in den Templates zusammenzustückeln, kapselt jede Entität ihre Logik in einem eigenen kleinen Service mit genau einer Aufgabe: aus einem Objekt das fertige <script type="application/ld+json">-Tag erzeugen – oder einen leeren String, wenn keine sinnvollen Daten vorliegen.

final class VineyardProfileSchemaService
{
    public function buildJsonLd(VineyardProfile $profile, string $absoluteUrl): string
    {
        // … Felder einsammeln, leere verwerfen, kodieren …
    }
}

Der Controller ruft diesen Service auf der Detailseite auf und hängt das Ergebnis – falls nicht leer – in den Seitenkopf:

$jsonLd = $this->schemaService->buildJsonLd($profile, $absoluteUrl);
if ($jsonLd !== '') {
    $pageRenderer->addHeaderData($jsonLd);
}

Dieses Muster haben wir vom bereits bestehenden Event-Markup übernommen und für Winzer-Profile, Wine-Trade-Club-Mitglieder und Autoren jeweils 1:1 repliziert. Der Vorteil: Jeder Service ist klein, testbar und folgt derselben Struktur. Neue Entitäten lassen sich in Stunden statt Tagen ergänzen.

2. Minimal-gültige Objekte per “graceful omission”

Der Schlüssel zum Verzicht auf einen Datenmodell-Umbau liegt in einer einfachen Erkenntnis: Für ein LocalBusiness schreibt schema.org nur den Namen als Pflichtfeld vor. Alles andere – Telefon, Bild, Adresse, Öffnungszeiten – ist optional.

Wir bauen deshalb das Objekt aus genau den Feldern, die bereits vorhanden sind, und lassen leere Felder konsequent weg, statt Platzhalter oder neue Felder zu erzwingen. Technisch sorgt ein abschließender Filter dafür, dass keine leeren oder null-Werte im Ergebnis landen:

$data = array_filter([
    '@context'  => 'https://schema.org',
    '@type'     => 'LocalBusiness',
    'name'      => $profile->getVineyardName(),   // Pflicht
    'telephone' => $profile->getPhone(),          // wird verworfen, wenn leer
    'image'     => $imageUrls,
]);

Fehlt der Name, liefert der Service einen leeren String – und es wird gar kein Markup ausgegeben. So entsteht nie ungültiges JSON-LD, egal wie vollständig ein einzelner Eintrag gepflegt ist.

3. Der passende Typ je Eintragsart

Nicht jede Verzeichnisseite ist gleich. Wir haben pro Eintragsart den semantisch korrekten schema.org-Typ gewählt:

• Winzer-Profile und Wine-Trade-Club-Mitglieder sind Unternehmen und damit LocalBusiness. Da schema.org keinen eigenen Typ “Weingut” kennt, ergänzen wir bei den Winzern ein additionalType, das auf den passenden Wikidata-Eintrag verweist – so bleibt der Eintrag spezifisch, ohne den Standard zu verlassen.
• Autorinnen und Autoren sind Personen und damit Person. Hier hinterlegen wir zusätzlich die Organisation, für die sie arbeiten, als verschachteltes Organization-Objekt.

Als url dient jeweils die kanonische, absolut aufgebaute Adresse der Detailseite selbst – denn nur die indexierbare Einzelseite trägt SEO-Wert, nicht die Listenansicht.

4. Sicher kodiert – editierbare Inhalte gehören abgesichert

Verzeichnisdaten werden oft von Redaktion oder den Mitgliedern selbst gepflegt. Solche Inhalte landen direkt im Seitenkopf – ein klassisches Einfallstor für XSS, wenn man unachtsam kodiert. Wir kodieren das JSON-LD mit JSON_UNESCAPED_UNICODE, behalten aber das Standard-Escaping der Schrägstriche bewusst bei. So wird ein im Text verstecktes </script> zu <\/script> und kann das umgebende Script-Tag nicht vorzeitig schließen. Umlaute und Akzente bleiben dabei trotzdem lesbar.

5. Welche Zusatzfelder einen Eintrag wirklich aufwerten

Mit dem minimal-gültigen Objekt ist der schnelle, günstige Hebel umgesetzt. Im nächsten Schritt stellt sich die Frage, welche zusätzlichen Felder den Aufwand lohnen. Gemeinsam mit dem Kunden haben wir hier priorisiert – nicht jedes denkbare Feld, sondern die mit dem größten Nutzen zuerst:

• Strukturierte Öffnungszeiten statt Freitext: als maschinenlesbare openingHoursSpecification (Wochentag, Öffnen, Schließen). Das ist der aufwändigste, aber auch wirkungsvollste Schritt, weil er die lokale Suche direkt bedient.
• Eine eigene Beschreibung, die den Eintrag inhaltlich greifbar macht.
• Gründungsjahr, Anbaufläche und Anbaumethode als optionale Detailfelder, die Profil und Markup zusätzlich anreichern.

Wichtig dabei: Jedes neue Feld bleibt optional und wird – wenn leer – weder auf der Seite noch im Markup ausgegeben. Das hält Profile aufgeräumt und das JSON-LD stets gültig.

Das Ergebnis

Mehrere Hundert Detailseiten der Plattform liefern Suchmaschinen jetzt strukturierte, valide Daten – Unternehmen als LocalBusiness, Autoren als Person. Erreicht haben wir das ohne neue Datenbankfelder, ohne Migrationen und ohne Backend-Umbau, allein aus dem vorhandenen Bestand. Das wiederverwendbare Service-Muster macht jede weitere Eintragsart zu einer kleinen, klar umrissenen Erweiterung statt zu einem Projekt.

Fazit

Strukturierte Daten sind einer der wenigen SEO-Hebel, die viel bewirken und wenig kosten – vorausgesetzt, man baut sie pragmatisch: minimal-gültige Objekte aus vorhandenen Feldern, leere Werte konsequent weglassen, sicher kodieren und die Logik in kleine, wiederverwendbare Services kapseln. Gerade Verzeichnis-, Mitglieder- und Profilseiten profitieren davon enorm, weil sie viele indexierbare Einzelseiten mit echten Daten besitzen.

Sie betreiben selbst ein Verzeichnis, ein Mitglieder- oder Branchenportal und möchten Ihre Detailseiten für Suchmaschinen besser auffindbar machen? Sprechen Sie mit uns – wir schauen uns an, welcher Markup-Hebel bei Ihnen am schnellsten wirkt.