Webmaster-Zentrale Blog
Offizielle Informationen zum Crawling und zur Indexierung von Webseiten und News für Webmaster
Die richtige Startseite für internationale Nutzer erstellen
Montag, 16. Juni 2014
Wenn euer Unternehmen in mehreren Ländern tätig oder auf verschiedene Sprachen ausgerichtet ist, empfehlen wir, für die auf einzelne Länder oder Sprachen ausgerichteten URLs separate Websites oder Abschnitte mit spezifischen Inhalten einzurichten. Ihr könnt zum Beispiel eine Seite für die USA und Englisch sprechende Besucher und eine andere Seite für Frankreich und Französisch sprechende Nutzer anbieten. Ihr findet bei uns Informationen zum Umgang mit
internationalen und mehrsprachigen Websites
, auf der Startseite sind jedoch ganz besondere Aspekte zu beachten. Dieser Blogpost enthält Tipps zur Erstellung der richtigen Startseite auf eurer Website, sodass ihr je nach Sprache und Standort der Nutzer die passenden Inhalte schalten könnt.
Es gibt drei Möglichkeiten zur Konfiguration der Start- oder Zielseite, die den Nutzern beim Aufrufen der Seite angezeigt wird:
Alle Nutzer sehen die gleichen Inhalte.
Die Nutzer können selbst wählen.
Inhalte werden abhängig vom Standort und von der Sprache der Nutzer geschaltet.
Sehen wir uns die einzelnen Möglichkeiten genauer an.
Die gleichen Inhalte für alle Nutzer weltweit schalten
In diesem Szenario schaltet ihr auf eurer Startseite bzw. unter eurer generischen URL, beispielsweise
http://www.ihremusterdomain.
de
, spezifische Inhalte für ein bestimmtes Land und eine bestimmte Sprache. Diese Inhalte sind für jeden verfügbar, der diese URL in seinem Browser direkt aufruft oder nach dieser spezifischen URL sucht. Wie bereits erwähnt, sollten alle verschiedenen Landes- und Sprachversionen auch über eine eigene eindeutige URL zugänglich sein.
Hinweis:
Ihr könnt auf eurer Seite ein Banner einblenden, um Nutzern an anderen Standorten oder mit anderen Spracheinstellungen eine passendere Version vorzuschlagen.
Nutzer die gewünschte lokale Version und Sprache selbst wählen lassen
Bei dieser Konfiguration schaltet ihr auf eurer Startseite bzw. unter eurer generischen URL eine Seite zur Länderauswahl. So können die Nutzer selbst entscheiden, welche Inhalte sie abhängig von Land und Sprache sehen möchten. Alle Nutzer, die diese URL eingeben, rufen dieselbe Seite auf. Wenn ihr dieses Szenario auf eurer internationalen Website implementiert, vergesst nicht, für die Länderauswahlseite die Anmerkung
x-default rel-alternate-hreflang
zu verwenden, die speziell auf diese Art von Seiten ausgerichtet ist. Anhand des Werts "x-default" können wir Seiten erkennen, die nicht für eine bestimmte Sprache oder Region spezifisch sind.
Nutzer automatisch weiterleiten oder dynamisch die passenden HTML-Inhalte abhängig von den Standort- und Spracheinstellungen der Nutzer schalten
Im dritten Szenario werden automatisch die passenden HTML-Inhalte für eure Nutzer je nach deren Standort- und Spracheinstellungen geschaltet. Dies geschieht entweder über eine serverseitige 302-Weiterleitung oder durch die dynamische Schaltung der richtigen HTML-Inhalte. Vergesst nicht, die Anmerkung "x-default rel-alternate-hreflang" auf der Startseite bzw. generischen Seite einzufügen, auch wenn es sich bei der generischen Seite um eine Weiterleitungsseite handelt, die nicht von Nutzern direkt aufgerufen werden kann. Hinweis: Nutzer, für die keine passende Version verfügbar ist, sollten am besten weitergeleitet werden. Wenn beispielsweise Französisch sprechende Nutzer eine Website aufrufen, für die es nur eine englische, spanische und chinesische Version gibt, könnt ihr für diese Nutzer die Inhalte schalten, die euch am geeignetsten erscheinen. Für welche Konfiguration ihr euch auch entscheidet – achtet darauf, dass alle Seiten, einschließlich der Seiten zur Auswahl des Landes und der Sprache, folgende Kriterien erfüllen:
Sie müssen die
Anmerkung "rel-alternate-hreflang"
enthalten.
Sie müssen für das Crawling und die Indexierung durch den Googlebot zugänglich sein. Blockiert also das Crawling und die Indexierung eurer lokalisierten Seiten nicht.
Sie müssen Nutzern ermöglichen, die lokale Version oder Sprache zu wechseln. Dies kann beispielsweise über ein Drop-down-Menü geschehen.
Erinnerung:
Wie bereits erwähnt, müssen für die einzelnen Landes- und Sprachversionen separate URLs vorliegen.
Hinweise zur Anmerkung "rel-alternate-hreflang"
Unabhängig davon, für welche Vorgehensweise ihr euch entscheidet – eure Seiten sollten Anmerkungen enthalten. Dies hilft Suchmaschinen, die richtigen Ergebnisse für eureNutzer anzuzeigen.
Bei Länderauswahlseiten und bei der Weiterleitung oder dynamischen Schaltung von Startseiten sollte die Anmerkung
x-default hreflang
verwendet werden, die speziell für Startseiten mit automatischer Weiterleitung und Länderauswahlseiten konzipiert wurde.
Hier noch ein paar allgemeine Tipps zur Anmerkung "rel-alternate-hreflang":
Eure Anmerkungen müssen von den anderen Seiten bestätigt werden. Wenn Seite A auf Seite B verweist, muss Seite B zurück auf Seite A verweisen. Andernfalls werden eure Anmerkungen möglicherweise nicht richtig interpretiert.
Eure Anmerkungen sollten auf sich selbst verweisen. Seite A sollte mit der Anmerkung "rel-alternate-hreflang" versehen sein, die auf sich selbst verweist.
Ihr könnt die Anmerkung "rel-alternate-hreflang" im HTTP-Header, im Kopfteil der HTML-Datei oder in einer Sitemap-Datei angeben. Beschränkt euch auf eine einheitliche Vorgehensweise zur Implementierung der Anmerkungen, um widersprüchliche Signale und Fehler zu vermeiden.
Der Wert des Attributs "hreflang" muss für die Sprache im Format
ISO 639-1
und für die Region im Format
ISO 3166-1 Alpha 2
vorliegen. Die Festlegung nur der Region wird nicht unterstützt. Wenn ihr eure Website nur für ein Land konfigurieren möchtet, nutzt die geografische Ausrichtung in den
Webmaster-Tools
.
Wenn ihr euch an diese Empfehlungen haltet, können wir eure lokalisierten Inhalte besser verstehen und den Nutzern so relevantere Suchergebnisse anzeigen. Fragen oder Feedback könnt ihr wie immer gerne im
Forum für Webmaster
posten.
Post von
Zineb Ait Bahajji
und
Gary Illyes
, Webmaster Trends Analysts
(Veröffentlicht von
Johannes Mehlem
, Search Quality Team)
Start der #NoHacked-Kampagne für sichere Websites
Montag, 9. Juni 2014
Unsere
#NoHacked
-Kampagne möchte euch aufmerksam für Hacking-Attacken machen und Tipps anbieten, wie ihr eure Websites sicher vor Angriffen haltet. Obwohl wir wünschten, dass dies niemandem passiert, ist es doch überraschend häufig für Websites - inklusive eurer :( - dass sie ausgenutzt werden.
Im Laufe dieser Woche werden wir täglich einen Tipp zur Vorbeugung von Hacking mit euch über
Google+
,
Twitter
und
Facebook
teilen.
Der spaßige Teil kommt hier: Ihr seid eingeladen, mitzumachen! Teilt eure besten Tipps zur Vorbeugung von Hacking mit dem Hashtag #NoHacked auf der Plattform eurer Wahl: Google+, Twitter und Facebook. Wir werden die besten Tipps am Ende der Woche teilen.
Viel Spaß beim Posten und nicht #NoHacked vergessen ;)!
Post von
Johannes Mehlem
(Search Quality Team)
Tipps zum Verschieben von Websites
Freitag, 6. Juni 2014
Es gibt nur wenige Themen, die bei Webmastern zu größerem Kopfzerbrechen oder mehr Verwirrung führen als das Verschieben von Websites. Damit euch keine unangenehmen Überraschungen erwarten, haben wir einen detaillierten Leitfaden zusammengestellt, in dem beschrieben wird, wie ihr eure Website auf Googlebot-freundliche Weise verschieben könnt. Aber was bedeutet eigentlich "eine Website verschieben" und wie geht ihr dabei am besten vor?
Beispiel der Adressänderungsfunktion in Webmaster-Tools unter den allgemeinen Seitenkonfigurationen ("Zahnrad")
Grundlegendes
Als Website-Verschiebung werden im Allgemeinen zwei Arten der Inhaltsmigration bezeichnet:
Verschieben einer Website ohne URL-Änderungen:
Es wird nur die zugrunde liegende Infrastruktur einer Website geändert, an der URL-Struktur sind keine Änderungen erkennbar. Beispiel: Ihr verschiebt www.ihremusterdomain.de zu einem anderen Hostinganbieter, behaltet aber die URLs und die Websitestruktur wie unter www.ihremusterdomain.de bei.
Verschieben einer Website mit URL-Änderungen:
In diesem Fall können sich beliebige Teile der Website-URLs ändern:
Das Protokoll:
http://www.ihremusterdomain.de
zu
https://www.ihremusterdomain.de
Der Domainname: ihremusterdomain.de zu ihremusterdomain.net
Die URL-Pfade: http://ihremusterdomain.de/page.php?id=1 zu
http://ihremusterdomain.de/widget
Uns sind einige Fälle bekannt, in denen Webmaster ihre Websites nicht korrekt verschoben haben oder bestimmte Schritte ausgelassen haben, mit denen sich einige Fehler vermutlich hätten vermeiden lassen. Um Webmaster bei der Planung und Durchführung der Website-Verschiebung zu unterstützen, haben wir den
Leitfaden zur Verschiebung von Websites in der Hilfe für Webmaster aktualisiert
. Gleichzeitig verbessern wir auch weiterhin unsere Crawling- und Indexierungssysteme, um Website-Verschiebungen zu erkennen und zu verarbeiten, sofern ihr euch an den Leitfaden haltet.
Wechsel zum Responsive Webdesign
Immer häufiger wird auch die Frage gestellt, wie Webmaster von einer Website mit separaten URLs für Mobilgeräte oder dynamischer Anpassung zum Responsive Webdesign wechseln können. Weitere Informationen zu dieser Konfigurationsänderung findet ihr auf der
neuen Seite der Website unserer Smartphone-Empfehlungen
.
Fragen könnt ihr wie immer gerne in unseren
Foren für Webmaster
posten.
Post von
Pierre Far
und
Zineb Ait Bahajji
, Webmaster Trends Analysts
(Veröffentlicht von
Johannes Mehlem
, Search Quality Team)
App-Indexierung jetzt in weiteren Sprachen
Mittwoch, 4. Juni 2014
Im April haben wir die App-Indexierung
weltweit auf Englisch
eingeführt, mit der Tiefenlinks zu euren mobilen Apps in den Google-Suchergebnissen auf Android-Geräten angezeigt werden können. Heute fügen wir die ersten Anbieter von Inhalten in anderen Sprachen hinzu: Fairfax Domain, MercadoLibre, Letras.mus.br, Vagalume, Idealo, L'Equipe, Player.fm, Upcoming, Au Feminin, Marmiton und Chip.de. In den Vereinigten Staaten werden nun auch die Apps von Walmart, Tapatalk und Fancy unterstützt.
Außerdem stehen unsere
Richtlinien für Entwickler
jetzt in acht zusätzlichen Sprachen zur Verfügung:
Chinesisch (Traditionell)
,
Französisch
,
Deutsch
,
Italienisch
,
Japanisch
,
Portugiesisch (Brasilien)
,
Russisch
und
Spanisch
.
Wenn ihr Interesse an der App-Indexierung habt und eure Inhalte fertig implementiert sind,
füllt bitte dieses Formular aus
. Fragen könnt ihr wie immer gerne
im Forum für Webmaster
posten.
Falls ihr im Juni an der Google I/O teilnehmt, lasst euch den Vortrag
Future of Apps and Search
nicht entgehen. Dort stellen wir einige Aktualisierungen der App-Indexierung vor.
Post von Erik Hendriks, Software Engineer
(Veröffentlicht von
Johannes Mehlem
, Search Quality Team)
Seiten mit "Abruf wie durch Google" rendern
Dienstag, 27. Mai 2014
Über die
Funktion "Abruf wie durch Google" in den Webmaster-Tools
können Webmaster nachvollziehen, wie der Googlebot ihre Seiten abruft. Die Serverheader und der HTML-Code, die angezeigt werden, helfen bei der Diagnose von technischen Problemen und Nebeneffekten von Hackerangriffen. Manchmal erschweren sie aber auch das Überprüfen der Antwort:
Hilfe!
Was bedeutet all dieser Code?
Ist das wirklich dieselbe Seite, die ich in meinem Browser sehe?
Wo wollen wir Mittag essen?
Bei der letzten Frage können wir zwar nicht helfen, aber für die übrigen haben wir dieses Tool kürzlich so erweitert, dass ihr sehen könnt, wie der Googlebot die Seite rendern würde.
Gerenderte Seite ansehen
Zum Rendern der Seite sucht der Googlebot nach allen zugehörigen externen Dateien und versucht, sie ebenfalls abzurufen. Bei diesen Dateien handelt es sich oft um Bilder, CSS- und JavaScript-Dateien sowie sonstige Dateien, die indirekt über den CSS- oder JavaScript-Code eingebettet sein können. Anschließend wird mit ihrer Hilfe ein Vorschaubild gerendert, das die Sicht des Googlebots auf die Seite wiedergibt.
Ihr findet die
Funktion "Abruf wie durch Google"
im Abschnitt "Crawling" der
Google Webmaster-Tools
. Wartet nach dem Senden einer URL mittels "Abrufen und rendern" auf deren Verarbeitung. Dies kann bei manchen Seiten einen Moment dauern. Sobald die Seite verarbeitet wurde, klickt ihr auf die Antwortzeile, um euch die Ergebnisse anzusehen.
Umgang mit von robots.txt blockierten Ressourcen
Der Googlebot richtet sich bei allen Dateien, die er abruft, nach den
Anweisungen in der robots.txt-Datei
. Wenn ihr das Crawling einiger dieser Dateien nicht gestattet oder wenn sie über einen Server eines Drittanbieters eingebettet werden, der das Crawling durch den Googlebot unterbindet, können wir euch die Dateien nicht in der gerenderten Ansicht zeigen. Wir können sie ebenfalls nicht verwenden, wenn der Server nicht antwortet oder Fehler zurückgibt. Solche Probleme sind in den Webmaster-Tools im Abschnitt
Crawling-Fehler
aufgeführt. Wenn wir auf eines dieser Probleme stoßen, weisen wir unterhalb des Vorschaubilds darauf hin.
Wir empfehlen euch daher, dafür zu sorgen, dass der Googlebot auf alle eingebetteten Ressourcen zugreifen kann, die für die sichtbaren Inhalte oder das Layout eurer Website wichtig sind. Zum einen erleichtert euch das die Verwendung von "Abruf wie durch Google", zum anderen kann der Googlebot dann diese Inhalte finden und indexieren. Einige Inhaltstypen – z. B. Schaltflächen sozialer Medien, Schriftarten oder Skripts zur Websiteanalyse – sind für die sichtbaren Inhalte oder das Layout oft weniger bedeutsam und ihr Crawling kann daher weiterhin untersagt bleiben. Weitere Informationen findet ihr im vorherigen Blogpost zum
neuen Verfahren von Google zur besseren Analyse des Webs
.
Wir hoffen, dass euch dieses Update die Diagnose solcher Probleme erleichtert und bei der Erkennung von Inhalten hilft, deren Crawling versehentlich blockiert wurde. Wenn ihr Kommentare oder Fragen habt, könnt ihr diese hier oder im
Forum für Webmaster
posten.
Post von Shimi Salant, Webmaster Tools team
(Veröffentlicht von
Johannes Mehlem
, Search Quality Team)
Bessere Analyse von Webseiten
Freitag, 23. Mai 2014
Im Jahr
1998
standen unsere Server noch in
Susan Wojcickis
Garage und wir machten uns keine großen Gedanken über JavaScript oder CSS. Beide wurden kaum verwendet bzw. JavaScript wurde damals genutzt, um Seitenelemente blinken zu lassen! Seither hat sich viel verändert. Im Web gibt es zahlreiche komplexe, dynamische Websites, die JavaScript in großem Umfang einsetzen. In diesem Blogpost erläutern wir unser Verfahren zum Rendern umfangreicherer Websites, d. h., wir rufen eure Inhalte jetzt mehr wie moderne Webbrowser ab, einschließlich externer Ressourcen, führen JavaScript aus und wenden CSS an.
Ursprünglich haben wir uns nur die reinen Textinhalte angesehen, die wir in HTTP-Antworten erhielten, und haben nicht analysiert, was ein typischer Browser abrufen würde, der JavaScript ausführt. Als es dann immer mehr Seiten gab, auf denen wertvolle Inhalte mit JavaScript gerendert wurden, konnten wir diese den suchenden Nutzern nicht anzeigen. Das war sowohl für die Suchenden als auch für die jeweiligen Webmaster ein Nachteil.
Um dieses Problem zu beheben, beschlossen wir, auszuprobieren, ob die Analyse der Seiten durch das Ausführen von JavaScript möglich sei. Dieses Vorgehen ist beim aktuellen Umfang des Webs recht schwierig, aber wir waren der Ansicht, dass es einen Versuch wert sei. Wir haben dieses Verfahren im Laufe der Zeit schrittweise verbessert. In den letzten Monaten hat unser Indexierungssystem eine große Anzahl an Webseiten beinahe wie einnormaler Nutzer gerendert, der einen Browser mit aktiviertem JavaScript verwendet.
Manche Abläufe beim Rendern sind nicht perfekt und können die Suchergebnisse für eure Websites beeinträchtigen. Im Folgenden findet ihr einige potenzielle Probleme und – sofern verfügbar – auch Vorschläge, wie ihr diese verhindern könnt:
Wenn Ressourcen wie JavaScript oder CSS in separaten Dateien blockiert werden, z. B. in robots.txt, damit der Googlebot sie nicht abrufen kann, kann unser Indexierungssystem eure Websites nicht wie ein normaler Nutzer abrufen. Wir empfehlen daher, dem Googlebot das Abrufen von JavaScript und CSS zu gestatten, damit eure Inhalte besser indexiert werden. Das ist insbesondere bei mobilen Websites wichtig, bei denen externe Ressourcen wie CSS und JavaScript unseren Algorithmen anzeigen, dass die Seiten
für Mobilgeräte optimiert
sind.
Sollte euer Webserver die hohe Anzahl von Crawling-Anfragen für Ressourcen nicht verarbeiten können, werden eure Seiten von uns möglicherweise nicht korrekt gerendert. Um sicherzustellen, dass eure Seiten von Google gerendert werden können, müssen eure Server die Crawling-Anfragen für Ressourcen verarbeiten können.
Idealerweise sollte eure Website auch auf Fehler und unerwartet auftretende Ereignisse angemessen reagieren (Graceful Degradation). Dadurch können Nutzer auf eure Inhalte auch dann zugreifen, wenn sie in ihren Browsern keine kompatiblen JavaScript-Implementierungen verwenden. Dieses Vorgehen hilft auch Websitebesuchern, die JavaScript deaktiviert haben, und Suchmaschinen, die noch kein JavaScript ausführen können.
In einigen Fällen ist JavaScript unter Umständen zu komplex, sodass wir die Seite nicht vollständig und korrekt rendern können.
Manche JavaScript-Implementierungen entfernen Inhalte von der Seite, statt sie hinzuzufügen, weshalb wir diese Inhalte dann nicht indexieren können.
Um das Debugging zu vereinfachen, entwickeln wir momentan ein Tool, das Webmastern ein besseres Verständnis vermitteln soll, wie Google ihre Websites rendert. Es sollte in den nächsten Tagen
in den Webmaster-Tools verfügbar
sein. Antworten auf Fragen findet ihr in unserem
Forum für Webmaster
.
Post von Michael Xu, Software Engineer, und Kazushi Nagayama, Webmaster Trends Analyst
(Veröffentlicht von
Johannes Mehlem
, Search Quality Team)
Websites mit PageSpeed Insights für Mobilgeräte optimieren
Montag, 19. Mai 2014
Wir möchten Entwicklern und Webmastern helfen, ihre Seiten für Mobilgeräte zu optimieren. Deshalb haben wir PageSpeed Insights kürzlich aktualisiert und zusätzliche Empfehlungen für eine bessere Benutzerfreundlichkeit auf Mobilgeräten hinzugefügt.
Wenn die Benutzerfreundlichkeit zu wünschen übrig lässt, kann dies die Vorteile einer schnell ladbaren Seite schmälern. Wir wissen, dass eine mobile Seite
eine durchschnittliche Ladezeit von mehr als sieben Sekunden erfordert
(in Englisch). Mit dem
PageSpeed Insights-Tool
und den entsprechenden Empfehlungen zur Geschwindigkeit kann eure Seite
wesentlich schneller geladen werden
(in Englisch). Nehmen wir jedoch einmal an, dass eure mobile Website keine sieben, sondern nur drei Sekunden Ladezeit erfordert. Wenn die Nutzer danach trotzdem noch fünf Sekunden lang den Text vergrößern und nach oben oder unten scrollen müssen, bevor sie ihn lesen und die Seite richtig benutzen können, empfinden sie die Website als nicht benutzerfreundlich. Mit den neuen Regeln für die Nutzererfahrung von PageSpeed Insights könnt ihr diese Probleme erkennen und beseitigen. Unsere neuen Empfehlungen beziehen sich auf die folgenden Bereiche:
Darstellungsbereich konfigurieren: Wenn eure Seite kein Meta-Tag für den Darstellungsbereich enthält, erkennen moderne Browser auf Mobilgeräten sie nicht als für Mobilgeräte optimiert und zeigen die Desktopversion an, möglicherweise mit Vergrößerung der Schrift, was zu Layoutproblemen führt.
Legt den Darstellungsbereich so fest,
dass die Seitenbreite der Breite des mobilen Displays entspricht. Dies ist der erste Schritt, um eure Website für die Anzeige auf Mobilgeräten zu optimieren.
Inhalte an den Darstellungsbereich anpassen: Nutzer sind es gewohnt, auf mobilen Websites nicht horizontal, sondern vertikal zu scrollen. Nach der Konfiguration des Darstellungsbereichs solltet ihr sicherstellen, dass die Seiteninhalte
auf die Breite des Darstellungsbereichs ausgerichtet sind
. Beachtet dabei, dass nicht alle Mobilgeräte gleich breit sind.
Gut lesbare Schriftgrößen verwenden: Wenn Nutzer heranzoomen müssen, um den Text eines Artikels auf dem Smartphone zu lesen, ist eure Website nicht für Mobilgeräte optimiert. PageSpeed Insights überprüft, ob der Text auf eurer Website
groß genug ist,
sodass ihn die meisten Nutzer bequem lesen können.
Tipp-Ziele ausreichend groß darstellen: Nutzer sind schnell frustriert, wenn sie auf einem Mobiltelefon oder Tablet versehentlich auf die falsche Schaltfläche oder den falschen Link tippen, weil ihre Fingerspitze größer ist als der Mauscursor bei einem Desktopcomputer. Achtet deshalb darauf, dass die
Tipp-Ziele auf dem Touchscreen groß genug sind,
damit Nutzer der mobilen Website sie problemlos berühren können.
Plug-ins vermeiden: Die meisten Smartphones unterstützen Flash oder andere Browser-Plug-ins nicht. Für eure mobile Website sollten daher
keine Plug-ins erforderlich sein
.
Weitere Informationen zu diesen Regeln findet ihr in
unserer Hilfe
. Mit dem
PageSpeed Insights-Tool
könnt ihr eure Seiten und die entsprechenden Verbesserungen abschließend testen. Das Design von PageSpeed Insights ist jetzt auch für Mobilgeräte optimiert. Darüber hinaus stehen die Hilfedokumente in weiteren Sprachen zur Verfügung.
Fragen und Feedback könnt ihr wie gewohnt in unserer
Diskussionsgruppe
(in Englisch) posten.
Post von Matthew Steele und Doantam Phan, PageSpeed Insights team
(Veröffentlicht von
Johannes Mehlem
, Search Quality Team)
Labels
#NoHacked
2
2017
1
Accessibility
13
AJAX
1
AMP
7
Android
2
api
1
App-Indexierung
3
Best Practices
99
Bildersuche
2
captcha
1
Chrome
4
Code
12
Crawling
1
Crawling und Indexierung
126
Diskussionsforum
15
Duplicate Content
17
Dynamic Rendering
1
Einsteiger
8
Event
1
events
1
Feedback
1
Geo-Targeting
11
Google Analytics
6
Google Dance
1
Google News
1
Google Places
4
Google-Assistant
1
Google-Suche
59
Google+
9
Hacking
16
Hangouts
1
https
3
JavaScript
3
Kanonische URL
1
Kommentare
1
Konferenz
19
Lighthouse
3
Links
18
Malware
17
Mobile
38
Mobile-first indexing
1
Nachrichten-Center
16
Optimisation
3
PageSpeed Insights
2
Penalties
1
Performance
3
Ranking
1
reCaptcha v3
1
Rendering
2
Rich Snippets
18
Richtlinien für Webmaster
36
robots.txt
7
Safe Browsing
5
Search Console
19
Search Results
1
Security
4
Seitenzugriff
1
SEO
4
Sicherheit
38
Site Clinic
5
Sitemaps
30
Spam Report
9
SSL
1
Structured Data
8
Tools und Gadgets
17
Verschlüsselung
1
Video
132
Webmaster blog
1
Webmaster Community
1
Webmaster-Academy
1
Webmaster-Tools
154
webspam
3
Archiv
2020
Nov.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
2019
Dez.
Nov.
Okt.
Sept.
Juni
Mai
Feb.
Jan.
2018
Dez.
Nov.
Okt.
Sept.
Juli
Juni
Mai
Apr.
Feb.
Jan.
2017
Dez.
Nov.
Juni
Apr.
März
Jan.
2016
Nov.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Jan.
2015
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Mai
Apr.
März
Feb.
Jan.
2014
Nov.
Okt.
Sept.
Aug.
Juni
Mai
Apr.
März
Feb.
Jan.
2013
Dez.
Nov.
Okt.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2012
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2011
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2010
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2009
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2008
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2007
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feed
Forum für Webmaster
Webmaster-Sprechstunden
Webmaster-Tools-Hilfe
Developers-Site für Webmaster