Das Putzlowitsch Test- und SEO-Blog

GSC-Liste – ein Bookmarklet für die Google-Search-Console

Bookmarklets

Bookmarklets sind feine Sachen, denn man kann tolle Dinge damit machen. :-)

Ein Bookmarklet ist ein Browser-Lesezeichen, welches aber nicht die URL einer Webseite speichert, sondern Javascript-Code. Dieser kann dann auf eine gerade im Browserfenster angezeigte Webseite losgelassen werden.

Das Bookmarklet hat Zugriff auf den kompletten Seiteninhalt, kann diesen verändern oder Daten extrahieren und z.B. in einem neuen Fenster darstellen.

Vor einiger Zeit hatte ich bereits mal ein Bookmarklet geschrieben, das die Ergebnisseite der Google-Bildersuche auswertet und eine neue, übersichtliche Listenansicht erstellt. Die Daten aus dieser Ansicht können auch als CSV-Datei gespeichert werden.

Die Google-Search-Console, ehemals Webmaster-Tools

GSC – Indexierungsstatus

Die Google-Search-Console (GSC) bietet dem Webmaster viele nützliche Werkzeuge und Statistiken. So kann man sich z.B. den Indexierungsstatus für eine Website ansehen.

Der Bericht „Indexierungsstatus“ bietet Daten zu den URLs, die Google im vergangenen Jahr in der aktuellen Property zu indexieren versuchte.

Dieser Wert gibt die Gesamtzahl der URLs an, die für die Anzeige in den Suchergebnissen verfügbar sind, zusammen mit weiteren URLs, die Google mit anderen Methoden finden könnte. Diese Zahl variiert im Laufe der Zeit, während Sie Seiten hinzufügen und entfernen. Die Anzahl der indexierten URLs ist fast immer deutlich kleiner als die Anzahl der gecrawlten URLs, weil unter Insgesamt indexiert nicht jene URLs aufgeführt werden, die als Duplikate oder nicht kanonisch betrachtet werden oder die ein noindex-Meta-Tag enthalten.

Mit dem Button [Diagrammdaten herunterladen] kann man die Daten als CSV-Datei oder in Google-Docs speichern. Teilweise kann man Daten auch per GSC-API abfragen, speichern und weiterverarbeiten.

Nur leider gibt es diese Möglichkeit nicht in allen Bereichen der Search-Console.

Speichern oder nicht speichern, das ist hier die Frage

Wegen eines Problems mit einem meiner Webhoster waren Anfang des Jahres zwei Statistiken für mich besonders interessant, die „Website-Fehler“ und die „Crawling-Statistiken“.

Und genau bei diesen Statistiken gibt es keine Speichermöglichkeit und meines Wissens auch keinen Zugriff per API. Man kann bestenfalls einen Screenshot machen, aber da sieht man keine konkreten Zahlen. Beim Überfahren des Diagramms mit der Maus werden zwar die Daten zum aktuelle Datenpunkt eingeblendet, aber eben nur für den einen.

GSC – Keine Antwort vom Server

Aber irgendwo auf der Webseite müssen die Daten ja zu finden sein, wenn sie als Tooltip-Fenster angezeigt werden können.

GSC-Liste Bookmarklet

Ja, die Daten sind auf der Webseite zu finden und genau hier kommt nun das Bookmarklet ins Spiel. Es extrahiert die Daten und stellt sie als CSV-Datei bereit. Es gibt keinerlei Einstellmöglichkeiten und es wird auch keine neue Browserseite geöffnet. Der Klick auf [GSC Liste] öffnet nur den „Datei speichern“-Dialog.

GSC-Liste als CSV-Datei speichern

Der Dateiname wird aus dem letzten Teil des Pfades der URL in der GSC (‚crawl-stats‘, ‚crawl-errors‘), dem Domain-Namen und dem Datum von bis zusammengesetzt.

Hier findet Ihr das Bookmarklet Version 1.0:

GSC Liste

Die Bookmarklets sind zwar Links, es macht aber wenig Sinn, diese hier direkt anzuklicken. Vielmehr müßt Ihr sie als Lesezeichen im Browser speichern, also z.B. einfach in die Bookmarkleiste ziehen.

Das Bookmarklet funktioniert nur auf den Seiten „Crawling-Statistiken“ und „Crawling-Fehler“ in der Google-Search-Console.

Ich habe es mit den aktuelle Desktop-Versionen von Firefox (57.0.4) und Chrome (63.0.3239.132) getestet. Damit funktioniert es. Wie es mit anderen Browsern aussieht, kann ich nicht sagen. Das könnt Ihr gerne ausprobieren und hier dann in den Kommentaren berichten. :-)

2 Kommentare »

Google-Suchanalyse funktioniert nun für Bildersuche in DE

Vor knapp vier Monaten war mir ein Problem in der neuen Google-Suchanalyse mit der Bildersuche bei google.de aufgefallen. Mittlerweile hat Google das Problem behoben. Seit dem 4. August werden jetzt auch brauchbare Daten beim Filter „Bild“ geliefert:

Links die alten Suchanfragen, rechts die neue Suchanalyse, jeweils für den Suchtyp Bild und den Zeitraum der letzten 28 Tage. Die aktuellen Zahlen:

Tool Impressions Klicks Impressions (de) Klicks (de)
Suchanfragen 1.097.952 10.322 840.490 8.185
Suchanalyse 774.157 5.596 582.169 5.292
Anteil in % 70,51 54,16 69,27 64,65

Warum die Zahlen der Suchanalyse möglicherweise insgesamt geringer als die der alten Suchanfragen sind, wird in den Hilfetexten erläutert.

Nun stimmt aber das Verhältnis von Impressionen und Klicks zwischen Suchanalyse und Suchanfragen halbwegs überein. Man kann es auch an der CTR für DE sehen, die zwischen Suchanalyse (0,91%) und Suchanfragen (0,97%) in etwa gleich ist.

So ist nun die Suchanalyse auf für die Bildersuche in DE brauchbar. Jetzt kann ich mich auch mal mit der Suchanalyse-API beschäftigen. Zur Zeit rufe ich die Daten für meine interne Statistik noch über die alten Suchanfragen ab. Die funktioniert zwar noch, aber bestimmt nicht ewig.

Ein Kommentar »

Neue Google-Suchanalyse für Bildersuche in DE unbrauchbar

Seit heute ist die neue Suchanalyse in den Google-Webmastertools für alle verfügbar. Erfreulicherweise kann man sich auch noch die Daten der alten „Suchanfragen“ ansehen, was einen Vergleich der beiden Statistiken ermöglicht. So sieht das z.B. bei die Bildersuche für meine Putzlowitsch-Seite aus:

Links die alten Suchanfragen, rechts die neue Suchanalyse, jeweils für den Suchtyp Bild und den Zeitraum der letzten 28 Tage. Die ernüchternden Zahlen:

Tool Impressions Klicks Impressions (de) Klicks (de)
Suchanfragen 1.604.929 12.413 1.205.558 8.451
Suchanalyse 1.096.689 300 795.956 20
Anteil in % 68,33 2,41 66,02 0,23

Gut, bei den Impressions sind es nur noch ca. zwei Drittel, daß kann ich nicht wirklich beurteilen, liegt aber im Rahmen der verbesserten Genauigkeit, die in der Hilfe beschrieben wird:

Aber nur noch etwa 2,5% bei den Klicks erscheint mir sehr wenig zu sein. Wenn ich die Daten nach Deutschland filtere, wird es noch dramatischer. Nur noch lächerliche 0,23% bleiben da übrig. Mit anderen Worten, in 4 Wochen haben nur 20 Leute auf eines meiner Bilder geklickt. Dabei findet man meine Bilder durchaus an vorderen Positionen und auch in der Bilder-Box der Websuche und im Knowledge-Graph.

Zum Thema Bilder und Bildersuche gibt es natürlich auch Hinweise und Erklärungen in der Hilfe:

Anzahl der Klicks für Bilder verringert. Der neue Bericht „Suchanalyse“ zählt bei einem Bildersuchergebnis, das auf Ihre Seite verweist, nur Klicks auf ein maximiertes Bild oder auf den Link „Seite besuchen“. Der ältere Bericht „Suchanfragen“ hat jeden Klick auf ein Bild sowohl bei der Websuche als auch bei der Bildersuche gezählt, auch wenn das Bild nicht maximiert wurde. Dies bedeutet, dass die Anzahl der Klicks im neuen Bericht niedriger ausfällt, aber sehr viel aussagekräftiger ist.

Und weiter:

Was zählt als Klick?
Klicks werden nur gezählt, wenn sie den Nutzer zu Ihrer Property leiten. Klicks werden nicht gezählt, wenn sie zur Weiterleitung innerhalb der Suchergebnisse führen. Beispiel:
– Der Klick auf ein Bild in Websuchergebnissen wird nicht als Klick gezählt. Bilderklicks werden nur gezählt, wenn der Klick zur Website führt, etwa beim Klicken auf das Bild oder den Link „Seite besuchen“ innerhalb der Bildersuche. Beim Klick auf ein Bild in der Websuche gelangt der Nutzer üblicherweise zur Bildersuche, wo das angeklickte Bild maximiert wird, was nicht als Klick zählt.
– Klicks, die zu anderen suchinternen Funktionen führen, wie die meisten Knowledge Graph-Klicks, werden im Bericht nicht gezählt.

Und genau da liegt der Hase begraben, oder die Ursache des Problems. Bei der Websuche oder Bildersuche auf google.de führt der Klick auf ein Ergebnis, sei es nun in der Bildersuche oder Websuche (Bilderbox, Knowledge-Graph) eben nicht zum vergrößerten Bild oder intern zur Bildersuch, sondern zu meiner Seite (im alten Bildersuche-Frameset). Um es mit Google zu formulieren, der Klick leitet den Nutzer zu meinem Property, wir nun aber trotzdem nicht gezählt.

Entweder Google bessert da nochmal nach, oder man kann die neue, schicke Suchanalyse für die Bildersuche in DE nicht gebrauchen. Leider soll die alte Suchanfragen-Statistik in drei Monaten abgeschaltet werden. Mit der könnte ich gut auch noch länger weiterleben. :-)

Weitere Artikel mit Bezug zu diesem:
5 Kommentare »

Google Webmaster-Tools: 404 Fehler von 404-Fehlerseiten verlinkt

Nicht gefunden

URL: httрs://рutzlοwitsсh.dе/wp-cοntеnt/uрlοads/2011/06/kindеrtag-

Fehlerdetails

Zuletzt gecrawlt am: 29.12.14
Erstmals erkannt am: 29.12.14

Der Googlebot konnte diese URL nicht crawlen, da keine zugehörige Seite existiert. Im Allgemeinen wirken sich 404-Codes nicht auf die Leistung Ihrer Website bei der Suche aus. Sie können sie jedoch zur Verbesserung der Nutzererfahrung verwenden.

Verlinkt über

httр://рutzlοwitsсh.dе/wp-cοntеnt/uрlοads/2011/06/kindеrtag-

Möglicherweise werden nicht alle URLs aufgeführt.

Google WMT-Fehler-404 mit Link von 404-Seite

Das habe ich gerade in den Google-Webmaster-Tools entdeckt. Die angegebene URL zeigt in Uploads-Verzeichnis, also dahin, wo die Bilder liegen.

Wie solche URLs enstehen können, darüber habe ich ja schon ein paar Mal etwas geschrieben [1][2][3].

Selbstreferenzielle Fehler

Das Interessante ist nun aber, welche Seite in den Google-WMT als Link-Quelle (Verlinkt über…) angezeigt wird. Das ist nämlich die Seite selbst, oder genau genommen, die Fehlerseite.

Der Webserver liefert den passenden HTTP-Statuscode 404 zurück und noch einen mehr oder weniger nützlichen Text für den Nutzer. Dieser sieht den Statuscode ja normalerweise nicht.

Die Standard-Fehlerseite des Apache-Webservers ist eher schlicht gehalten:

Not Found
The requested URL /wp-cοntеnt/uрlοads/2011/06/kindеrtag- was not found on this server.

Die angeforderte URL sowieso wurde auf diesem Server nicht gefunden.

Fehlerseite 404

Genau da liegt wohl das Problem, denn die fehlerhafte URL wird auf der Fehler-Seite als Text (!) ausgegeben. Kein Link, nicht mal ein http:// oder https:// steht vorne dran.

Aber wie wir wissen, reimt sich Google bzw. der Google-Bot gerne mal URLs aus Sachen zusammen, die irgendwie entfernt nach einer URL aussehen.

Ein Teufelskreis?

Nun ensteht dadurch ein Problem, denn die angeblich verlinkende Seite existiert natürlich und wird auch weiterhin existieren. Es ist ja schließlich die Fehlerseite des Webservers.

Wenn ein „Link“ aber weiterhin besteht, wird Google auch immer mal wieder die Seite aufrufen um zu sehen, ob sie vielleicht doch existiert. Im Ergebnis wir dann die Link-Quelle auch immer aktualisiert und bleibt bestehen. Ein endloser Kreislauf. Oder doch nicht?

Ich könnte zwar die Fehlerseite anpassen, so das die nicht gefunden URL nicht mehr angezeigt wird, aber warum? Soll der Google-Bot doch Zeit mit Fehlern verplämpern, ist nicht mein Problem.

Die wahre Fehlerquelle

Ich habe auch die wahrscheinlich wirkliche Fehlerquelle gefunden:

Umgebrochener Linktext in Google-Groups

In diesem Beitrag bei Google-Groups wir der sichtbare Linktext umgebrochen und damit die URL an der Stelle abgeschnitten, so wie es oben als fehlerhafte URL zu sehen ist. Der darunter liegende Link zum Bild funktioniert hingegen einwandfrei.

Der Text httр://рutzlοwitsсh.dе/wp-cοntеnt/uрlοads/2011/06/kindеrtag- sieht halt so schön nach einer URL aus, also nimmt Google ihn als URL mit und schickt den Google-Bot vorbei.

Wie sagt John Müller das doch so schön im Webmaster-Hangout:

„Wir möchten sichergehen, dass wir nichts verpasst haben.“

Und die Moral von der Geschicht

Trau den Google-Webmaster-Tools nicht. Zumindest nicht immer.

Wenn in den Google-Webmastertools der Beitrag bei Google-Groups als Link-Quelle angezeigt werden würde, dann wäre das wirklich hilfreich. Aber die Fehlerseite selbst als Quelle anzugeben, halte ich, nun ja, für einen Fehler.

Kommentare deaktiviert für Google Webmaster-Tools: 404 Fehler von 404-Fehlerseiten verlinkt

Google Webmastertools: Hinweis auf mobile Benutzerfreundlichkeit

Vorhin erhielt ich eine neue Meldung in den Google-Webmastertools.

Beheben Sie Probleme der mobilen Nutzerfreundlichkeit auf …
An: Webmaster von …
Die Systeme von Google haben 7 Seiten Ihrer Website getestet und bei 43 % dieser Seiten kritische Fehler in Bezug auf die Nutzerfreundlichkeit auf Mobilgeräten erkannt. Die Fehler auf den 3 Seiten beeinträchtigen die Nutzererfahrung auf Mobilgeräten für Ihre Website deutlich. Diese Seiten werden von der Google-Suche als nicht für Mobilgeräte optimiert eingestuft, und werden entsprechend in den Suchergebnissen für Smartphone-Nutzer dargestellt.

Und als erster Tip steht darunter:

1. Problematische Seiten finden
Rufen Sie einen Bericht mit Details zu den nicht für Mobilgeräte optimierten Seiten Ihrer Website sowie die jeweiligen Probleme auf.
[ Probleme anzeigen ]

Der Klick auf „Probleme anzeigen“ führt mich direkt zur Ansicht „Suchanfragen -> Benutzerfreundlichkeit auf Mobilgeräten“. Hier wird mir dann Folgendes angezeigt:

Benutzerfreundlichkeit auf Mobilgeräten

Seit dem 23. Dezember 2014 ist also alles in Ordnung. Es sind keine Fehler mehr vorhanden.

Es ist ja nett, daß Google mich auf Probleme mit der mobilen Benutzerfreundlichkeit aufmerksam macht. Nur kommt diese Meldung hier mindestens 3 Wochen zu spät. :-)

4 Kommentare »