Das Putzlowitsch Test- und SEO-Blog

Ein Bookmarklet für die Google Bildersuche

Neue Version!

Eine neue, erweiterte Version gibt es hier:
Google Bilder-Liste – ei...et für die Google Bildersuche

Bookmarklets

Die 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.

Genau Letzteres war der Anlaß, aß ich mich nun mit Bookmarklets beschäftige. Bisher wußte ich noch nicht mal etwas von deren Existenz.

Ein Bookmarklet für die Google Bildersuche

Bei Facebook fragte David Radicke vor einigen Tagen, ob nicht jemand ein Tool/Addon/Bookmarket kennt, mit welchem man in der Google Bildersuche nur die URLs anzeigen kann.

Daraufhin bekam er eine Lösung programmiert. Dieses Bookmarklet von Chris Ainsworth ist schon eine feine Sache. Es extrahiert aus der Ergebnisseite der Google-Bildersuche die URLs der Bilder und der referenzierenden Seiten und zeigt sie in einer übersichtlichen Tabelle an.

Aber zur Bildersuche gehören irgendwie auch die Bilder. Also habe ich das Javascript etwas angepaßt und erweitert:

  • in der ersten Spalte werden die Thumbnails und die Bildgröße angezeigt
  • das Bookmarklet funktioniert ohne Änderung für alle Google-Länderdomains
  • man kann sich eigene Bilder und ggf. fremde Hotlinks farblich hervorheben lassen

Das Ergebnis sieht dann in etwa so aus:

Google Image Extractor with Thumbnails

Hier findet Ihr das Bookmarklet Version 1.1, welches die Tabelle erzeugt:

Google Img Extractor

Google Image-Extractor Domains-Config

Hier findet Ihr das Bookmarklet, mit welchem ihr die Liste der eigenen Domains befüllen könnt:

Google Img Domains

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.

Dann ruft Ihr die Google-Bildersuche mit dem gewünschten Suchbegriff auf und startet das Bookmarklet durch Anklicken des Lesezeichens (Buttons in der Lesezeichenleiste).

Die Liste der eigenen Domains wird im localStorage gespeichert, der aber nur bei neueren Browsern funktioniert. Zudem müssen Cookies für die Google-Domain erlaubt sein.

Getestet habe ich die Bookmarklets bisher mit Firefox 35.0.1 und Google Chrome 40.0.2214.94, damit funktioniert es.
Die Tests mit anderen Browsern überlasse ich Euch. :-)

4 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.

Keine Kommentare »

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 »

Geschwindigkeit vs. Sichertheit – https bremst Seite aus

Sicher ist sicher

Vor gut einem Monat habe ich meine schnurpsel.de-Website auf https umgestellt. Für das Shared-Webhosting bietet Strato zu einem monatlichen Preis von 2,99 Euro ein einfaches Single-Domain-Zertifikat an, welches ich nun hier auch nutze.

Schnurpsel mit Strato-SSL

Sichtbarer Effekt ist das Schloß-Symbol in der Adressleiste, welches auf eine sichere Verbindung hinweist. Die Übertragung der Daten vom Browser des Nutzers zum Server und umgekehrt ist verschlüsselt. So weit, so gut.

Sicher ist langsamer

Ich habe durchaus erwartet, daß die Seiten etwas langsamer werden, denn die Verschlüsselung benötigt natürlich Rechenzeit. Die ersten Test der auf https umgestellten Domain bestätigten das auch. Die Seiten werden merklich langsamer geladen. Aber wie langsam ist nun dieses Langsam, wenn es sogar merkbar ist?

Hierzu habe ich einen Blick in die Google-Webmastertools geworfen. Dort kann man sich die Ladezeiten für die Seitenabrufe durch den Googlebot ansehen.

Google-Webmastertools: schnurpsel.de mit https

Vor der Umstellung lag die Ladezeit zwischen 0,5 und 1 Sekunde. Das ist sicher kein Spitzenwert, aber durchaus akzeptabel. Nach der Umstellung bewegt sich die Zeit im Bereich von 1,5 bis 2 Sekunden, eine merkliche Verschlechterung.

Die Zeitfresser

Die konkreten Ladezeiten habe ich mir in den Entwicklertools von Chrome angesehen. Die Timeline und die „Resource network timing“ gibt Aufschluß darüber, wie lange etwas beim Aufruf einer Seite dauert.

Da ich keine „Meßwerte“ für schnurpsel.de aus der Zeit vor der https-Umstellung besitze, habe ich die Werte für ein Testblog, auch bei Strato gehostet, als Vergleich herangezogen.

Strato ohne https

Die Timeline für schnurpsel.de sieht so aus:

Die Zeiten für „Blocking“ und „DNS Lookup“ haben nichts mit dem Webserver selbst zu tun und liegen im normalen Rahmen.

Interessant wird es dann beim „Connecting„, der Zeit für den Verbindungsaufbau mit dem Server auf der Netzwerkebene (TCP) und eben auch für die erste SSL-Aushandlung. Die Zeit hat sich von etwa 30 ms ohne SSL auf fast 300 ms mit SSL mal eben verzehnfacht.

Die „SSL„-Zeit gibt es ohne https natürlich nicht. Hier wird die verschlüsselte Verbindung mit dem Schlüsselaustausch, Prüfung des Zertifikates usw. abschließend ausgehandelt. Das schlägt noch einmal mit mindestens 250 ms zu Buche.

Die Zeit für das Senden („Sending“) kann man praktisch vernachlässigen, sie liegt immer im Bereich von wenigen Millisekunden.

Die Wartezeit („Waitung“) ist die Zeit die vergeht, bis nach dem Senden der Anforderung (Request) die Antwort (Response) beim Browser eintrifft. Für WordPress ist es die Zeit, die benötigt wird, um die Seite zu erstellen, also Laden von WordPress, der Plugins und des Themes, Datenbankabfragen, Erzeugen der Ausgabe usw. Die Zeit liegt bei der Schnurpsel-Seite höher als bei der Testseite, weil einfach viel mehr Daten zu verarbeiten sind. Die Testinstallation ist praktisch eine leere WP-Seite.

Zu guter Letzt müssen die Daten vom Server zum Browser übertragen werden, was der „Receiving“-Zeit entspricht. Auch hier dauert es bei Schnurpsel Erwartungsgemäß länger, weil mehr Daten zu übertragen sind.

Langsames SSL bei Strato

Die zusätzliche Zeit von 550 ms (300 ms + 250 ms) paßt ganz gut zu dem, was in den Webmastertools von Google angezeigt wird. Wobei das eher die Untergrenze darstellt, die Verlängerung der Ladezeit durch SSL kann auch höher ausfallen.

Srato mit https (700 ms)

Letztendlich stellt sich mir nun die Frage, was besser oder schlechter ist. Die deutlich merkbar längere Ladezeit spricht gegen https, das mehr an Sicherheit, verbunden mit größerem Vertrauen und „Professionalität“, aber dafür.

Ich werde bei https bleiben und hoffe einfach, daß Strato da irgendwie noch was an der Geschwindigkeit verbesserm kann. Bei anderen Sachen haben sie es ja früher oder stäter auch geschafft. :-)

12 Kommentare »

RaketenSEO-Rankings bei aus.gerech.net als XML und JSON

Raketenseo

Wie schon letztes Mal gibt es auch beim aktuellen SEO-Wettbewerb RaketenSEO die Ranking-Daten von aus.gerech.net im XML- und JSON-Format.

Die URLs lauten:

Der Aufbau ist recht einfach und weitestgehend selbsterklärend. Im Kopf gibt es drei Datenfelder:

  • nam – Name bzw. Suchbegriff (zB. RaketenSEO)
  • upd – Datum und Zeit des letzten Updates der Liste
  • cnt – Anzahl der Google-Suchergebnistreffer (nicht Listeneinträge!)

Es folgt in rnk eine Liste der Suchergebnisse mit folgenden Datenfeldern:

  • pos – Position in den Suchergebnissen
  • url – URL der Seite
  • typ – Typ des Suchergebnisses, mögliche Werte
    • txt – normales Suchergebnis
    • new – Google-News
    • img – Universal Search Bilder
    • vid – Video
  • img – URL des Bildes, wenn Typ img ist (optional)
  • aut – Name des Autors, falls verfügbar (optional)
  • lpo – letzte Position, 1000 falls neu in der Liste

Bei der Position für Universal-Search Ergebnisse wird eine Unternummerierung vorgenommen. Das erste Ergebnis bekommt .1, das zweite .2, das dritte .3 usw. an die eigentliche Position angehängt. Befinden sich zum Beispiel vier Bilder an der Position 13, so erhalten sie die Positionen 13.1, 13.2, 13.3 und 13.4 in pos zugeordnet.

Die Daten werden stündlich zu vollen Stunde erhoben. Es dauert aber ein paar Minuten, bis sie dann tatsächlich vorliegen. Also sollten die Daten ein paar Minuten nach der vollen Stunde abgefragt werden. Den aktuellen Zeitpunkt der Daten sieht man ja in den Kopfdaten.

Das Top-10 Diagramm im PNG-Format liegt auch zu diesem Zeitpunkt vor. Es gibt ein 24-Stunden-Diagramm und ein 3-Wochen-Diagramm:

Und morgen zeige ich dann, wie ich mit einem WordPress-Plugin das Ranking von aus.gerech.net hier bei Schnurpsel einbinde. :-)

Weitere Artikel mit Bezug zu diesem:
2 Kommentare »