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

Surprise, Surprise!
Fünf Dinge, die du über technische
Suchmaschinenoptimierung bisher nicht wusstest
Bastian Grimm, Peak Ace AG | @basgr

Crawl Budget = Crawl Rate * Crawl Demand
#1 Dein Verständnis von Crawl
Budget ist falsch

Google crawlt nicht jede Seite (deiner Website).
Offensichtliches zuerst:

Wird eine Seite nicht gecrawlt, wird sie auch nicht
indexiert.

Ist eine Seite nicht indexiert, verdient ihr damit kein Geld!

pa.ag@peakaceag6
Aber das hier habt ihr sicher alle schon gesehen?
Quelle: https://pa.ag/2LUnt2R

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.

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.

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.

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

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

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”

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.

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.

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.

pa.ag@peakaceag16
Wie sich das Crawl Budget zusammensetzt
Crawl Budget = Crawl Rate * Crawl Demand
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?)

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:
[…] 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.

Deshalb gilt:
Ihr müsst eure Fehler beheben!
(Just saying.)

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.

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:
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)

Wo liegt der Unterschied – und warum ist das
überhaupt wichtig?
Crawling vs. Indexierung

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.

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?

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

Wiederkehrende Elemente und anderen Boilerplate
Content sicher „verstecken“
#2 Einfache JavaScript Events reichen
(schon lange) nicht mehr aus

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:

Wie verhindere ich, dass bspw.
rechtliche Hinweise und
Versandinformationen als
Boilerplate gewertet werden und
sich ggf. negativ auswirken?

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

pa.ag@peakaceag29
Content im HTML-Markup, hier in einem <p> TagContent im CSS-Selektor – hier z. B. ::before

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

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

Der iFrame Content wird nach dem Rendern – in einigen
Fällen – der übergeordneten URL zugeordnet.
#3 iFrames sind gefährlich

pa.ag@peakaceag33
Laut BuiltWith sind iFrames immer noch beliebt
Quelle: https://pa.ag/2l8qDaN

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>

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.

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!

Welchen Einfluss hat z. B. bewusst über iFrames
eingebundener Content nunmehr auf meine Domain?
Page Level Quality?

Dirty 3rd-Party iFrames, anyone?

Ein weiterer Test… weil: Links!
Noch nicht überzeugt?

pa.ag@peakaceag40
Zwei zusätzliche Links (1 interner, 1 externer)
wurden zur iFrame URL hinzugefügt.

pa.ag@peakaceag41
GSC HTML zeigt die Links selbstverständlich an:
Wieder werden sie in das DOM der übergeordneten URL eingebettet.

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.

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:

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.

Falls ihr verhindern wollt, dass jemand eure Inhalte
in einem iFrame lädt (und dafür ranken kann).
X-Frame-Options Header

Basis: ~500 Domains (primär in Europa), auditiert in den
letzten 24 Monaten
#4 Die drei häufigsten DC-Szenarien

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

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

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.

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!?

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.

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

Was, wenn ich zwingend URL-Parameter fürs Tracking
verwenden muss?
#5 Tracking- und andere
GET-URL-Parameter

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

pa.ag@peakaceag56
Und bitte niemals intern verlinken ...!

pa.ag@peakaceag57
Auch eigene Parameter nicht für das Tracking nutzen!
Erwähnte ich schon, dass Parameter tatsächlich ständig Probleme machen?

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

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

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.

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)

UX ab 2021 offiziell nun ein Google “Ranking-Faktor”
#6 Bonus: #webperf

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

Schnelle Ladezeiten machen einen wesentlichen Anteil
der gesamten User Experience aus.
Performance = User Experience

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

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 […]

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

Wie kriege ich meine (Listing- /
Kategorie-) Seiten schneller?

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

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.

pa.ag@peakaceag71
Im Google Lighthouse Report zu finden unter:
Opportunities > Properly size images

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

imagemin ist euer Freund: "lossy" oder "lossless"
Komprimierung für JPEG, PNG, GIF, SVG & WebP
DIY-Bildkomprimierung

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)

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

pa.ag@peakaceag76
Im Google Lighthouse Report zu finden unter:
Opportunities > Defer offscreen images

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

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:

Ich kann / will nicht allen
Content sofort zeigen; kann ich auf- / zuklappen?
#7 Bonus: Content auf- / zuklappen

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; }

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.

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!

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.

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

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

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

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

Similar a SEOday Köln 2020 - Surprise, Surprise - 5 SEO secrets (20)

Más de Bastian Grimm

Más de Bastian Grimm (20)

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