Technisches SEO: Crawling Budget, Indexing, Performance | morefire Kneipentalk

By | August 30, 2019


Hi zusammen, willkommen zum morefire
Kneipentalk. Heute reden wir über das Thema Tech SEO und dazu haben uns den
schönen René eingeladen. Hallo, zum Wohle so auf ein Kölsch mit
René. Genau, wir haben uns heute vorgenommen, das Thema technische SEO ein bisschen
auseinander zu nehmen. Was ist für dich technische SEO?
Klassisch, alles was unter der Haube ist. Was der normale Redakteur, der normale
Seitenbetreiber nicht sieht und oftmals sogar auch zu meinem Erschrecken halt
nicht weiß anzupacken, anzugehen. Wenn ein Auto halt einen Ölwechsel braucht, okay die
Theorie ist soweit klar, aber wo ist der Drehknopf, wo geht das Ölwechsel unten
wieder raus? Da gibts nämlich auch noch einen Knopf wo ich dran ziehen was
bringt mir das überhaupt? All diese Sachen fallen, sage ich jetzt
mal, unter die Rahmenbedingungen von technical SEO. Also Dinge wie Crawling,
Rendering solche Geschichten? Genau, das fängt da, fängt schon damit an beim Crawling.
Das ist praktisch das Eintrittstor in den Google-Index. Ich glaube wie
hinlänglich bekannt, dass nur das, nur die Informationen, die Google halt sehen
kann, betreten oder ausführen verarbeitet kann, verstehen kann, genau danke. Können
auch in den Index kommen und nur was im Google-Index ist, kann halt gerankt und
auf den Suchergebnisseiten ausgespielt werden, ist ganz klar. Und früher hat
man ja gesagt Google versteht nur Text. Also früher konnte man ja sogar Text
verständlich machen, der nicht überall sichtbar war.
Aber Dinge wie damals Flash oder Javascript da haben wir alle gesagt hat
Google keine Chance kommt nicht durch. Genau, genau, nach wie vor es natürlich so,
dass Google eine Textsuchmaschine primär ist. Gehört dabei zur Kategorie der
Index-Suchmaschinen und lustigerweise, klar, Flash damals ein Graus oder halt
auch der heißeste Scheiß. Ich glaube 2008 rum war das, hat
Google aber wohl gelernt Inhalte oder die sinngemäß die Inhalte aus Flash
Embedded Content heraus exorzieren, herauslesen zu können
und daneben auch in seinem Index, ich sage mal, zu verschlagworten damit
aufnehmen zu können. Ich kann mich noch erinnern, dass wir HTML-Fallbacks auf Flashseiten
eingebaut haben. Das wäre gar nicht nötig gewesen genau es ist gar nicht, ist nicht, ist
heute auch nicht mehr nötig, aber wenn man Flash einsetzt sollte man es auf
jeden Fall, trotzdem nach wie vor tun, weil es ist halt immer noch nicht garantiert,
dass Google es mittlerweile immer noch genauso tut wie damals. In der Regel
tut es Google halt eher nicht mehr so wie damals. Ich glaube ein Jahr später, 2009,
hat dann Google gelernt Inhalte von dynamischer Bereitstellung, also die mit
Ajax, sage ich jetzt mal, manipuliert oder nachgeladen wurde. Hat
Google dann verstanden die auch auslesen zu können und bewerten zu können.
Und ich glaube diese ganze Thematik wie Google mit mit diesen Geschichten umgeht,
hat sich 2015 noch einmal grundlegend geändert. Da hat nämlich dann Google gesagt, ich sag mal, die alte Crawling Technologie oder das Vorgehen, wie wir es
all die Jahre gemacht haben. Das ist jetzt depretcht, also das machen wir nicht weiter in
der Form und wir shiften da jetzt unseren Fokus ein bisschen. Okay, also
Javascript ist auch kein Problem mehr. Also ich kann mich noch an Zeiten
erinnern, da haben wir Javascript-Links zu machen um den Linkjuice in der Seite zu
behalten. Davon würde ich natürlich heute abraten, aber
versteht Google was hinter so einem Javascript-Link passiert? Also generell
ist es so, dass Google bei nahezu allen großen Seiten oder Seiten mit genug
Trust und Domain-Authority und ausreichend Crawl-Budget, versucht
wirklich Javascript auszuführen und den kompletten DOM zu rendern, das Document
Object Model. Also zugucken wirklich was kommt dann nachher als Inhalt der Seite
heraus und bewertet diesen Inhalt und macht nicht nur einfach View Source vom HTML. Also schaut sich nicht den plain geschriebenen HTML-Quellcode an, weil da
kann ja auch nichts drin stehen und durch Javascript-Magie, also durch das
rendern des DOMs und nachladen, kannst Du halt den Inhalt erzeugen.
Das schaut sich Google schon sehr, sehr genau an und Javascript-Links funktionieren.
Allerdings nur was praktisch beim Onload- Event von Javascript stattfindet. Alles
was Du mit Onload machst, das funktioniert und wenn etwas onklick ist, zum
beispiel onklick vom onklick-Event im
Javascript her, wenn du so eine onklick Event oder onklick-Link hast. ARF dann gleich auflöst, das sieht Google zum Beispiel nicht. Oder das
interpretiert Google zum Beispiel nicht. Gibts’ auch einen einfachen Hack oder Work-Around auf die Schnelle jetzt gesagt gibts’ noch andere verlässlichere
Methoden. Man guckt einfach im Google Cache was
für Inhalte stehen da drin? Und man weiß ja welche Inhalte seiner Seite mit
Javascript nachgelagerten werden oder injected werden oder wie Du die Links
maskiert hast und wenn dann diese Links oder diese Inhalte dort auftauchen dann
konnte Google praktisch den DOM rendern und das Ergebnis daraus lesen
und indexieren. Und fehlen dann Passagen oder interne Links, dann weißt
Du mit Sicherheit Google konnte das entweder nicht finden, nicht ausführen
oder hat es schlichtweg nicht gesehen. Wie Du das dann anwendest das ist
halt Deine Sache. Zum Guten zum Bösen. Eher zum Guten, alles kann nichts muss.
Genau. Und gibts’ irgendwelche Tricks wie ich rausfinden kann was Google von mir
sieht und was nicht? Also diese Javascript-Geschichten. Klar, am einfachsten ist die Google Search Console. Kostenloses Produkt von Google. Soll bitte jeder nutzen. Da gibt
es die Funktion fetch-and-render, früher glaube ich noch mal Abruf wie durch Google,
oder Abruf mit dem Googlebot auf Deutsch
irgendwie so übersetzt. Da kann man erstmal prüfen, kann Google alle
Ressourcen so was wie Javascript, CSS- Dateien meiner Webseite halt einsehen.
Das muss nämlich Google können, um dann die Inhalte auch darstellen zu
können und bewerten zu können und Google gibt einem dann auch
den gerenderten Output zurück in einem Vorschaufenster. Man sieht auch wirklich genau was
was Google interpretiert hat? Ja, genau Google bemüht sich dann
Javascript halt auszuführen je nachdem was Du für ein Framework dahinter hast. Das wird alles berücksichtigt. Wird der DOM gerendert. Dann das ganze Composite,
zusammengebaut, gelayoutet und wenn Du dann da schon siehst: oh da sind Bilder nicht
drin oder du hast eigentlich einen Slider damit mehreren Bildern, da ist jetzt aber
nur ein Bild vorhanden da lässt sich nicht drücken und so weiter und so fort.
Hat Google sehr wahrscheinlich mit ein Fallback benutzt. Kannst du jetzt ganz
kurz erklären was DOM bedeutet? Ja DOM ist praktisch das Document Object Model. So
gesehen was immer zu Stande kommt oder erzeugt wird, wenn
ein HTML-Quellcode verarbeitet ist und früher war es einfach so Du
schreibst einfach nur HTML-Quellcode von mir aus mit Javascript oder ohne das hat
keine Auswirkungen. Und Google hat sich praktisch einfach nur wie man in
jedem Browser view Source machen kann, den HTML-Quellcode angezeigt. Das
einfach das CSS, das Layout, die Farben, die Bilder weggelassen und den reinen
Text gelesen. Und AHREFS im HTML- Markup ist ja praktisch dann auch
einfach “plain Text” so gesehen. Konnte man einfach auslesen und wenn Du jetzt ein
Javascript-Framework benutzt zum Beispiel Angular.js oder React. Dann kannst du
praktisch deinen HTML-Quellcode aus Markup manipulieren nachträglich nachdem das Markup vom Server angefordert wurde, dann wird nämlich praktisch noch das
Framework, jetzt vereinfacht gesagt, getriggert und lädt dann nachträglich alle
Informationen rein in das Document Object Model. Und dann wird das ganze
gerendert, zusammengebaut, mit Farben und Grafiken zu versehen und das ist dann
der letztendliche Output oder der vollwertige Inhalt der gesamten Seite. Also
alles zusammengepackt sowie? Alles zusammengebaut wird also wie Google es versteht? Genau, wenn man da ein bisschen nachlesen will so so Geschichten wie
Critical Rendering Path gibts’ da. Was passiert eigentlich nach dem Networkaufruf, nach dem Motto es wird angefragt beim Server: Hey der Domainname ist
das die IP? Ja , ist es. Was liegt darauf? Ja dieses Dokument, das hat einen Stylesheet das hat eine Javascript-Datei und in dem HTML-Markup Dokument gibts’ den und den Inhalt. Das Stylesheet macht dann die und die Farben und die Pixel an der
Varianten werden angeführt und Javascript macht dann eben die Magie
und füllt dann zum Beispiel leere Platzhalter im HTML-Quellcode, die man
natürlich dann definiert hat, magischerweise nachdem der Quellcode
gelesen wurde also von HTML-Markup nachträglich mit Inhalt auf. Und das ist
die ganze Magie. Hat natürlich auch bei der Entwicklung ist das unglaublich
Zeit und Nerven schonend, weil ich muss nur einmal wirklich ein HTML-Template
schreiben, damit CSS ein bisschen stylen und formen. Und
eigentlich kann ich fast jeglichen Inhalt nur wenn ich nicht nur einen Klick
mache, sondern ein Onload-Event. Da reinladen und Google mit sehr, sehr
großer Wahrscheinlichkeit kann das nahtlos sehen, verstehen, bewährten,
in den Index aufnehmen, verschlagworten, also gewichten schon vorab, wofür bin ich
relevant? Wie hoch ist die Autorität? Und am Ende dann natürlich kommt anders das Ranking
aus dem Index bei raus, wenn eine Suchanfrage gestellt wird. Und was hat das
Ganze dann wenn ich mir überlege, dass Google das ganze Framework einmal
abspeichern und sich dann nur noch die Javascript Inhalte reinholt. Was hat das
für Auswirkungen auf die Performance? Natürlich wenn du ein Javascript
Framework benutzt die gängig sind so Angular.js Version 1 oder Version 2 oder das
React Framework von Facebook. Es ist natürlich ressourcenaufwendig. A: kann man jetzt sagen vom Prozessor, von der physischen Maschine her. Super viele
Webseiten Inhalte werden auf Shared-Hosting -Systemen gehostet. Das heißt auf einer
physischen Hardware tummeln sich 100 oder bis zu tausend andere Kunden, die
ihre Domains und Informationen halt ausgeliefert haben wollen. In der Regel
ist das aber nicht der Flaschenhals, sondern es kommt dann eben darauf an, wie schnell kann wirklich dieser Critical- Rendering-Path oder das gesamte Rendering des Dokumentes vonstatten gehen. Es gibt zum Beispiel wenn man das http 1.1
Protokoll benutzt, was noch sehr, sehr weit verbreitet ist, hat man immer nur
acht Requests parallel. Und jede Anforderung an den Server zeig mal HTML-Dokument! Lade mal eine CSS-Datei! Lade die andere CSS-Datei! Lade die Javascript Datei! Lade drei Bilder! Dann bin ich schon bei 6 Requests und Du
kannst Dir ja vorstellen, wenn Du dann viele Bilder viele CSS-Dateien, viele
Javascript-Dateien hast, dass dann die Anforderungen aller Ressourcen
exponentiell lang wächst und natürlich sagt dann Googlebot oder auch der
Browser immer gibt mal erst alle Informationen! Damit ich dann im Rendering-Path das
sinnvoll nacheinander aufbauen kann und zusammen stückeln kann und die Lösung
dafür wäre dann http2 oder was? http2 ist natürlich eine Lösung. Da gibt
es nämlich praktisch die Limitierung auf 8 simultane Requests nicht. Das heißt da kann ich viel mehr Bandbreite durchjagen. Wenn man auf http2 wechselt,
bitte sofort https-Protokoll mit verwenden, sonst funktioniert das ganze
nicht und wenn man schon so weit ist, dann am
besten direkt PHP7 und Laravel mitbenutzen. Das ist dann Topnotch alles, noch von der Cookie Local Domain nach laden lassen. Protipp. Und
dann ist man eigentlich dann bist Du schon sehr tief drin in der Performance.
Schrägstrich sogar Webserver-Optimierung so gesehen. Das kann man natürlich machen. Das sollte auch zukünftig jeder
Seitenbetreiber nicht nur größere Shops, sondern auch von mir aus gerne kleine
und auch private Leute da hingehen, weil das ist einfach nur eine Erleichterung
und ein Geschwindigkeitsboost. Man kann aber natürlich so schöne Sachen
machen wie wirklich nur eine Javaskript-Datei verwenden. Diese bitte auch in sich
selber komprimieren, also komprimieren heißt entweder weniger Leerzeichen im
Code haben oder praktisch die Codezeilen hintereinander weg schreiben.
Bitte keine Fehler im Javaskript schreiben. Ich komme noch aus der Zeit wo
sonst hängt sich das Ganze auf wieder genau wo W3C Validator und Tidy und all so
was der heißeste Scheiß waren das heißt es wenn du dann Null Punkte im W3C
bei XHTML Standard 1.1 hattest dann warst Du so der King und konntest dann dein Widget, was einen Backlink gesetzt hat damals, auf deine Seite knallen. Das war damals das Geilste.
das gilt heute, ich bin ein Freund vom sauberen Markup, es gilt aber auch
explizit für Javascript-Quellcode Da bitte keine Fehler
auch keine Warnungen rein machen. Das muss wirklich beim durchlaufen, man kann das ja in der Develop-Console eines jeden guten Webbrowsers einfach mal
durchlaufen lassen, da sollte wirklich kein Fehler, also nur
das was nötig ist? Nur das was nötig ist. Am besten immer nur eine Datei, die
komprimieren, minifien. Am besten dann auch noch so eine Datei oder der Inhalt
einer Javascript- oder CSS-Datei ändert sich in der Regel auch nicht wirklich.
Dann kann man ein langes Verfallsdatum Mhd wie zum Beispiel bei Lebensmitteln
kann man dann Google mitgeben und sagen: Pass mal auf die Datei brauchst du dir einmal ziehen und dann ist die zwei Wochen, vier Wochen, Vier Monate gültig, wenn das genau
solange sich nichts ändert. Das gleiche gilt irgendwo noch, gilt
auch für HTML-Dokumente. Da kannst Du ja auch einen Timestamp in den Head
reinschreiben. Zu wann sich der Inhalt der Seite letztendlich geändert
hat und Google hat letztlich noch mal bestätigt, dass die doch bei sehr großen
contentlastigen Seiten genau auf diesen Timestamp achten, war mir gar nicht
so bewusst, aber ist auch eine schöne Sache, macht auch Sinn, um Ressourcen zu sparen, von Google. Absolut, darum geht es ja was sagst du dann, das Thema Crawling-Budget? Kommt mittlerweile jeden Tag, alle zwei Tage irgendwo durch die Blogs oder bei Facebook. Was sagst Du dazu? Wer soll auf sein Crawling-Budget achten?
Jeder oder nur große Seiten, Shops? Was sagst Du dazu? Erstmal schön, dass das Thema
endlich Anklang findet und viele auch Pionierarbeit leisten und ein bisschen
mehr Verständlichkeit und Aufbereitung der Inhalte bieten und ich denke mal so, um
die Frage gleich zu setzen. Sollte ich irgendwann mal ein Ölwechsel
bei meinem Auto machen oder soll ich überhaupt meine Bude aufräumen oder
soll ich Wäsche waschen ist irgendwie gleich damit gesetzt. Vereinfacht gesagt
du solltest dich auf jeden Fall darum kümmern, weil Crawling-Budget vereinfacht
gesagt, definiert wie viel Zeit und Arbeitsaufwand Google Dir und Deiner Webseite und damit Geld gönnt natürlich. Jede Verarbeitung einer Webseite und die erfassten Informationen kostet Google Geld. Ressourcen, Zeit; Google US-amerikanisches Unternehmen will natürlich die kleinste Violine der Welt spielen, also Geld
verdienen, nicht Geld verbrennen und Google ist natürlich sehr, sehr dankbar
wenn sie schnell und effizient und dann noch wirtschaftlich gehaltvolle und
attraktive Zielseiten deines Webangebotes schnell finden kann.
Das heißt das Crawling-Budget kommt auch Dir zu Gute. Stell dir vor du hast fünf
Seiten: Die Startseite, Widerrufsbelehrung, am Konto anmelden, Impressum und die Kategorieseite für Deine Hauptprodukte. Jetzt gesteht Google Dir ein Crawl-Budget von 15 Sekunden zu. Dein Webserver ist aber ziemlich langsam,
rendert langsam, die Daten werden langsam ausgespielt. Und zum Beispiel durch die Macht, was Google schon mal kostet, genau, was kostet, und die
Macht der internen Verlinkungen hast Du Google davon überzeugt,
missverständlich, dass neben der Startseite, das Impressum, mein Kontologin und praktisch die Widerrufsbelehrung gleich viel Wert sind
wie essentiell zu sizen oder gleich viel Wert sind. Dann sagt Google:
interessant ich schaue mir die vier Seiten an”, vergisst aber die wichtige
Kategorie Seite zu crawlen und dann zu indexieren und was indexiert wird, kann zu ranken. Weil Du eben durch Macht der internen
Verlinkung und zu wenig Zeit im Vorfeld verplempert hast, Google dann entweder
sagt die Zeit ist um. Ich sehe da ist noch eine Seite, aber wahrscheinlich ist
die nicht viel Wert und selbst wenn sie wert, ist meine Zeit ist um. Ich kann und
davon will nicht mehr bei Dir bleiben Ich gehe jetzt weiter zu einer anderen
Webseite. Ist es halt vergeudetes Potenzial und klar also unterm Strich
kann man sagen es geht um Kohle. Für Google steckt da ein wirtschaftliches Ziel hinter und für den Webseitenbetreiber natürlich
auch, all das was indexiert wird kann ranken und ich glaube keiner
will zu seiner Widerrufsbelehrung ranken und du hast natürlich
mittels Crawl-Budget und dann das nächste Thema wäre halt sich die Macht
der internen Verlinkung zu Nutze zu machen. Kannst Du wirklich den Googlebot, also den Crawler von Google, effizient durch dein Angebot steuern und
wirklich sagen: “So hey das sind für mich wirtschaftlich attraktive Landingpages,
weil wenn die ranken kann ich entsprechend Geld verdienen, was das Ziel ist. Dabei sollte das nachhaltige Ziel sein bei den meisten Websites. Wir haben das Thema Performance mal so ein bisschen angeschnitten.
Was zählt für Dich noch dazu? Also wir hatten das eher von der Serverseite kurz angeschnitten. Genau, da bin ich aus Versehen schon reingerutscht, also so ein Begriff ist halt immer Pagespeed. Den würde ich halt immer untergliedern in die Seitengeschwindigkeit und die Ladezeit einer gesamten Seite. Das heißt Seitengeschwindigkeit
wie schnell können wir wirklich die ganzen Assets: Bilder, Javascript-Dateien,
die ganzen Requests eingeholt werden? Wie schnell antwortet der Server? Wie
verlässlich antwortet der Server? Dann die Geschwindigkeit wirklich bis alles
aufgebaut wurde. Bis man Javascript ausgeführt hat. Bis CSS ausgeführt hat.
Bis dann die Inhalte praktisch im arranged wurden also richtig angebaut. Wo steht da
der Inhalt? Wann kommt der Slider darüber? Das kostet ja auch alles Zeit- und
Netzwerkressourcen und man kann halt auf jeder Ebene anfangen zu
optimieren und das Schlusslicht oder das letzte Glied wäre dann wirklich noch
eins tiefer zu gehen weg von seinem CMS, weg von seinen Inhalten. Wirklich auf die
Webserverebene und runter zu gehen. Egal, ob man jetzt Apache, NGX, Lite TPW, oder wie das Ding auch immer heißt oder Gott bewahre den IRS nutzt. Du kannst bei allen Webserver Varianten entsprechend auch nochmal Performance-Optimierungen
durchführen. Cool! Dann haben wir heute eine Menge
mitgenommen. Ich danke Dir zum Wohl nochmal. Danke, dass ich hier sein durfte. Gerne!

3 thoughts on “Technisches SEO: Crawling Budget, Indexing, Performance | morefire Kneipentalk

  1. morefire Online Marketing Post author

    Technisches SEO oder wie Rene sagt: "Das, was unter der Haube ist" ist kein Zuckerschlecken, sondern benötigt etwas Erfahrung.💻🖱 Eine technische Optimierung ist notwendig um zum Beispiel dem Google Bot das effiziente und ressourcensparende Crawling zu ermöglichen. Was sind für Euch wichtige Aspekte, wenn es um technisches SEO geht? ⚡Schreibt es in die Kommentare!

    Reply
  2. Rene Dhemant Online-Marketing Post author

    Danke für das leckere Kölsch und dem spannenden Austausch auf Augenhöhe!

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *