Mittwoch, 6. Februar 2019
Im Leistungsbericht der Search Console werden momentan alle Seitenmesswerte genau der URL zugeordnet, auf die der Nutzer über die Google Suche gelangt. Dadurch werden zwar präzise Daten angegeben, aber das Property-Management gestaltet sich recht kompliziert. Ein Beispiel: Wenn ihr die mobile Version und die Computerversion eurer Website als separate Properties hinzugefügt habt, müsst ihr mehrere Properties öffnen, um alle Daten der Google Suche für denselben Inhalt zu sehen.
Aus diesem Grund werden die Suchmesswerte in der Search Console demnächst der von Google ausgewählten kanonischen URL zugeordnet und nicht mehr der URL, auf die in der Google Suche verwiesen wird. Diese Änderung hat mehrere Vorteile:
- Alle Suchmesswerte für einen Inhalt werden unter einer URL gruppiert: der kanonischen URL. So erhaltet ihr über einen bestimmten Inhalt in einer Property einen besseren Überblick.
- Für Nutzer mit separaten mobilen oder AMP-Seiten werden alle Daten – oder zumindest die meisten, da bestimmte mobile URLs auch kanonisch sein können, – einer Property zugewiesen: der "kanonischen" Property.
- Die Berichte zu AMP-Seiten und für Mobilgeräte optimierten Seiten werden nutzerfreundlicher. In diesen Berichten werden Probleme momentan in der Property der kanonischen Seite aufgeführt, aber Impressionen erscheinen in der Property der URL, auf die in der Google Suche verwiesen wird. Nach der Änderung werden Impressionen und Probleme in derselben Property aufgeführt.
Wann wird die Änderung durchgeführt?
Wir planen, die gesamten Leistungsdaten am 10. April 2019 zu verschieben. Damit es keine Unterbrechungen gibt, werden wir schon ab Januar 2018 die neuen zusammengefassten Daten veröffentlichen. Außerdem werden wir die alte und die neue Version einige Wochen lang parallel anbieten, damit ihr euch die Unterschiede und die Auswirkungen genauer ansehen könnt.
API- und Data Studio-Nutzer: Für die Search Console API werden wir am 10. April 2019 zu den kanonischen Daten wechseln.
Inwiefern ändern sich dadurch die Daten?
- Für die einzelnen URLs: Es werden keine Zugriffe mehr für nicht kanonische (doppelte) URLs angezeigt, sondern nur noch für die kanonische URL.
- Für die Property: Die Daten der alternativen Property, zum Beispiel der mobilen Website, werden dann unter der "kanonischen Property" aufgeführt. Die Zugriffe für die alternative Property werden vermutlich nicht auf null sinken, weil die Kanonisierung auf der Seitenebene und nicht auf der Property-Ebene stattfindet. Daher gibt es möglicherweise auch für die mobile Property kanonische Seiten. Für die meisten Nutzer werden die Daten jedoch unter einer einzigen Property gruppiert. Die Zugriffe für AMP-Properties sinken in den meisten Fällen auf null. Eine Ausnahme sind eigenständige Seiten.
- Ihr könnt Daten auch weiterhin nach Gerät, Darstellung in der Suche (wie AMP), Land und anderen Dimensionen filtern, ohne dass dadurch wichtige Informationen zu den Zugriffen verloren gehen.
Einige Beispiele für diese Änderungen sind unten aufgeführt.
Änderung vorbereiten
- Überlegt, ob es notwendig ist, den Nutzerzugriff für die verschiedenen Properties zu ändern. Müsst ihr beispielsweise neue Nutzer zur kanonischen Property hinzufügen oder brauchen vorhandene Nutzer weiterhin Zugriff auf nicht kanonische Properties?
- Passt alle eure benutzerdefinierten Berichte zu Zugriffsdaten an, damit diese Änderung berücksichtigt wird.
- Die kanonische URL für eine vorhandene URL könnt ihr mit dem URL-Prüftool abfragen.
- Wenn ihr Zugriffsdaten speichern möchtet, die mit dem aktuellen System berechnet wurden, ladet ihr die Daten am besten über die Schaltfläche "Daten exportieren" im Leistungsbericht oder über die Search Console API herunter.
Beispiele
Hier sind einige Beispiele, inwiefern sich die Daten für eure Website ändern könnten. Ihr seht, wie sich die Anzahl der Zugriffe für die kanonische Website example.com und die alternative Website m.example.com ändern würden.
Wichtig: In diesen Beispielen enthält die Computerversion alle kanonischen Seiten und die mobile Website alle alternativen Seiten. In der Praxis habt ihr für eure Computerversion unter Umständen aber auch alternative Seiten und für die mobile Website einige kanonische Seiten angegeben. Ihr könnt die kanonische URL für eine vorhandene URL mit dem URL-Prüftool abfragen.
Zugriffe insgesamt
In der aktuellen Version werden einige Zugriffe der kanonischen Property zugeordnet und einige der alternativen Property. Bei der neuen Version werden alle Zugriffe unter der kanonischen Property zusammengefasst.
|
|
Kanonische Property
( https://example.com)
|
Alternative Property
( https://m.example.com)
|
| Aktuell |
|
|
| Neu, basierend auf kanonischen URLs |
|
|
| Veränderung | +700 | +3.000 | -700 | -3.000 |
Zugriffe auf einzelne Seiten
Alle Änderungen der Zugriffszahlen für die doppelten URLs und die kanonische URL einzelner Seiten findet ihr unter "Seiten". Im nächsten Beispiel seht ihr, dass die Zugriffe, die früher auf die kanonische Seite und die alternativen Seiten verteilt wurden, in Zukunft alle unter der kanonischen URL zusammengefasst werden:
|
Kanonische Property
(https://example.com) |
Alternative Property
(https://m.example.com) |
|
| Alt |
|
|
| Neu |
|
|
| Veränderung | +150 | +800 | -150 | -800 |
Zugriffe über Mobilgeräte
In der aktuellen Version werden alle Zugriffe über Mobilgeräte der "m."-Property zugeordnet. Bei der neuen Version werden alle Zugriffe unter der kanonischen Property zusammengefasst, wenn der Filter "Gerät: Mobilgerät" wie in dieser Abbildung zu sehen angewendet wurde:
|
Kanonische Property
( https://example.com)
|
Alternative Property
( https://m.example.com)
|
|
| Alt |
|
|
| Neu |
|
|
| Veränderung | +700 | +3.000 | -700 | -3.000 |
Fazit
Diese Änderung kann zuerst etwas verwirrend sein, aber wir sind uns sicher, dass sich dadurch auf lange Sicht die Zugriffsdaten für Websites besser verwalten lassen. Fragen oder Feedback könnt ihr uns gerne über das Forum für Webmaster zukommen lassen.