Meine Präsentation vom SEOday 2015 in Köln zum Thema Crawl-Budget und Crawl-Rate-Optimierung mit vielen Tipps zur Verbesserung von Auffindbarkeit, Indexierung, Geschwindigkeit sowie den "häufigsten Stolpersteinen" bei der Optimierung.
3. Die Ziele für Crawl-Budget & Crawl-Rate
Optimierung?
1. Ein möglichst vollständiger Crawl der Domain in akzeptabler Zeit
4. Die Ziele für Crawl-Budget & Crawl-Rate
Optimierung?
1. Ein möglichst vollständiger Crawl der Domain in akzeptabler Zeit
2. Schnelles Bemerken von Änderungen an bestehenden Inhalten und
damit möglichst zeitnahes Aktualisieren der jeweiligen Inhalte im Index
5. Die Ziele für Crawl-Budget & Crawl-Rate
Optimierung?
1. Ein möglichst vollständiger Crawl der Domain in akzeptabler Zeit
2. Schnelles Bemerken von Änderungen an bestehenden Inhalten und
damit möglichst zeitnahes Aktualisieren der jeweiligen Inhalte im Index
3. Schnelles Auffinden von neuen Inhalten / URLs auf einer Domain, so
dass selbige schnellstmöglich auch via Google auffindbar sind
6. Die Ziele für Crawl-Budget & Crawl-Rate
Optimierung?
1. Ein möglichst vollständiger Crawl der Domain in akzeptabler Zeit
2. Schnelles Bemerken von Änderungen an bestehenden Inhalten und
damit möglichst zeitnahes Aktualisieren der jeweiligen Inhalte im Index
3. Schnelles Auffinden von neuen Inhalten / URLs auf einer Domain, so
dass selbige schnellstmöglich auch via Google auffindbar sind
4. Schonender bzw. effizienter Umgang mit Ressourcen im Crawl-Prozess
(Serverinfrastruktur sowie Traffic)
10. PageRank als Crawling Faktor
„Interner“ PR als Priorisierung für den Crawling-Prozess
• Keine wirklich ein-
sehbare Zahl
• Zugeteilt pro Hostname
sowie pro Subdomain
• Interner PageRank !=
Toolbar PageRank
12. „Die Crawl-Rate definiert die Anzahl an
Crawl-Anfragen (Zugriffen) durch den
Crawler einer Suchmaschine (Google) in
einem bestimmten Zeitraum (bspw. 24h)
auf eine Domain (oder ein Verzeichnis).“
13. Ausgangspunkt: Google Search Console
Was will Google? Jeden Tag möglichst viele,
relevante URLs extrem schnell herunterladen!
http://g.co/searchconsole
15. Sie haben ihr CMS “ausgetauscht”!
(ME DURING THE CONFERENCE CALL…)
16. Nutze die Anzahl der Links und die Linktiefe
um den Crawler zu kontrollieren
#1 Die richtige Architektur
17. Das Wichtigste? Die Startseite!
Idealerweise sind alle Inhalte max. 3-5 Klicks entfernt!
1.
2.
3.
18. Priorisiere URLs anhand von Suchvolumen
Homepage > Kategorien > … > Detail-Seiten
Wer “speziell” sucht, erwartet keine generischen LPs!
Mehr zum Thema Keywordrecherche: http://bg.vu/sesldn14
19. Lesbarkeit der Links sicherstellen
Einfach zu testen: JavaScript und CSS deaktivieren
http://chrispederick.com/work/web-developer/ & http://www.feedthebot.com/spiderview.html
webcache.googleusercontent.com/search?q=cache:www.domain.com&strip=1
20. Für eigene Domains: Fetch & Render
Google’s Search Console: Lesbarkeit prüfen und
Darstellungen vergleichen (CSS & JS freigeben)
21. Es geht Google nur um eines: Effizienz!
Ein Maximum an einzigartigen Seiten, (fast) keine
Duplikate, alle Inhalte crawlbar, etc.
http://pa.ag/deep-crawl
22. Tiefe des Craw-Prozesses überwachen!
Kalender können bspw. „unendliche“ URLs erzeugen!
Gut optimiert
(Gleichmäßige Verteilung
über Ebene 1-5, die
wichtigsten Seite „nahe“
der Startseite)
Schwierig
Alle Inhalte auf einer Ebene
bzw. extrem viele Inhalte
auf Ebene 6 – 14…
23. Sicherstellen, dass jede Unterseite den
bestmöglichen, internen Link bekommt.
#2 Die “richtigen” Links
27. Sowie semantisch passende Verlinkungen:
Einen Schuh mit “passendem” Outfit zu verbinden ist
jedoch nicht immer ganz einfach! Richtig, liebe Damen?
Leicht
Schwierig
36. Prüfe sorgfältig, welche Seiten du in den Index lässt und
noch viel wichtiger, wie du es machst!
#3 Crawler Control
37. Meta Tags im Browser anzeigen:
SeeRobots Plug-in für Chrome & Firefox
http://www.seerobots.com/
38. Meta Robots Tag vs. robots.txt
<meta name="robots" content="noindex, follow" />
• Seiten werden gecrawlt
• Seiten werden nicht indexiert
• Seiten werden nicht in den Suchergebnissen angezeigt
User-Agent:*
Disallow: /seite.html
• Seiten werden nicht gecrawlt
• URLs werden “teilweise” indexiert
• URLs werden “teilweise” in den Suchergebnissen angezeigt
Was sind die wichtigsten Unterschiede?
40. Beides gleichzeitig hilft auch nicht!
Google kann Robots Meta Tags nicht lesen, wenn das
URL-Pattern via robots.txt gesperrt ist!
41. Wie macht man es richtig?
Für die Praxis gilt:
• Das Robots Meta Tag ist im täglichen Gebrauch für HTMLs eigentlich immer die
bessere Wahl, da es deutlich granularer eingesetzt werden kann.
• Kein Verlust von externer Linkkraft, denn diese wird nicht weitergegeben
• Kein Bruch in der internen Verlinkung; häufig sonst sehr schwer steuerbar
• Reduzieren des Indexes auf ausschließlich relevante URLs
https://developers.google.com/webmasters/control-crawl-index/docs/robots_meta_tag
42. Bietet diese Seite wirklich signifikanten Mehrwert,
wenn ich sie für die Indexierung freigebe?
Stell dir immer die Frage:
43. Was nicht in den Index gehört #1
Leere (oder nahezu leere) Kategorie oder Tag-Seiten!
44. Was nicht in den Index gehört #2
… verschiedene Versionen einer URL, verursacht durch
gefilterte oder sortierte Inhalte!
45. Was nicht in den Index gehört #3
… oder dynamisch generierte Seiten wie Suchresultate!
SERP in SERP = schlechte Nutzererfahrung!
46. Was nicht in den Index gehört #4
.. und vieles mehr:
• verschiedene “no result-Seiten”
(keine Kommentare für Produkt A, keine Bewertungen für Produkt B, usw.)
• falsch implementierte Paginierungen
(Seite 2+ muss nicht indexiert werden, da diese idR. kein Rankingziel hat)
• Achtung bei Facettennavigationen
(wegen der Vielzahl an Kombinationen)
• mehrere Versionen einer Homepage
(z.B. index.php vs. “/” oder non-www vs. www oder https vs. non-https)
• gleicher Inhalt auf verschiedenen Domains
47. Wie viel Organic-Traffic haben die „noindex“-Kandidaten,
wie Filter & Sortierungen, denn wirklich?
Unsicher? Analytics Daten!
48. Noch besser als „noindex“ ist demnach das Löschen!
noindex geht natürlich auf
euer Crawl-Budget!
49. Auch hier: Weniger ist mehr; aber wenn, dann richtig!
#4 Weiterleitungen
50. Es gibt viele verschiedene Redirects:
http://en.wikipedia.org/wiki/List_of_HTTP_status_codes#3xx_Redirection
Und das sind nur die serverseitigen…
51. Und es gibt ja noch „andere“ Redirects:
• Weiterleitungen im HTML via Meta Tag: <meta refresh …>
• Simple, inline Weiterleitungen per JavaScript, z.B. mit
document.location.href=URL
• Komplexere, teils unsichtbare Weiterleitungen über externes
JavaScript, z.B. via jQuery Event Listener
• Etc.
Wichtig:
Nur weil Google diese Weiterleitungen (zum Teil) im „Fetch & Render“
erkennt, heißt das nicht, dass diese Weiterleitungen SEO kompatibel sind!
53. Mit einer Ausnahme: Language-switches
Source: http://pa.ag/1JqUcEo
• für sprach-/geo-basierte Redirects nutzt man HTTP 302 oder HTTP 303
• Google sagt, sie verstehen 301’s ebenso – aber sicher ist sicher!
60. Canonical Tags im Auge behalten!
Allgemein gilt: Für Filter, zum Sortieren oder bei HTTP
vs. HTTPs ist die Verwendung “OK”.
61. Google könnte Canonicals ignorieren…
Verwendet Canonical Tags nicht als Entschuldigung
für schlechte Website-Architektur!
http://googlewebmastercentral.blogspot.de/2009/02/specify-your-canonical.html
Is rel="canonical" a hint or a directive?
It's a hint that we honor strongly.
We'll take your preference into
account, in conjunction with other
signals, when calculating the most
relevant page […]
62. Aber oft passieren komische Dinge…
Es darf nur eine Rel-Canonical-Anweisung pro URL geben, nur EINE!
Absolute URLs mit Protokoll & Subdomain verwenden
Konsistenz wahren: Ein Protokoll (http vs. https), entweder www oder
non-www & konsistente Verwendung von Trailing Slashes
Rel-Canonical-Ziele müssen tatsächlich funktionieren (keine 4XX-Ziele)
Keine Canonical Tag-Verkettung, Google wird diese ignorieren!
etc.
65. X-Robots-Tag: Indexierungssteuerung
• Gleiche (kombinierte) Anweisungen, wie für das Robots Meta Tag möglich
• Entweder kommasepariert oder auch mehrfaches Verwenden des Headers
• Individuelle Crawler Regeln funktionieren auch hier analog zum Meta Tag.
http://https://developers.google.com/webmasters/control-crawl-index/docs/robots_meta_tag?hl=de
66. X-Robots Rel-Canonical Implementierung:
• Google indexiert auch PDFs, DOCs, usw. – auch diese Dateien sind bzw. können
Duplicate Content verursachen.
• Rankings – bspw. für PDF Dateien – sind eher schwierig (für den User), da eine
Navigation fehlt. Es empfiehlt sich daher zu einem PDF immer ein HTML Pendant
vorzuhalten und entsprechend dort hin per Canonical Header zu verweisen.
67. It’s all about site speed, especially on mobile!
#7 Site Speed
73. Viele Seitenbetreiber haben zugehört:
Top-4 Ergebnisse deutlich schneller als der Rest!
Source: Searchmetrics Ranking Factors 2014 (US) - http://pa.ag/10cZuU2
74. Die Erwartungshaltung ist eindeutig:
Diesen Ansprüchen müsst ihr gerecht werden!
“A report from Nielsen has revealed
that 47% of people expect a website to
load within 2 seconds, and 40% will
leave a website if it does not load fully
within 3 seconds.”
Quelle: http://pa.ag/1Rk8dIf
75. 100ms machen einen (großen) Unterschied!
Amazon = 1%+ mehr Umsatz pro 100ms
1 Sek. Verzögerung = -11% Pageviews & -7% Conversions
Source: http://pa.ag/1w8IYwq
76. Google PageSpeed Insights als Startpunkt
Freies, web-basiertes Tool, um eine Seite anhand
diverser Regeln und best-practices zu messen
https://developers.google.com/speed/pagespeed/insights/
77. Was wirklich zählt? Zeit statt Note!
Vollständiger Artikel: http://pa.ag/1KjZuQQ
78. webpagetest.org – mit allen Funktionen:
Alles auf einen Blick: TTFB, Keep-Alive, Compression &
Caching, Image Usage, CDN & Wasserfall-Diagramme
79. webpagetest.org – mit allen Funktionen:
Alles auf einen Blick: TTFB, Keep-Alive, Compression &
Caching, Image Usage, CDN & Wasserfall-Diagramme
80. Auf diese Punkte als erstes achten
(vor allem bei neuen Webseiten)
Welche Ressourcen hängen voneinander ab?
Wie wirkt sich JavaScript auf Ladezeiten aus?
Lassen sich lange Netzwerk- & DNS-Anfragen erkennen?
Blockieren sich Netzwerk-Anfragen von der gleichen Domain?
Finden sich “visuelle Abhängigkeiten” zwischen (Sub-)Anfragen?
Treten lange und exzessive JavaScript-Ausführungen auf?
81. Die eigene Seite (& den Wettbewerb)
fortlaufend monitoren!
Ende April veröffentlichte sitespeed.io ein sehr cooles
Dashboard für ein sehr granulares Monitoring
http://www.peterhedenskog.com/blog/2015/04/open-source-performance-dashboard/
83. Leider keine Zeit, tiefer einzusteigen, daher:
Zu den Folien: http://pa.ag/unggd15
84. 10x Ansätze um typische Probleme aufzuspüren:
Crawl-Issues identifizieren?
85. Google crawled GET-Formulare, POST is your friend!
Thin Content bzw. SERP in SERP Danger: Zielseiten
zus. auf “noindex”.
#1 Die interne Suche
86. Anzahl der Elemente pro Seite erhöhen =
weniger URLs im Pager!?
#2 Paginierungen
87. Haltet eure Sitemaps aktuell: Ausschließlich indexierbare
URLs, die mit HTTP Status 200 antworten!
#3 XML Sitemaps
88. Jede Weiterleitung zählt ins Crawl-Budget;
intern immer nur direkt auf die Zielseite verlinken!
#4 HTTP 30X (Redirect)
89. 404’er, werden mehrfach abgerufen bevor Google
diese löscht (wenn überhaupt). 410 = gone!
(Diese URLs natürlich nicht mehr aktiv verlinken!)
#5 HTTP 404 (not found)
90. Google muss die jeweilige Seite erst crawlen!
Weniger Restriktionen = weniger Crawl-Overhead!
#6 Exzessive Canonical Tags
91. Filter und / oder Sortierungen generieren Unmengen
an mgl. URL-Kombinationen. PRG ftw!
#7 Facetted Navigation
92. Das POST-Redirect-GET Pattern (PRG)
Suchmaschinenfreundliche Reduzierung von Verlinkung!
Mehr lesen: http://pa.ag/1jzXn6A
93. Google crawled z.B. auch AJAX Calls oder
JSON-Objekte (falls verlinkt)!
#8 Achtung bei Non-HTML‘s
94. …url?a=b&c=d ist nicht das Gleiche wie …url?c=d&a=b!
Einheitliche Reihenfolgen; oder # als Alternative?
#9 GET-Param. Reihenfolge
95. #10 Echte Daten gibt’s (nur) in Logfiles!
z.B. umsonst mit ELK (Elasticsearch, Logstash, Kibana)
http://logz.io/blog/log-analysis-technical-seo/