Google verwendet Nutzerdaten aus dem Chrome User Experience Report, um die Ladezeit von Webseiten zu messen. Auch andere Daten aus dem Report werden ausgewertet und können sich auf die Rankings auswirken. Webmaster sollten sich daher zukünftig noch mehr auf die Nutzererfahrung konzentrieren.

Wenn eine Seite öfter der HTTP-Status 304 zurückliefert und damit anzeigt, dass sich seit dem letzten Besuch nichts geändert hat, wirkt sich dies nicht auf Googles Crawlingrate für die betreffende Seite aus.

Das Setzen eines iFrames im Head des HTML-Codes kann laut Google dazu führen, dass vorhandene Meta-Daten nicht geparst werden.

Google kann beim Crawlen von Webseiten keine Custom CSS-Properties erkennen. Der Grund dafür liegt in der Browser-Engine, die Google zum Rendern der Seiten verwendet.

Wenn auf einer Seite das "noindex"-Attribut per JavaScript entfernt wird, behandelt Google die Seite dennoch so, als gebe es dort ein "noindex".

Strukturierte Daten im JSON-LD-Format, die per JavaScript gesetzt werden, können von Google ausgelesen werden. Um zu testen, ob Google die Daten auch tatsächlich erkennt, sollte aber das Rich Media Testing-Tool verwendet werden.

Durch die wachsende Verbreitung von Single Page Applications (SPA) stellt sich immer wieder die Frage, wie Google mit den Inhalten solcher Seiten umgeht. Eine interessante Frage dazu ergab sich gerade im Zusammenhang mit Angular Universal.

Google treibt die Umstellung möglichst vieler Webseiten auf HTTPS voran. Per Twitter hat eine Google-Mitarbeiterin vier der wichtigsten Gründe dafür genannt.

Für Google spielt es laut eigener Aussage in der Suche keine Rolle, ob die Auflösung einer Domain per DNSSEC abgesichert wird.

Für unverschlüsselte Webseiten ohne HTTPS wird die Luft immer dünner: Googles Chrome-Browser wird ab Juli solche Seiten generell als unsicher kennzeichnen.

Der Einsatz des Vary-HTTP-Headers zum Hinweis auf unterschiedliche Seiten für Mobilgeräte und den Desktop sollte nur dort erfolgen, wo es auch technisch begründet und sinnvoll ist. Darauf hat Google kürzlich hingewiesen.

Bei der Bewertung der Ladezeit einer Webseite (Page Speed) sollte man zwischen den Besuchern einerseits sowie dem Crawlen und Indexieren andereseits trennen. Darauf hat Google in einem Webmaster-Hangout hingewiesen.

Eine neue Studie zeigt in deutlicher Weise den Zusammenhang zwischen der Ladezeit von Webseiten und der Bounce Rate. Obwohl die durchschnittliche Dateigröße der Seiten in den letzten Jahren stark gewachsen ist, laden die Seiten im Durchschnitt recht schnell.

Google hat heute das "Speed-Update" angekündigt: Ab Juli wird die Ladezeit Rankingfaktor in der mobilen Suche. Betroffen sind laut Google nur besonders langsame Seiten.

Google wird Webseiten keine Sonderbehandlung zukommen lassen, die wegen der Patches gegen die aktuellen CPU-Sicherheitslücken und gegen die mit Meltdown und Spectre gekennzeichneten Angriffe langsamer geworden sind. Die Nutzer interessiere es schließlich nicht, warum eine Webseite langsam sei.

Die Download-Zeit einer Webseite stellt einen wichtigen Faktor der Webseitengeschwindigkeit dar. Wenn das Herunterladen der Dateien einer Seite zu lange dauert, kann sich das negativ auf die Crawling-Rate auswirken.

Die aktuelle Sicherheitslücke, die in vielen der aktuell verwendeten CPUs besteht, könnte sich auch auf die Performance von Webseiten auswirken. Was müssen Webmaster und SEOs beachten?

307-Redirects stellen eine besondere Form der Weiterleitung dar. Anders als gewöhnliche 301- oder 302-Redirects können sie nicht nur vom Server, sondern auch vom Browser durchgeführt werden. Wie geht Google damit um?

Eine Webseite sollte laut Google einen 404-Fehler senden, wenn eine ungültige URL aufgerufen wird. Nicht zu empfehlen sind dagegen 500er-Fehler, die auf Probleme des Servers hinweisen.

Google hat klargestellt, dass Progressive Web Apps (PWAs) keinerlei Rankingvorteile in den Suchergebnissen genießen. Dazu kommt, dass für Google das Crawlen und Rendern solcher Seiten noch anspruchsvoller ist als bei normalen HTML-Seiten.