Search Console: Nutzer hinzufügen und Rechte verwalten

Einen Nutzer in der Search Console hinzuzufügen dauert eine halbe Minute: Einstellungen öffnen, „Nutzer und Berechtigungen“ wählen, „Nutzer hinzufügen“ klicken, E-Mail-Adresse eintragen, Rolle auswählen. Die eigentliche Arbeit liegt nicht im Klicken, sondern in der Entscheidung davor. Es gibt mehrere Rollen, sie unterscheiden sich spürbar, und die falsche Wahl rächt sich meist erst Monate später, wenn eine Agentur geht, ein Mitarbeiter das Unternehmen verlässt oder niemand mehr weiß, wer eigentlich die Kontrolle über die Property hat.

Dieser Beitrag beantwortet genau diese Verwaltungsfrage: Welche Rolle bekommt wer, worin unterscheiden sich bestätigte und delegierte Inhaber, wie behältst du den Überblick und wie entziehst du Zugänge vollständig, wenn jemand geht. Wie die Search Console selbst funktioniert und welche Berichte sie liefert, erklärt der allgemeine Leitfaden zur Search Console; hier geht es ausschließlich um Zugriff und Verantwortung.

Die vier Rollen im Überblick

In der Search Console gibt es für Personen vier Stufen, und sie sind nicht gleichwertig. Ganz oben steht der bestätigte Inhaber: Er hat die Property selbst durch eine Bestätigungsmethode nachgewiesen, also etwa durch eine DNS-Eintragung, eine HTML-Datei, ein Meta-Tag oder über Google Analytics beziehungsweise den Tag Manager. Direkt daneben steht der delegierte Inhaber, den ein bestätigter Inhaber in der Nutzerliste ernannt hat. Darunter folgt der Nutzer mit Vollzugriff und zuletzt der eingeschränkte Nutzer.

Inhaber dürfen alles, was in der Property überhaupt möglich ist. Dazu gehören das Hinzufügen und Entfernen anderer Nutzer, das Ändern von Einstellungen, das Senden und Zurückziehen bestimmter Anträge und der Umgang mit Sicherheitsproblemen und manuellen Maßnahmen. Nutzer mit Vollzugriff sehen alle Daten und können die meisten Aktionen auslösen, etwa Seiten zur Indexierung einreichen, Sitemaps verwalten oder Berichte teilen, aber sie können keine weiteren Nutzer verwalten und keine Inhaberfunktionen ausführen. Eingeschränkte Nutzer sehen den Großteil der Daten, können aber kaum etwas verändern.

Davon zu unterscheiden sind Verknüpfungen, die du unter „Einstellungen“ findest. Wenn du Google Analytics, YouTube oder andere Google-Dienste mit der Property verknüpfst, ist das keine Nutzerrolle, sondern eine Datenverbindung. Sie taucht in der Nutzerliste nicht auf und muss beim Aufräumen separat geprüft werden. Genauso wenig ist ein Dienstkonto für die API ein Mensch, auch wenn es in der Liste wie ein Nutzer erscheint.

Welche Rolle für wen? Drei typische Fälle

Die einfachste Regel lautet: So wenig Rechte wie möglich, so viele wie nötig. Was das praktisch heißt, zeigen drei Konstellationen, die in Unternehmen ständig vorkommen.

Erstens das Redaktionsteam. Redakteure wollen sehen, welche Suchanfragen auf ihre Artikel führen und welche Seiten Impressionen, aber kaum Klicks haben. Dafür reicht der eingeschränkte Zugriff völlig. Niemand in der Redaktion muss Sitemaps einreichen oder Einstellungen ändern, und ein versehentlicher Klick kann nichts beschädigen.

Zweitens die SEO-Verantwortliche oder der Entwickler. Wer technische Probleme untersucht, Seiten zur Indexierung einreicht und Sitemaps pflegt, braucht Vollzugriff. Das Ändern der Rechte anderer braucht er dafür nicht. Gerade bei Entwicklern wird oft reflexhaft Inhaberstatus vergeben, weil sie „sowieso alles“ machen. Das ist unnötig, denn die Bestätigung der Property läuft ohnehin über DNS oder Code, und genau dort haben Entwickler ihre eigenen Wege.

Drittens die externe Agentur. Hier lohnt sich ein genauer Blick. Für laufende Beratung genügt fast immer Vollzugriff. Inhaberrechte braucht eine Agentur nur in Ausnahmefällen, etwa wenn sie eine Domainumstellung begleitet, bei der die Adressänderung genutzt wird, oder wenn sie bei einer manuellen Maßnahme den Antrag auf erneute Prüfung stellen soll. Selbst dann gilt: Rechte befristet vergeben und danach zurücknehmen.

Nutzer hinzufügen: Schritt für Schritt und die häufigsten Stolpersteine

Der Ablauf ist kurz, aber an mehreren Stellen entscheidet sich, ob es beim ersten Mal klappt. Du brauchst selbst Inhaberstatus in der Property, in der die Person Zugriff erhalten soll; sonst fehlt in den Einstellungen der Menüpunkt zum Hinzufügen oder er ist ausgegraut.

Der häufigste Fehler ist die falsche Property. Wer eine Website sowohl als Domain-Property als auch als URL-Präfix-Property eingerichtet hat, fügt den Nutzer gern in der einen hinzu, während die Person in der anderen nach Daten sucht und nichts findet. Der zweithäufigste Fehler ist die falsche Adresse: Der Kollege meldet sich privat mit einer anderen Gmail-Adresse an als der, die du eingetragen hast. Frage vorher nach der Adresse, die tatsächlich für Google-Dienste benutzt wird. Und: Berechtigungen gelten je Property, nicht je Konto. Wer mehrere Properties betreut, muss in jeder einzeln eingetragen werden.

• Wähle oben links die richtige Property. Bei einer Domain-Property gilt die Berechtigung für alle Subdomains und Protokolle, bei einer URL-Präfix-Property nur für genau dieses Präfix.
• Öffne „Einstellungen“ und dann „Nutzer und Berechtigungen“. Klicke auf „Nutzer hinzufügen“.
• Trage die E-Mail-Adresse ein, und zwar die, mit der die Person bei Google angemeldet ist. Das kann ein Google-Workspace-Konto oder ein privates Google-Konto sein. Eine beliebige Firmenadresse ohne Google-Konto funktioniert nicht.
• Wähle die Berechtigung: „Inhaber“ (delegiert), „Vollständig“ oder „Eingeschränkt“. Bestätigen, fertig.
• Die Person erhält eine Benachrichtigung und sieht die Property nach dem nächsten Laden der Oberfläche in ihrer Liste.

Bestätigter gegenüber delegiertem Inhaber

Dieser Unterschied ist der wichtigste Punkt der ganzen Rechteverwaltung, und er wird fast immer übersehen. Ein bestätigter Inhaber hat die Property selbst nachgewiesen. Die Bestätigung hängt an einem konkreten Token: einem DNS-Eintrag, einer Datei im Stammverzeichnis, einem Meta-Tag im Quelltext oder einer Verbindung zu Analytics oder Tag Manager. Solange dieser Token existiert, bleibt die Inhaberschaft bestehen. Verschwindet er, etwa weil die Seite relauncht wurde und die HTML-Datei fehlt, verliert der Inhaber seinen Status, obwohl in der Nutzerliste nie jemand etwas geändert hat.

Ein delegierter Inhaber hat dagegen keinen eigenen Token. Er wurde von einem bestätigten Inhaber in der Nutzerliste ernannt und erhält damit praktisch dieselben Rechte. Das ist für Agenturen und Kollegen bequem, weil sie nichts auf dem Server ändern müssen. Es bedeutet aber auch: Die Inhaberschaft kann in der Nutzerliste von jedem Inhaber entzogen werden, und sie ist nur so stabil wie die bestätigte Inhaberschaft, auf der die Property insgesamt aufsetzt.

Daraus folgt eine praktische Empfehlung. Sorge dafür, dass mindestens ein bestätigter Inhaber zur Organisation gehört und nicht zu einer Agentur, und nutze, wenn möglich, die Bestätigung per DNS über die Domain, die deine Firma kontrolliert. Ein DNS-Eintrag überlebt Relaunches, Theme-Wechsel und CMS-Umzüge, weil er mit dem Hosting der Seite nichts zu tun hat. Wer dagegen auf das Meta-Tag im Theme oder eine Datei im Webroot setzt, riskiert, dass die Bestätigung bei der nächsten Umstellung unbemerkt wegfällt.

Hinzu kommt ein Detail, das beim Aufräumen wichtig wird: Einen bestätigten Inhaber kannst du nicht einfach über die Nutzerliste löschen. Die Search Console verlangt, zuerst die Bestätigung aufzuheben, also den Token zu entfernen. Bei einem delegierten Inhaber genügt dagegen der Klick auf „Nutzer entfernen“.

Zugänge aufräumen, wenn jemand geht

Der Abschied einer Mitarbeiterin oder der Wechsel einer Agentur ist der Moment, in dem Rechte meist vergessen werden. Der Zugang bleibt bestehen, weil niemand die Liste öffnet, und erst beim nächsten Audit fällt auf, dass ein ehemaliger Dienstleister weiterhin Daten einer Seite sehen, teilweise sogar Änderungen auslösen kann. Eine kurze Checkliste hilft, nichts auszulassen.

Eine Reihenfolge ist dabei wichtig: Erst sicherstellen, dass es einen eigenen Inhaber gibt, dann entfernen. Wer zuerst entzieht, steht im schlimmsten Fall ohne jeden Inhaber da und muss die Property neu bestätigen, was bei einer kaputten DNS-Verwaltung oder unbekanntem Hoster mühsam werden kann.

• Nutzerliste je Property durchgehen und die Person oder Agentur entfernen. Bei mehreren Properties derselben Website, etwa Domain- und URL-Präfix-Property, in allen nachsehen.
• Prüfen, ob die Person bestätigter Inhaber ist. Wenn ja, erst einen anderen bestätigten Inhaber aus der eigenen Organisation einrichten, dann den Token der alten Bestätigung entfernen und danach in der Nutzerliste löschen.
• Unter „Einstellungen“ die Bestätigungsdetails ansehen. Dort siehst du, über welche Methoden die Property bestätigt ist. Alte Meta-Tags, Dateien oder DNS-Einträge einer Agentur gehören entfernt, sonst bleibt ein Hintertürchen.
• Verknüpfungen prüfen: Ist ein Analytics-Konto oder ein YouTube-Kanal des Dienstleisters verbunden, sollte diese Verbindung gelöst werden.
• Dienstkonten und API-Zugriffe kontrollieren. Wenn die Agentur Berichte automatisiert abruft, steht ein Dienstkonto in der Liste, das nach dem Ende der Zusammenarbeit weiterläuft, bis jemand es entfernt.
• Benachrichtigungen und geteilte Links beachten. Wer als Empfänger von Nachrichten zu Indexierungsproblemen oder Sicherheitswarnungen geführt wird, sollte ersetzt werden, damit wichtige Hinweise nicht ins Leere laufen.

Domain-Property oder URL-Präfix: wo Rechte wirklich greifen

Rechte gelten immer für die Property, in der du sie vergibst. Eine Domain-Property fasst alle Protokolle und Subdomains zusammen, also http und https sowie www, Shop- oder Blog-Subdomain. Wer dort Vollzugriff erhält, sieht die Daten aller dieser Varianten. Bei einer URL-Präfix-Property beschränkt sich der Zugriff auf genau das eingetragene Präfix. Das lässt sich gezielt nutzen: Soll eine externe Redakteurin nur den Blog unter einem Unterverzeichnis sehen, legst du dafür eine URL-Präfix-Property an und vergibst dort eingeschränkten Zugriff, statt ihr die gesamte Domain zu öffnen.

Die Kehrseite ist der Überblick. Gewachsene Konten enthalten oft fünf oder mehr Properties derselben Website, angelegt von wechselnden Personen über die Jahre. Jede hat eine eigene Nutzerliste. Beim Aufräumen genügt es deshalb nicht, nur die Hauptproperty zu prüfen. Öffne die Property-Auswahl, gehe jede Variante durch und notiere, wo die betreffende Person auftaucht. Überflüssige Properties kannst du als Inhaber entfernen, sobald niemand sie mehr braucht; vorher lohnt sich ein Export der Berichte, falls dort noch Verlaufsdaten liegen, die in der Hauptproperty fehlen.

Ein Beispiel: Agenturwechsel in fünf Schritten

Stell dir einen mittelgroßen Onlineshop vor. Die bisherige Agentur hat vor drei Jahren die Domain-Property angelegt und per DNS-Eintrag bestätigt, den sie im Namen des Kunden beim Domain-Anbieter gesetzt hat. Außerdem ist sie als Inhaber eingetragen. Nun endet der Vertrag, und eine neue Agentur übernimmt.

Zunächst richtet der Shopbetreiber, also jemand mit Zugriff auf die DNS-Verwaltung, eine eigene Bestätigung ein: einen zweiten TXT-Eintrag mit einem neuen Token, den die Search Console für die Property ausgibt. Damit gibt es einen bestätigten Inhaber aus dem eigenen Haus. Anschließend ernennt er die neue Agentur als Nutzer mit Vollzugriff, und nur falls ein konkreter Anlass besteht, als delegierten Inhaber mit einer Frist.

Erst danach wird der alte TXT-Eintrag der Agentur gelöscht und die Bestätigung in der Search Console neu geprüft. Fällt ein Konto als bestätigter Inhaber weg, lässt es sich jetzt in der Nutzerliste entfernen. Zuletzt werden Verknüpfungen, Dienstkonten und Benachrichtigungsempfänger kontrolliert. Das Ergebnis ist eine Property, die nach dem Wechsel dem Unternehmen gehört und nicht von der Gutwilligkeit eines Dienstleisters abhängt.

Wichtig ist der Datenaspekt. Daten, die bisher aufgezeichnet wurden, gehen beim Wechsel nicht verloren, solange die Property selbst bestehen bleibt. Wer hingegen eine neue Property anlegt, weil der alte Zugang verloren ging, beginnt mit leerer Historie, denn die Search Console liefert rückwirkend keine Daten für neu angelegte Properties. Deshalb ist der Erhalt der bestehenden Property wichtiger als jede Bequemlichkeit bei der Neuanlage.

Regeln, mit denen die Rechteverwaltung dauerhaft sauber bleibt

Einmaliges Aufräumen reicht nicht, weil sich Teams verändern. Wer die Nutzerliste als Teil der normalen Offboarding-Routine behandelt, vermeidet die meisten Probleme, ohne viel Zeit zu investieren. Hilfreich sind wenige, klare Regeln.

Vergib Zugänge an namentliche Personen mit der Firmenadresse, nicht an Sammelpostfächer oder geteilte Logins. Geteilte Konten verhindern, dass du nachvollziehen kannst, wer etwas getan hat, und sie lassen sich beim Weggang einer Person kaum sauber beenden. Halte außerdem mindestens zwei Inhaber aus der eigenen Organisation vor, damit die Property nicht an einer einzigen Person hängt, die krank wird oder kündigt.

Dokumentiere, wer warum welche Rolle hat, und überprüfe die Liste in festen Abständen, etwa einmal im Quartal und bei jedem Agenturwechsel. Die Liste selbst zeigt dir Rolle und Adresse, aber nicht den Grund. Eine kurze Notiz im internen Wiki genügt. Und befriste Inhaberrechte für Dienstleister, statt sie dauerhaft zu belassen: Der Kalendereintrag zum Entziehen ist billig, der Schaden durch einen vergessenen Inhaber nicht.