Domain Property oder URL Präfix in der Search Console: Was passt?

Anders gesagt: Sie wählen nicht entweder das eine oder das andere. Sie nutzen beide Typen zusammen. Die Domain Property zeigt Ihnen das Gesamtbild, eine URL Präfix Property dagegen ein bestimmtes Protokoll, eine Subdomain oder einen Ordner. In diesem Leitfaden erklären Talha Aslan und Team die Einrichtung Schritt für Schritt. Falls Sie neu im Tool sind, lesen Sie zunächst unsere Google Search Console Anleitung für Einsteiger.

Was genau umfasst eine Domain Property?

Laut der Google Hilfeseite zum Hinzufügen einer Property deckt eine Domain Property die Stammdomain und alle Subdomains ab, und zwar unabhängig vom Protokoll. Eine Property für example.com fasst also http, https und ftp, Subdomains wie www und m sowie tiefere Ebenen in einem Bericht zusammen.

• http://example.com und https://example.com erscheinen in derselben Property.
• Subdomains wie www.example.com, m.example.com und blog.example.com gehören dazu.
• Jeder Ordner und jeder Unterpfad liegt im Umfang.
• Eine andere Endung bleibt außen vor; example.com enthält keine Daten von example.org.

Außerdem rät Google ausdrücklich davon ab, beim Anlegen ein www voranzustellen. Denn die Property enthält die Version mit und ohne www bereits gemeinsam. Deshalb geben Sie den Namen schlicht als example.com ein, ohne Protokoll und ohne Pfad.

Warum brauchen Sie trotzdem eine URL Präfix Property?

Eine URL Präfix Property erfasst nur Adressen, die mit genau dem eingegebenen Präfix beginnen, und das Präfix enthält das Protokoll. Die Property https://example.com/ sieht also weder http://example.com/ noch https://www.example.com/. Dieser enge Umfang wirkt zunächst wie eine Einschränkung. In der Praxis ist er allerdings oft genau das, was Sie brauchen.

Vor allem in diesen Fällen hilft Ihnen eine URL Präfix Property:

• Ein Team betreut nur den Blogordner und soll den Rest der Website nicht sehen.
• Ihre Website ist mehrsprachig, und Sie möchten /en/ und /de/ getrennt auswerten.
• Der DNS Zugang fehlt, deshalb verifizieren Sie per HTML Datei oder Tag.
• Eine Anwendung auf einer Subdomain soll getrennt von der Hauptseite erscheinen.

Andererseits empfiehlt Google auch den Seitenfilter im Leistungsbericht, um Daten der Domain Property nach Subdomain, Protokoll oder Pfad aufzuteilen. Somit ist die URL Präfix Property keine Pflicht. Stattdessen dient sie der Ordnung und der Rechteverwaltung.

Wie unterscheiden sich beide Property Typen im direkten Vergleich?

Die folgende Tabelle fasst den offiziellen Vergleich aus der Search Console Hilfe verständlich zusammen. So sehen Sie auf einen Blick, welche Property welche Aufgabe übernimmt.

Das Fazit ist einfach. Der erste Typ punktet beim Umfang, der zweite bei der Flexibilität. Deshalb betrachten wir beide als Partner, nicht als Konkurrenten.

Wie bestätigen Sie eine Domain Property per DNS Schritt für Schritt?

Die Google Seite zur Bestätigung der Inhaberschaft nennt für diesen Property Typ nur eine Methode: den DNS Eintrag beim Domainanbieter. Je nach Einrichtung erhalten Sie entweder einen TXT oder einen CNAME Eintrag. So gehen Sie vor:

1. Öffnen Sie den Dialog zum Hinzufügen einer Property und tippen Sie bei der Domainoption nur example.com ein.
2. Kopieren Sie den angezeigten Bestätigungseintrag, meist ist es ein TXT Eintrag.
3. Melden Sie sich in der DNS Verwaltung Ihrer Domain an und legen Sie einen neuen TXT Eintrag an.
4. Lassen Sie das Hostfeld leer oder tragen Sie @ ein.
5. Speichern Sie den Eintrag und klicken Sie danach in der Search Console auf Bestätigen.
6. Scheitert die Bestätigung, versuchen Sie es nach ein bis zwei Tagen erneut.

Bei manchen Anbietern kann Google den Eintrag für Sie setzen, bei anderen tragen Sie ihn von Hand ein. Ob der Eintrag schon sichtbar ist, prüfen Sie mit unserer DNS Abfrage.

Warum klappt die DNS Bestätigung manchmal nicht sofort?

Google erklärt, dass manuell angelegte Einträge zwei bis drei Tage brauchen können, bis sie sichtbar sind. Scheitert der erste Versuch, gibt es also keinen Grund zur Sorge. Lassen Sie den Eintrag stehen, warten Sie und versuchen Sie es erneut. Trotzdem sparen ein paar schnelle Prüfungen vorab Zeit.

• Vielleicht steht der Eintrag bei der falschen Domain, etwa bei einer Subdomain statt der Stammdomain.
• Vielleicht steht im Hostfeld die volle Domain, und das Panel hängt sie ein zweites Mal an.
• Beim Kopieren ist womöglich ein Leerzeichen in den Wert gerutscht.
• Ihre Nameserver zeigen eventuell auf einen anderen Dienst, dann bearbeiten Sie das falsche Panel.

Der letzte Fall begegnet uns in der Praxis am häufigsten. Haben Sie die Domain zum Beispiel bei einem Anbieter gekauft und die Nameserver auf ein CDN umgestellt, legen Sie den Eintrag in der DNS Ansicht dieses Dienstes an. Zudem verweist Google auf die Google Admin Toolbox, um zu sehen, welche Einträge Ihr Anbieter tatsächlich ausliefert.

Was passiert mit der Domain Property, wenn Sie den Bestätigungseintrag löschen?

Google bittet klar darum, den Eintrag nach erfolgreicher Bestätigung stehen zu lassen. Die Search Console prüft das Token regelmäßig. Findet sie es nicht mehr, erhalten Sie eine Nachricht; beheben Sie das Problem nicht, laufen Ihre Berechtigungen nach einer Kulanzfrist ab.

Seien Sie daher bei DNS Aufräumaktionen vorsichtig. Beispielszenario: Ein Websitebetreiber wechselt den Anbieter für E-Mail und löscht alte TXT Einträge in einem Rutsch, der Google Eintrag verschwindet gleich mit. Einige Tage später meldet die Property ein Zugriffsproblem. Die Lösung ist einfach: Eintrag neu anlegen, erneut bestätigen. Bemerkt es allerdings niemand, verliert womöglich das ganze Team den Zugang zu den Berichten.

Zudem weist Google darauf hin, dass alle Nutzer den Zugang verlieren, sobald alle bestätigten Inhaber ihn verlieren. Daher empfehlen wir, den Eintrag in Ihrer Dokumentation als „nicht anfassen“ zu markieren und diese Notiz mit allen zu teilen, die DNS bearbeiten.

Mit welchen Methoden bestätigen Sie eine URL Präfix Property?

Hier haben Sie mehr Auswahl. Die offizielle Seite nennt den Upload einer HTML Datei, ein HTML Tag, den Google Analytics Trackingcode, das Containersnippet von Google Tag Manager und einen DNS Eintrag. Bei Websites, die Google selbst hostet, etwa Google Sites oder Blogger, erfolgt die Bestätigung automatisch, wenn Sie mit demselben Konto angemeldet sind.

1. HTML Datei: Sie laden die Datei von Google ins Stammverzeichnis und lassen sie dort.
2. HTML Tag: Sie ergänzen ein Metatag im Head Bereich der Startseite.
3. Google Analytics: Sie nutzen Ihren vorhandenen Trackingcode, sofern Ihre Kontorechte reichen.
4. Tag Manager: Sie bestätigen über das Containersnippet mit passender Berechtigung.
5. DNS: Sie legen einen Eintrag an, genau wie beim domainweiten Typ.

Ein Detail ist wichtig. Laut Google bestätigt eine DNS Bestätigung der URL Präfix Property automatisch auch die passende Domain Property. Wählen Sie die Tag Methode, hilft Ihnen unser Meta Tag Generator, den Aufbau des Head Bereichs zu verstehen.

Welche Bestätigungsmethode hält am längsten?

Die Haltbarkeit hängt davon ab, wie stark Änderungen an der Website die Methode betreffen. Ein HTML Tag oder eine Datei verschwindet leicht bei einem Themewechsel oder Relaunch. Ebenso können die Methoden über Analytics und Tag Manager brechen, wenn jemand den Code entfernt oder Kontorechte ändert. Ein DNS Eintrag liegt dagegen außerhalb des Seitencodes, also berührt ihn ein Relaunch nicht.

Google empfiehlt außerdem, mehr als eine Methode einzurichten, damit der Zugang bestehen bleibt, falls eine ausfällt. Deshalb arbeiten wir meist mit drei Ebenen:

• Hauptebene: ein DNS Eintrag, den der domainweite Typ ohnehin braucht.
• Reserveebene: eine HTML Datei oder ein Tag in den URL Präfix Properties.
• Dokumentationsebene: ein kurzes Dokument, das festhält, welche Methode bei wem liegt.

Zieht die Website zum Beispiel auf ein neues Content Management System um, verschwindet vielleicht das Tag, der DNS Eintrag bleibt aber. Somit laufen Ihre Berichte ohne Lücke weiter.

Wie organisieren Sie mehrere Properties für eine Website?

Google rät, bei URL Präfix Properties für jedes Protokoll und jede Subdomain eine eigene Property anzulegen; auch Unterbereiche sind möglich. Ein Konto kann bis zu 1.000 Properties enthalten, also spielt die Grenze für eine typische Website kaum eine Rolle. Das eigentliche Problem ist Unordnung.

Als Beispielszenario nehmen wir eine Unternehmenswebsite in drei Sprachen. Diese Struktur empfehlen wir:

1. example.com als domainweite Property: die Gesamtansicht der Website.
2. https://www.example.com/ als URL Präfix Property: die bevorzugte Liveversion.
3. https://www.example.com/en/ und https://www.example.com/de/: eigene Ansichten für die Sprachteams.
4. https://shop.example.com/: eine Property für die Shop Subdomain.

Zudem erwähnt Google, dass untergeordnete Properties, die Sie nach der Bestätigung der übergeordneten anlegen, deren Methode automatisch übernehmen. Sie müssen also nicht jede Ordnerproperty einzeln bestätigen. Achten Sie bei wachsender Liste auf klare Namen; sonst steigt das Risiko, in der falschen Property zu arbeiten.

Wie verteilen Sie Inhaber und Nutzerrechte sinnvoll?

Die Google Seite zur Verwaltung von Inhabern, Nutzern und Berechtigungen definiert drei Stufen. Ein Inhaber hat volle Kontrolle, fügt Nutzer hinzu und ändert Einstellungen. Ein uneingeschränkter Nutzer sieht alle Daten, reicht Sitemaps ein und nutzt die URL Prüfung, kann aber keine Nutzer hinzufügen. Eingeschränkte Nutzer haben überwiegend Lesezugriff.

Nur Inhaber können Nutzer hinzufügen, und Google unterstützt keine E-Mail Gruppen. Denken Sie außerdem daran, ausgeschiedene Personen zu entfernen; unser Leitfaden zum Entfernen alter Inhaber und Nutzer zeigt, wie das geht.

Wer sollte Inhaber sein, wenn Sie mit einer Agentur oder Beratung arbeiten?

Unsere Haltung ist eindeutig. Die bestätigte Inhaberschaft gehört immer in das eigene Konto des Unternehmens. Für die Beratung genügt je nach Auftrag die Rolle als delegierter Inhaber oder uneingeschränkter Nutzer. So verlieren Sie den Zugang zu Ihren Daten nie, wenn die Zusammenarbeit endet.

Warum ist das so wichtig? Weil Probleme entstehen, sobald die Person mit dem Token geht. Google schreibt, dass nach dem Weggang des einzigen bestätigten Inhabers jemand neu bestätigen muss, um den Zugang zurückzuerhalten. Dafür brauchen Sie DNS oder Dateizugriff, und in einer hektischen Woche kann das Tage dauern.

Wenn Talha Aslan und Team im Rahmen unserer SEO Beratung an einer neuen Website starten, bringen wir zuerst die Property Struktur und die Kette der Inhaberschaft in Ordnung. Danach halten wir gemeinsam mit dem Kunden schriftlich fest, wer welche Rolle hat. Kurz gesagt: Die Daten gehören Ihnen, wir arbeiten mit dem Zugang, den Sie uns geben.

Wie führen Sie die Domain Property nach einem Domainumzug weiter?

Wechseln Sie die Domain, brauchen Sie getrennte Properties für alte und neue Domain. Laut der Google Seite zum Tool zur Adressänderung müssen Sie Inhaber beider Properties sein und dasselbe Google Konto nutzen. Zudem verschiebt das Tool Subdomains nicht automatisch; für jede Variante mit und ohne www stellen Sie einen eigenen Antrag.

1. Legen Sie die domainweite Property der neuen Domain vor dem Umzug an und bestätigen Sie sie per DNS.
2. Löschen Sie die Properties der alten Domain nicht, Sie brauchen sie zum Vergleich.
3. Richten Sie 301 Weiterleitungen von alten Seiten auf ihre neuen Gegenstücke ein.
4. Starten Sie das Tool zur Adressänderung in der alten Property.
5. Behalten Sie die Weiterleitungen laut Google mindestens 180 Tage, bei anhaltendem Traffic länger.

Laut Google eignet sich das Tool nicht für den Wechsel von HTTP auf HTTPS oder zwischen Varianten mit und ohne www. Die vollständige Liste finden Sie in unserer Checkliste für die Website Migration. Ihre Weiterleitungen testen Sie mit dem Redirect Checker.

Brauchen Sie beim Wechsel auf HTTPS eine neue Property?

Nicht, wenn Sie den domainweiten Typ nutzen. Er deckt http und https bereits gemeinsam ab, also sehen Sie Daten vor und nach dem Wechsel im selben Bericht. Das ist einer seiner praktischsten Vorteile.

Allerdings ändert sich die Lage, wenn Sie nur URL Präfix Properties verwenden. Die Property http://example.com/ sieht keine https Adressen, deshalb brauchen Sie für die https Variante eine eigene. Sonst zeichnen Ihre Berichte nach dem Wechsel ein irreführendes Bild. Der Traffic ist nicht eingebrochen, er liegt nur in einer anderen Property.

Beispielszenario: Ein Unternehmen beobachtet seit Jahren eine http Präfix Property. Nach dem Umstieg auf HTTPS fallen die Klicks fast auf null, und das Team schlägt Alarm. Das Problem ist kein Verlust, sondern die falsche Property. Zur Lösung legen Sie die domainweite Property an und vergleichen beide Zeiträume an einem Ort. Dass eine neue Property eine Weile leer bleibt, ist normal; unser Beitrag zur Meldung Daten werden verarbeitet erklärt den Grund.

Wie beobachten Sie Subdomains innerhalb einer Domain Property getrennt?

Weil dieser Typ alles zusammenführt, gehen Details manchmal unter. Eine Support Subdomain kann zum Beispiel die Klicks der Hauptseite aufblähen. Für diesen Fall nennt Google zwei Wege: den Seitenfilter im Leistungsbericht oder eine eigene URL Präfix Property je Bereich.

• Seitenfilter: ideal für einen schnellen Blick; Sie isolieren die Subdomain mit der Bedingung „URL enthält“.
• Eigene URL Präfix Property: dauerhafte Beobachtung, eigene Nutzerrechte und Berichte je Bereich.
• Gemischter Ansatz: Die Gesamtansicht bleibt domainweit, Teamansichten liegen in Präfix Properties.

Unserer Erfahrung nach liefert eine eigene Property immer dann sauberere Ergebnisse, wenn eine Subdomain ein eigenes Team hat. Außerdem lassen sich Indexierungsprobleme so je Bereich leichter prüfen; dabei hilft unsere Anleitung zu nicht indexierten Seiten.

Wie verändert die Wahl der Property die Zahlen im Leistungsbericht?

Unterschiedliche Klickzahlen für dieselbe Website in zwei Properties sind völlig normal. Denn jede Property zählt nur Adressen innerhalb ihres Umfangs. So fehlen in https://www.example.com/ etwa Klicks auf der m Subdomain oder auf der Version ohne www. Die domainweite Property addiert dagegen alles.

Diese Lücke sorgt in Berichtsrunden oft für Verwirrung. Eine Person bringt Zahlen aus der einen Property mit, eine andere aus der zweiten, und beide haben recht. Deshalb empfehlen wir, in jedem Bericht die Quelle zu nennen.

• Für Managementberichte wählen Sie die domainweite Property als einzige Quelle.
• Für Bereichsberichte nutzen Sie die passende Präfix Property und nennen sie in der Tabelle.
• Wechseln Sie die Property nicht zwischen Zeiträumen; sonst wirkt ein Umfangsunterschied wie eine echte Veränderung.

Sehen Sie einen plötzlichen Rückgang, prüfen Sie daher zuerst den Umfang der Property. Wie Sie echten Verlust von einem Umfangsunterschied trennen, zeigt unser Leitfaden zum Traffic Einbruch.

An welche Property senden Sie Ihre Sitemap?

Reichen Sie die Sitemap bei einer Property ein, die alle darin enthaltenen Adressen abdeckt. Der domainweite Typ umfasst alle Subdomains, also ist er meist die bequemste Wahl. Andererseits kann eine Sitemap in einer URL Präfix Property Probleme machen, wenn sie Adressen außerhalb des Präfixes enthält.

Beispielszenario: Ein Team reicht die Sitemap der ganzen Website bei der Property https://www.example.com/blog/ ein. Shop und Unternehmensseiten liegen außerhalb dieses Präfixes, deshalb zeigt der Bericht unerwartete Warnungen. Zur Lösung verschieben Sie die Sitemap in die umfassendere Property oder erstellen eine eigene für den Blog.

1. Prüfen Sie Protokoll und Subdomain der URLs in der Sitemap.
2. Wählen Sie die Property, die diese URLs vollständig abdeckt.
3. Reichen Sie die Sitemap ein und beobachten Sie einige Tage die Statusspalte.

Sehen Sie eine ähnliche Warnung, behandelt unser Beitrag zum Fehler URL in Sitemap nicht zulässig das Thema ausführlich.

Welche Property Struktur passt zu mehrsprachigen Websites?

Bei mehrsprachigen Websites bestimmt die Sprachstruktur den Property Plan. Liegen Sprachen in Ordnern wie /en/ und /de/, sammelt die domainweite Property bereits alle Sprachen. Dann legen Sie für den Ordner jedes Sprachteams eine Präfix Property an. Somit sieht jedes Team nur die Daten, für die es zuständig ist.

Liegen Sprachen auf Subdomains wie en.example.com, gilt dieselbe Logik, nur die Namen ändern sich. Nutzen Sie dagegen getrennte Länderdomains, brauchen Sie für jede eine eigene domainweite Property. Denn laut Google enthält die Property example.com keine Daten von example.de; die Endung ist Teil des Namens.

Unser Rat: Legen Sie keine Property an, bevor der Plan auf Papier steht. Halten Sie fest, welche Sprache in welcher Property liegt, wer welche Rolle erhält und wohin jede Sitemap geht. Dieses eine Blatt spart später die meiste Zeit, wenn das Team wächst.

Was prüfen Sie in der ersten Woche nach der Einrichtung?

Die Bestätigung ist erst der Anfang. Die erste Woche eignet sich am besten, um zu sehen, ob die Einrichtung wirklich funktioniert, denn neue Properties füllen sich innerhalb weniger Tage, und Fehler zeigen sich genau dann. Bei neuen Einrichtungen arbeiten wir diese kurze Liste ab:

1. Kommen Daten im Leistungsbericht an, und ist der Zeitraum plausibel?
2. Liegt die Sitemap in der richtigen Property, mit erfolgreichem Status?
3. Stehen in der Nutzerverwaltung nur die richtigen Personen?
4. Ist der Bestätigungseintrag im DNS weiterhin aktiv?
5. Liefert die URL Prüfung für die Startseite das erwartete Ergebnis?

Vergleichen Sie danach einige Tage lang alte Properties mit der neuen domainweiten. Die Zahlen weichen wegen des Umfangs ab. Verstehen Sie den Grund einmal und notieren Sie ihn; das verhindert später Fehlalarme. Sind die Klicks in der umfassenderen Property höher, liegt das zum Beispiel wahrscheinlich an der m Subdomain oder an der Version ohne www.

Schließlich teilen Sie das Dokument mit Property Plan und Bestätigungsmethoden mit dem Team. So weiß jeder, der DNS bearbeitet, was er nicht anfassen darf. Ein paar Minuten Kontrolle in der ersten Woche ersparen Ihnen monatelange Fehlinterpretationen.

Welche Fehler sehen wir bei der Einrichtung am häufigsten?

Die meisten Fehler aus der Praxis sind klein, ihre Folgen aber groß. Die folgende Liste zeigt die ersten Punkte, die wir bei einem Audit prüfen:

1. www oder https im Namen der domainweiten Property; richtig ist schlicht example.com.
2. Der einzige bestätigte Inhaber ist ein ehemaliger Mitarbeiter oder eine frühere Agentur.
3. Der Bestätigungseintrag verschwindet bei einer DNS Aufräumaktion.
4. Nach dem HTTPS Umstieg beobachtet das Team weiter die alte http Property.
5. Die Sitemap landet in der falschen Property.
6. Alle erhalten Inhaberrechte, obwohl eine Nutzerrolle genügt.

Zudem schreibt Google, dass Sie eine entfernte Property nur dann ohne neue Bestätigung wieder hinzufügen können, wenn noch mindestens ein bestätigter Inhaber besteht. Überlegen Sie also zweimal, bevor Sie eine Property löschen. Kurz gesagt: Ordnung beginnt bei der Einrichtung, späteres Aufräumen kostet immer mehr.

Wie oft sollten Sie Ihre Property Struktur prüfen?

Eine Search Console Einrichtung bauen Sie nicht einmal auf und vergessen sie dann. Mitarbeiter wechseln, Agenturen wechseln, DNS Anbieter wechseln. Deshalb empfehlen wir eine kurze, regelmäßige Routine. Die folgenden Abstände sind ein praxisbasierter Ausgangswert, keine feste Regel.

Passen Sie den Plan an Ihr Unternehmen an. Bei häufigem Personalwechsel lohnt sich zum Beispiel eine monatliche Prüfung der Nutzer. Für eine kleine Website mit selten geänderten DNS Einträgen genügt dagegen oft ein halbjährlicher Blick. Entscheidend ist, dass eine Person die Prüfung verantwortet und das Ergebnis kurz notiert.

Das ganze Audit dauert etwa eine halbe Stunde, doch wer es auslässt, verliert bei einem Umzug oder in einer Krise schnell Tage.

Sollten Sie die Einrichtung selbst übernehmen oder abgeben?

Mit DNS Zugang und einer einzelnen Website schaffen Sie die Einrichtung mit diesem Leitfaden selbst. Die Schritte sind nicht schwer; Sorgfalt verlangen vor allem die Kette der Inhaberschaft und die Nutzerrollen. Haben Sie allerdings mehrere Subdomains, Sprachordner oder einen anstehenden Umzug, kann ein einziger Fehler monatelange Entscheidungen auf falscher Datenbasis auslösen.

Ehrlich gesagt: Eine korrekte Property Struktur bringt allein keine Rankings, und niemand kann Rankings garantieren. Ohne korrekte Daten treffen Sie allerdings auch keine korrekten SEO Entscheidungen. Möchten Sie, dass wir Ihre Properties prüfen, einen Umzug planen oder Nutzerrechte ordnen, können Sie über unsere Seite zur SEO Beratung ein Angebot anfragen. Wir beheben das Problem auf Ihrer Website und verfolgen es danach mit regelmäßigen Berichten.

Zusammengefasst ist die Domain Property das Fundament für die Gesamtansicht, und URL Präfix Properties bringen Ordnung je Bereich und Team. Richten Sie beide gemeinsam ein und halten Sie die Inhaberschaft im Unternehmenskonto, dann können Sie sich jahrelang auf Ihre Search Console Daten verlassen.

Grundlagen: Was ist Online Marketing? Arten, Beispiele und Vorgehen auf einer Seite, mit einem interaktiven Film durch das Gehirn.