Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

SEOday Köln 2020 - Surprise, Surprise - 5 SEO secrets

692 views

Published on

My talk [DE] from SEOday 2020 in Cologne titled: "Surprise, Surprise - Fünf Dinge, die du über technische Suchmaschinenoptimierung bisher nicht wusstest". Enjoy!

Published in: Marketing
  • Login to see the comments

SEOday Köln 2020 - Surprise, Surprise - 5 SEO secrets

  1. 1. Surprise, Surprise! Fünf Dinge, die du über technische Suchmaschinenoptimierung bisher nicht wusstest Bastian Grimm, Peak Ace AG | @basgr
  2. 2. Crawl Budget = Crawl Rate * Crawl Demand #1 Dein Verständnis von Crawl Budget ist falsch
  3. 3. Google crawlt nicht jede Seite (deiner Website). Offensichtliches zuerst:
  4. 4. Wird eine Seite nicht gecrawlt, wird sie auch nicht indexiert. Offensichtliches zuerst:
  5. 5. Ist eine Seite nicht indexiert, verdient ihr damit kein Geld! Offensichtliches zuerst:
  6. 6. pa.ag@peakaceag6 Aber das hier habt ihr sicher alle schon gesehen? Quelle: https://pa.ag/2LUnt2R
  7. 7. pa.ag@peakaceag7 Aktuelle Info zu Crawl Budget bei Search off the Record Laut Googles Gary Illyes muss sich kaum jemand um das Crawl Budget sorgen: Quelle: https://pa.ag/2GdrDEN If you have fewer than one million URLs on a site, you usually don't have to worry about crawl budget […] usually it’s about the stupid stuff which either makes Googlebot crawl like crazy or can result in Googlebot to stop crawling entirely.
  8. 8. pa.ag@peakaceag8 Was der Google Webmaster Central Blog dazu sagt: Quelle: https://pa.ag/2HhsYoz Wasting server resources on pages […] will drain crawl activity from pages that do actually have value, which may cause a significant delay in discovering great content on a site.
  9. 9. pa.ag@peakaceag9 Falls ihr schon mal mit solchen Seiten zu tun hattet … Der richtige Umgang mit >50.000.000 crawlfähigen URLs (durch Verwendung von Parametern) macht einen erheblichen Unterschied in der organischen Performance! Google Analytics meldete knapp ~ 230.000 Unique URLs, der GSC zufolge waren jedoch über 50 Millionen URLs vorhanden.
  10. 10. pa.ag@peakaceag10 URL-Parameter verursachen i. d. R. die meisten Probleme (Kombinierte) URL-Parameter generieren oft Millionen von unnötigen URLs – v. a. für große Domains, die der Googlebot dann sorgfältig crawlt (sobald er sie gefunden hat).
  11. 11. pa.ag@peakaceag11 Challenge: Google dazu bringen, wichtige URLs zu crawlen Enorme Kürzungen des Bestands crawlbarer URLs führten zu einem Umbruch: Google crawlte zuvor nicht gecrawlte URLs nach der Eliminierung 15M+ unnötiger URLs. Quelle: Peak Ace AG 0 5.000.000 10.000.000 15.000.000 20.000.000 25.000.000 30.000.000 35.000.000 Jul Aug Sep Oct Nov Dec Jan Feb crawled URLs un-crawled URLs total URLs
  12. 12. pa.ag@peakaceag12 Checkt eure Domains: Indexabdeckung in der GSC Schaut euch v. a. den Bereich „Excluded” genauer an und achtet auf Crawl-Anomalien. Besser doppelt checken: “crawled - currently not indexed”, “duplicate without user-selected canonical” und “duplicate, Google chose different canonical than user”
  13. 13. pa.ag@peakaceag13 Die meisten „normal großen“ Domains werden keine massiven Probleme bewältigen müssen, aber: The bigger the website, the bigger the potential issues with crawl and index budgeting.
  14. 14. pa.ag@peakaceag14 Die meisten „normal großen“ Domains werden keine massiven Probleme bewältigen müssen, aber: Due to the size of the web, search engines have limited capacity, which you want to focus on your most important URLs.
  15. 15. pa.ag@peakaceag15 Das Konzept von „Crawl Budget” verstehen Das Crawl Budget ist die Länge der Zeit, die Crawler auf eurer Website verbringen. Es sollte sinnvoll „ausgegeben“ werden (und dafür könnt ihr sorgen), denn: Quelle: https://pa.ag/2KZIUjM & https://pa.ag/3b5jkEs ▪ Crawling kostet Geld. Sehr viel Geld. Geld ist eine knappe Ressource. ▪ Crawling-Ressourcen sollten effizient (sparsam) eingesetzt werden. ▪ Websites erhalten ein spezifisches „Crawl Budget“, das von verschiedenen Faktoren abhängt. ▪ NICHT: n Dokumente pro Host aber „Datacenter Computing Time“ pro Domain (Zeiteinheiten). ▪ Optimierung des Crawl Budgets = Google dabei helfen, mit weniger mehr zu erreichen.
  16. 16. pa.ag@peakaceag16 Wie sich das Crawl Budget zusammensetzt Crawl Budget = Crawl Rate * Crawl Demand Quelle: https://pa.ag/2HhsYoz Unter Einbezug der Crawl Rate und des Crawl Demand definieren wir [Google] das Crawl Budget als die Anzahl aller URLs, die der Googlebot crawlen kann und möchte. Crawl Rate: steht für die Anzahl der gleichzeitigen parallelen Verbindungen, die der Googlebot zum Crawlen der Website verwenden kann sowie für die Zeit, die er zwischen den einzelnen Abrufen warten muss. Die Crawl Rate kann steigen oder fallen – abhängig von: ▪ Crawl Health (Geschwindigkeit / Fehler) ▪ GSC Crawl Limit Crawl Demand: Selbst wenn das Limit der Crawl Rate nicht erreicht wird, ist der Googlebot kaum aktiv, so lange es keine Nachfrage von der Indexierung gibt. Zwei Faktoren sind bei der Bestimmung des Crawl Demand entscheidend: ▪ Popularität (Links? CTR?) ▪ Staleness (oder Freshness?)
  17. 17. pa.ag@peakaceag17 Die Crawl Rate ist keine fixe Kennzahl! Die Crawl Rate hängt von der Crawl Health ab, die folgendermaßen zu definieren ist: Quelle: https://pa.ag/2HhsYoz […] if the site responds really quickly for a while, the limit goes up, meaning more connections can be used to crawl. If the site slows down or responds with server errors, the limit goes down and Googlebot crawls less.
  18. 18. Deshalb gilt: Ihr müsst eure Fehler beheben! (Just saying.)
  19. 19. pa.ag@peakaceag19 Crawl Demand = Popularität + Staleness Oder falls ihr es freundlicher formulieren wollt: freshness Quelle: https://pa.ag/2Lc2SrP In general we [Google] try to do our crawling based on when we think this page might be changing, how often it will be changing. So if we think that something stays the same for longer periods of time, we might not crawl it for a couple of months. That is completely fine, we can still show it in search.
  20. 20. pa.ag@peakaceag20 Weitere Faktoren, die euer Crawl Budget beeinflussen Viele URLs mit einem nur geringen Mehrwert können sich negativ auf das Crawling sowie die Indexierung einer Website auswirken: Quelle: https://pa.ag/2HhsYoz Faktoren lt. Google, der Bedeutung nach sortiert: ▪ Faceted Navigation und Session IDs ▪ On-Site Duplicate Content ▪ Soft Error Pages ▪ Hacked Pages ▪ Infinite Spaces und Proxies ▪ Spam Content / Content geringer Qualität Was meiner Meinung nach ebenso wichtig ist: ▪ Alter: je älter die Domain, desto vertrauenswürdiger das Linkprofil ▪ Linkprofil (Authority / Trust): je stärker das allgemeine Linkprofil, desto mehr Computing Time ▪ Größe und (inhaltliches) Wachstum im Laufe der Zeit ▪ Zugänglichkeit: die „richtigen“ Links, HTTP-Statuscodes und Direktive bzgl. Crawling und Indexierung ▪ Prioritäten: wichtige Inhalte gehen vor ▪ Effizienz: kein Duplicate Content und Thin Pages ▪ Geschwindigkeit: so schnell wie möglich (Host Load)
  21. 21. Wo liegt der Unterschied – und warum ist das überhaupt wichtig? Crawling vs. Indexierung
  22. 22. pa.ag@peakaceag22 Nur damit wir hier alle auf dem gleichen Stand sind … Schauen wir uns einmal an, was die beiden Begriffe tatsächlich bedeuten: Crawling Crawling ist ein Prozess, bei dem Suchmaschinen Bots (auch als „Crawler“ bezeichnet) aussenden, um neue und aktualisierte Inhalte zu finden. Bei diesen Inhalten kann es sich um Webseiten, Bilder, Videos, PDF-Dateien etc. handeln. Unabhängig vom Format wird der Inhalt durch (Follow) Hyperlinks gefunden. Indexierung Der Index ist der Ort, an dem alle Seiten gespeichert werden. Nachdem ein Crawler eine Seite gefunden hat, wird sie von der Suchmaschine gerendert (genau wie im Browser). Dabei wird ihr Inhalt analysiert und alle diese Informationen werden abgespeichert. Wurde eine Seite entdeckt und gecrawlt, heißt das nicht zwingend, dass sie im Index gespeichert wird. vs.
  23. 23. pa.ag@peakaceag23 Auf einen Blick: Cheat Sheet für Crawling & Indexierung Entscheidungshilfe, wie ihr mit dem Googlebot und anderen Crawlern arbeiten könnt: Do nothing Implement meta canonical tag or x-robots rel- canonical header (to page which supposed to rank) Meta robots noindex tag or x-robots header Block URL/path/pattern using robots.txt or GSC URL parameter handling YES NOYES YESNO NOYES Are search engines allowed to crawl?Should it be indexed? Remove page from CMS/shop and apply 301 redirect Remove page from CMS/shop and serve 404/410 Should this page exist? Does it have SEO value? NO YES NO Does it have SEO value?
  24. 24. pa.ag@peakaceag24 Auf einen Blick: Cheat Sheet für Crawling & Indexierung Welche Direktive / Annotation führt zu welchem Ergebnis? Crawlbar Indexierbar Verhindert Duplicate Content Konsolidiert Signale robots.txt-Datei Robots Directives (Meta & HTTP Header) Canonical Tag (Meta & HTTP Header) hreflang Directives Rel-alternate Directive Search Console HTTP-Authentifizierung
  25. 25. Wiederkehrende Elemente und anderen Boilerplate Content sicher „verstecken“ #2 Einfache JavaScript Events reichen (schon lange) nicht mehr aus
  26. 26. pa.ag@peakaceag26 Wiederkehrende Elemente auslagern oder nachladen Exakt gleiche Lieferinformationen sowie Kundenvorteile auf der Produktseite überdenken; einfaches JS-Nachladen ist u. U. nicht mehr ausreichend:
  27. 27. Wie verhindere ich, dass bspw. rechtliche Hinweise und Versandinformationen als Boilerplate gewertet werden und sich ggf. negativ auswirken?
  28. 28. pa.ag@peakaceag28 Was sind CSS-Selektoren und wie funktionieren sie? ::before erzeugt ein Pseudoelement – das erste Resultat des gematchten Elements. Quelle: https://pa.ag/2QRr9aH
  29. 29. pa.ag@peakaceag29 Content im HTML-Markup, hier in einem <p> TagContent im CSS-Selektor – hier z. B. ::before
  30. 30. pa.ag@peakaceag30 Die GSC-Vorschau zeigt euch, wie es aussehen würde Googlebot scheint dies genauso zu handhaben wie Chrome auf Desktop / Smartphone: das gerenderte DOM bleibt unverändert (zu erwarten, da Pseudoklasse). HTML CSS
  31. 31. pa.ag@peakaceag31 Content innerhalb der CSS-Selektoren wird nicht indexiert Egal, ob Googlebot die URL rendert oder nicht – für die Testphrase, die sich im CSS ::before Selektor befindet, wird die URL nicht gefunden. Content in CSS-Selektoren wie ::before wird nicht indexiert Content im HTML-Markup wird wie erwartet gefunden und indexiert
  32. 32. Der iFrame Content wird nach dem Rendern – in einigen Fällen – der übergeordneten URL zugeordnet. #3 iFrames sind gefährlich
  33. 33. pa.ag@peakaceag33 Laut BuiltWith sind iFrames immer noch beliebt Quelle: https://pa.ag/2l8qDaN
  34. 34. pa.ag@peakaceag34 Zur Auffrischung: übergeordnete URL + iFrame Übergeordnete Seite / Bereich im gelben Kasten iFrame Content (von einer 2. URL) innerhalb des markierten roten Kastens <iframe src="URL"></iframe>
  35. 35. pa.ag@peakaceag35 Es scheint als wären reguläre iFrames durchaus riskant Der iFrame Content wird nach dem Rendern der übergeordneten URL zugeordnet; die übergeordnete Seite kann nun plötzlich für Content aus dem iFrame gefunden werden: Dieser Satz stammt ursprünglich aus dem iFrame, nicht von der übergeordneten URL.
  36. 36. pa.ag@peakaceag36 Nach Rendern: übergeordnete URL rankt für iFrame-Inhalt Einfach gesagt: Diese URL … … wird jetzt für den Content, der von dieser 2. URL stammt, gefunden!
  37. 37. Welchen Einfluss hat z. B. bewusst über iFrames eingebundener Content nunmehr auf meine Domain? Page Level Quality?
  38. 38. Dirty 3rd-Party iFrames, anyone?
  39. 39. Ein weiterer Test… weil: Links! Noch nicht überzeugt?
  40. 40. pa.ag@peakaceag40 Zwei zusätzliche Links (1 interner, 1 externer) wurden zur iFrame URL hinzugefügt.
  41. 41. pa.ag@peakaceag41 GSC HTML zeigt die Links selbstverständlich an: Wieder werden sie in das DOM der übergeordneten URL eingebettet.
  42. 42. pa.ag@peakaceag42 Der GSC „Top Linking Pages“-Bericht bestätigt das Die übergeordnete URL erscheint als verlinkende Seite für bastiangrimm.com – auch wenn sie keine Links in ihrem HTML-Markup aufweist.
  43. 43. Was kann / muss ich tun?
  44. 44. pa.ag@peakaceag44 iFrames URLs auf noindex setzen (oder robots.txt nutzen) Bestätigung: In den automatisch generierten Meta Descriptions fehlt jeglicher iFrame Content; GSCs HTML zeigt den eingebetteten Inhalt (aus dem Frame) nicht an:
  45. 45. pa.ag@peakaceag45 Content von / in „versteckten“ Frames wird nicht indexiert Ähnlich den noindex Frames erscheint eine Meta Description nicht in ihren SERPs. Der iFrame Tag enthält eine „display:none“-Annotation, der Content ist nicht im gerenderten DOM eingebettet. Keine Einbettung im gerenderten DOM, weil „hidden” über JS angewendet wurde.
  46. 46. Falls ihr verhindern wollt, dass jemand eure Inhalte in einem iFrame lädt (und dafür ranken kann). X-Frame-Options Header
  47. 47. Basis: ~500 Domains (primär in Europa), auditiert in den letzten 24 Monaten #4 Die drei häufigsten DC-Szenarien
  48. 48. pa.ag@peakaceag48 Die häufigsten Ursachen für Duplicate Content Für Google sind diese Beispiele jeweils zwei unterschiedliche URLs bzw. Duplikate: Taxonomie-Probleme Produktionsserver vs. https://pa.ag/url-a/ https://pa.ag/url-A/ Groß- und Kleinschreibung https://pa.ag/url-b https://pa.ag/url-b/ Trailing Slashes Kategorie A Kategorie BKategorie C Staging- / Test-Server
  49. 49. pa.ag@peakaceag49 Die häufigsten Ursachen für Duplicate Content Für Google sind diese Beispiele jeweils zwei unterschiedliche URLs bzw. Duplikate: Umgang mit Duplication-Problemen ▪ 301-Redirect: z. B. non-www vs. www, HTTP vs. HTTPS, Groß- und Kleinschreibung, Trailing Slashes, Index-Seiten (index.php) ▪ noindex: z. B. White Labelling, interne Search Result Pages, Work-in-Progress Content, PPC- und andere Landingpages ▪ (selbst-referenzierende) Canonicals: z. B. für Tracking- Parameter, Session IDs, Druckversion, PDF zu HTML etc. ▪ 403-Passwortschutz: z. B. Staging / Development Server ▪ 404 / 410 (gone): z. B. feeded Content welcher schnell entfern werden muss, andere veraltete / irrelevante oder qualitativ minderwertige Inhalte i https://pa.ag https://www.pa.ag non-www vs. www http://pa.ag https://pa.ag HTTP vs. HTTPS https://www.pa.ag/cars?colour=black&type=racing https://www.pa.ag/cars?type=racing&colour=black Reihenfolge der URL-Parameter
  50. 50. pa.ag@peakaceag50 Canonical Tags sind nur (sehr selten) eine Lösung Ein Canonical Tag ist nur ein Hinweis, keine Direktive – Google kann es ignorieren. Daher ist besondere Vorsicht bei der Verwendung von Canonical Tags geboten: ▪ Absolute URLs mit Protokoll und Subdomains nutzen ▪ Rel-canonical-Ziele müssen tatsächlich funktionieren (keine 4XX-Ziele) – diese müssen ein HTTP 200 liefern. ▪ Keine Canonical-Tag-Ketten, Google ignoriert diese! ▪ Konsistenz wahren: immer das gleiche Protokoll (HTTP vs. HTTPS), entweder mit oder ohne www und die konsequente Verwendung von Slashes am Ende der URLs. ▪ Es darf nur eine rel-canonical-Annotation pro URL geben – EINE! ▪ etc.
  51. 51. pa.ag@peakaceag51 Auch „Mixed Signals“ führen relativ häufig zu DC Zwei Canonical Tags (mit unterschiedlichen Zielen) – und weil‘s so schön ist, gleich auch noch ein Meta Robots „noindex“ dazu. Keine wirklich gute Idee! Auch nett… sortieren nach „Reihenfolge“… OK!?
  52. 52. pa.ag@peakaceag52 Achtung, DC! Wie viel Sortieren / Filtern ist zu viel? Bitte erst mal sicherstellen, dass die Optionen tatsächlich genutzt werden (Analytics ist dein Freund!) – andernfalls sollten sie eher entfernt / konsolidiert werden.
  53. 53. pa.ag@peakaceag53 Ebenfalls akute DC-Gefahr: Artikel pro Seite einstellen Hier wird für jedes Kategorie-Listing zusätzlich die 3-fache URL-Anzahl generiert – ein Crawling-Desaster. Und oft, wenn nicht gesteuert, auch noch Duplicate Content: Client-side JavaScript würde zumindest Crawling- und Indexierungsprobleme lösen – fraglich ist dennoch, ob diese Funktion tatsächlich genutzt wird.“
  54. 54. Was, wenn ich zwingend URL-Parameter fürs Tracking verwenden muss? #5 Tracking- und andere GET-URL-Parameter
  55. 55. pa.ag@peakaceag55 Im Idealfall: # anstelle von ? verwenden GA Tracking mit Fragmenten anstelle von GET-Parametern betreiben; oder Parameter automatisch via hitCallback-Parameter (nach Messung des Seitenaufrufs) entfernen: Quelle: https://pa.ag/2TuJMk5 Wenn ihr – aus welchen Gründen auch immer – GET- URL-Parameter verwenden müsst, Canonical Tags nicht vergessen und immer via GSC testen, ob Google diese auch honoriert.“
  56. 56. pa.ag@peakaceag56 Und bitte niemals intern verlinken ...!
  57. 57. pa.ag@peakaceag57 Auch eigene Parameter nicht für das Tracking nutzen! Erwähnte ich schon, dass Parameter tatsächlich ständig Probleme machen?
  58. 58. pa.ag@peakaceag58 Und auch sonst sind Parameter häufig problematisch: (Kombinierte) URL-Parameter generieren oft Millionen von unnötigen URLs – v. a. für große Domains, die der Googlebot dann sorgfältig crawlt (sobald er sie gefunden hat).
  59. 59. pa.ag@peakaceag59 Peak Ace Log File Auditing Stack – Interesse? → hi@pa.ag Logfiles werden in Google Cloud Storage gespeichert, in Dataprep verarbeitet, in BigQuery exportiert und über den BigQuery Connector in Data Studio visualisiert. 8 Google Data Studio Data transmission Display dataImport Google Dataprep 6 7 Google BigQuery 1 Log files GSC API v3 GA API v4 GA GSC 2 3 65 Google Apps Script DeepCrawl API 4
  60. 60. pa.ag@peakaceag60 URL-Parameter-Settings in der Google Search Console Die GSC erlaubt es, manuell URL-Parameter und ihre Auswirkungen zu konfigurieren; hier unbedingt bedenken, dass dies „nur“ für Google erfolgt.
  61. 61. pa.ag@peakaceag61 Best Case Scenario: GET-Parameter-Whitelisting Combine with 301 redirects to self, without parameters for all unknown GET parameters CLEAN URLS CANONICALISE (to self, ohne angehängt Parameter) 301-REDIRECT (to self, ohne angehängte Parameter) 403-ERROR (Solltet ihr schädliche Anfragen entdecken) HTTP 200 (Falls Parameter in der Whitelisting-Tabelle gefunden werden) WHITELIST CHECK (einzeln für jeden GET-Parameter)
  62. 62. UX ab 2021 offiziell nun ein Google “Ranking-Faktor” #6 Bonus: #webperf
  63. 63. pa.ag@peakaceag63 Nichts Neues: kürzere Ladezeiten = mehr gecrawlte URLs Die Verkürzung der Ladezeiten der Websites (Lighthouse Score ~36 zu 70) führte zu 25 % mehr URLs, die von Googlebot gecrawlt wurden. Quelle: Peak Ace AG 0 10 20 30 40 50 60 70 80 0 50.000 100.000 150.000 200.000 250.000 300.000 350.000 400.000 Nov Dec Jan Feb Mar Apr crawled URLs Lighthouse perf. score (avg.)
  64. 64. Schnelle Ladezeiten machen einen wesentlichen Anteil der gesamten User Experience aus. Performance = User Experience
  65. 65. pa.ag@peakaceag65 UX ab 2021 „offiziell“ Google-Ranking-Faktor Core Web Vitals: User und Page Experience auf einer Website evaluieren Quelle: https://pa.ag/3irantb Google plant zukünftig zu evaluieren, wie Besucher die Interaktion mit einer Webseite wahrnehmen. Dafür wird ein neues Set an Metriken verwendet - die Core Web Vitals. Fällt die User Experience diesen Metriken zufolge negativ aus, kann das dazu führen, dass Google die entsprechende Webseite schlechter rankt. i
  66. 66. pa.ag@peakaceag66 Fast Page Labelling seit Chrome 85 (Android) verfügbar Den Link lange drücken, dann erscheint auf Basis der Core Web Vitals die jeweilige Info zur URL (sofern die URL / Domain in der Vergangenheit schnell genug war): Quelle: https://pa.ag/31CChgi "Fast page" labelling may badge a link as fast if the URL (or URLs like it) have been historically fast for other users. When labelling, historical data from a site’s URLs with similar structure are aggregated together. Historical data is evaluated on a host- by-host basis when URL data is insufficient […]
  67. 67. pa.ag@peakaceag67 Client-side / Front-End: #webperf Hausaufgaben Verwendet zur Überprüfung meine Checkliste auf SlideShare: Alle Slides findet ihr auf SlideShare: http://pa.ag/iss18speed ▪ Content-First-Ansatz verfolgen: schrittweise Verbesserung, Above-the-Fold-Inhalte priorisieren: 14 kB (komprimiert) ▪ Größe reduzieren: effektive Zwischenspeicherung- und Komprimierungsprozesse implementieren ▪ Wann immer möglich, asynchrone Requests verwenden ▪ CSS- und JavaScript-Dateien verkleinern ▪ Schlankes Markup: keine Kommentare, Inline CSS / JS nur dort verwenden, wo es notwendig oder sinnvoll ist ▪ Bilder optimieren: JPGs & PNGs optimieren (Metadaten, etc.), passende Größen anfragen & neue Formate testen ▪ Browser Reflow und Repaint verkürzen
  68. 68. Wie kriege ich meine (Listing- / Kategorie-) Seiten schneller?
  69. 69. pa.ag@peakaceag69 60 % des gesamten Web Traffics machen Bilder aus … Die durchschnittliche Website übermittelt zwischen 890 – 990 KB an Bildern pro URL! Quelle: https://pa.ag/2xwHOFN
  70. 70. pa.ag@peakaceag70 Erneuter Hinweis auf Best Practices zur Bildoptimierung Gerade letzte Woche wies Google erneut auf die Notwendigkeit der Optimierung von hochwertigen Bildern hin (u. a. Whitespace entfernen, hohe Qualität, aktuell etc.): Quelle: https://pa.ag/2Hw7vPe Include a relevant, high quality image. […] ensure that the image is visually engaging and is of good quality. For additional guidance on image quality, review the Google Images best practices and Images Web Fundamentals.
  71. 71. pa.ag@peakaceag71 Im Google Lighthouse Report zu finden unter: Opportunities > Properly size images
  72. 72. pa.ag@peakaceag72 Grundlegende Bildoptimierung: Setzt sie auf „Diät” tinyPNG & tinyJPG zur (verlustfreien) Komprimierung & Entfernung von Metadaten et al., API-Zugriff, div. Plug-ins (WP etc.) sowie zur direkten Integration in Photoshop. Quelle: http://tinypng.com | http://tinyjpg.com
  73. 73. imagemin ist euer Freund: "lossy" oder "lossless" Komprimierung für JPEG, PNG, GIF, SVG & WebP DIY-Bildkomprimierung
  74. 74. pa.ag@peakaceag74 premierleague.com: >50 % Bildgröße / Traffic einsparen WebP / JPEG-XR ermöglichen verlustfreie Komprimierung, Transparenz, Metadaten, Farbprofile, Animationen und deutlich kleinere Dateien (30 % vs. JPEG, 80 % vs. PNG)
  75. 75. pa.ag@peakaceag75 Zurück zu Bildern: Responsive Images einfach generieren Ein Bild für alle Bildschirmauflösungen und Geräte ist nicht ausreichend. Ein Bild pro Pixel ist zu viel; responsivebreakpoints.com kann hier helfen! Mehr: https://pa.ag/2NNBvVm & https://pa.ag/2C6t6aQ
  76. 76. pa.ag@peakaceag76 Im Google Lighthouse Report zu finden unter: Opportunities > Defer offscreen images
  77. 77. pa.ag@peakaceag77 „lazySizes“ – Bilder erst laden, wenn sie benötigt werden Der leistungsstarke Lazy Loader für Bilder, iFrames und mehr erkennt jede Änderung in der Sichtbarkeit (z. B. durch Benutzerinteraktion, CSS oder JS) ohne Konfiguration. Mehr auf GitHub: https://pa.ag/2VOywil Besonders wichtig für mobile Geräte, da nur Bilder geladen werden sollen, die tatsächlich sichtbar sind! Selbst Responsive Images lassen sich damit laden (die Größen werden automatisch berechnet).
  78. 78. pa.ag@peakaceag78 Es wird jetzt alles viel einfacher: loading = lazy Performance Benefits gepaart mit SEO-Freundlichkeit (und ganze ohne JS) Tipp: Funktioniert übrigens auch für <iframe src=“…“ loading=“lazy“> Quelle: https://pa.ag/2YQL9gE Aktuelle Versionen von Chrome, Firefox und Edge bereits mit entsprechender Unterstützung:
  79. 79. Ich kann / will nicht allen Content sofort zeigen; kann ich auf- / zuklappen? #7 Bonus: Content auf- / zuklappen
  80. 80. pa.ag@peakaceag80 Sichtbarkeit von Content mit CSS-Annotationen ändern Diverse Möglichkeiten, Content anzuzeigen / zu verstecken, z. B. mit Opacity, Position, Display, Overflow etc. .read-more-target { opacity: 0; max-height: 0; font-size: 0; transition: .25s ease; }
  81. 81. pa.ag@peakaceag81 Ob sichtbar oder nicht, die Seite wird gefunden Aber: Text, der beim Laden nicht sichtbar ist, wird im Snippet nicht hervorgehoben: Content mit opacity:0, der nur nach Interaktion sichtbar ist: keine Hervorhebung! Content, der sofort sichtbar ist, wird in den SERPs entsprechend der Query hervorgehoben.
  82. 82. pa.ag@peakaceag82 Die Ergebnisse sind für alle Testfälle gleich Google liefert Ergebnisse (d. h. findet jede Test-URL, auch für den jeweils „versteckten“ Content) für alle Ein- und Ausklappmöglichkeiten. Getestet haben wir u. a. ▪ opacity:0 ▪ display:none ▪ position:absolute & top:-9999px ▪ overflow:hidden ▪ visibility:hidden ▪ width:1px & height:1px overflow:hidden als einzige Variante für SERP Highlighting: Testphrase aus dem mittels „overflow:hidden“ versteckten Bereich, trotzdem weiterhin hervorgehoben im Snippet!
  83. 83. pa.ag@peakaceag83 Das funktioniert auch mit diversen JS-basierten Lösungen readmore.js (jQuery), vanilla JS (getElementById), rendered JS (OPA) und modern JS Viele JS-Lösungen (z. B. readmore.js) funktionieren, indem sie „overflow“ nutzen, daher hier die Hervorhebung.
  84. 84. Any questions? hi@pa.ag www.pa.ag twitter.com/peakaceag facebook.com/peakaceag Take your career to the next level: jobs.pa.ag Bastian Grimm bg@pa.ag

×