Der Weg in den Google-Index: Was kann schiefgehen? [Search Camp 168]

16. März 2021 | Von in Podcast "Search Camp", SEO

In dieser Episode geht es um wichtige SEO-Basics: Welchen Weg nimmt eine Seite, bevor sie erfolgreich im Google-Index landet? Was kann auf diesem Weg schiefgehen? Und welche Einflussmöglichkeiten hat man auf die einzelnen Prozessschritte?

 

Die wichtigsten Podcast-Links:

 

Der Weg in den Google-Index: Was kann schiefgehen?

Moin! Herzlich willkommen mal wieder zu einer Folge von Search Camp. Ich habe heute ein bisschen ein Einsteigerthema herausgesucht. Ich erklär gleich, warum ich es mir herausgesucht habe. Das Thema ist heute: „Was muss eigentlich passieren, damit eine Seite im Index landet?“ Und natürlich kann man es auch umgekehrt formulieren: „Was kann eigentlich alles passieren, damit eine Seite nicht im Index landet?“

Den schlussendlich muss man sagen natürlich: Es ist wichtig, dass deine Inhalte im Index landen, dass Google, wenn jemand danach sucht, auch diese Inhalte ausspielen kann. Ansonsten ist der wertvollste Inhalt wertlos.

Ich möchte euch heute mal ein klein bisschen so durch den Prozess führen, auch noch mal klären: An welchen Stellen könnt ihr eigentlich eingreifen? Was kann wo schiefgehen?

Ich habe schon gesagt, das ist eigentlich ein Basic-Vortrag, aber ich merke, dass sehr oft dazu Fragen kommen, und ich merke auch oft bei bestimmten Fragen, dass die grundlegenden Konzepte dahinter eigentlich nicht richtig verstanden wurden. Deswegen kann man sagen, aus dem, was ich heute erzähle, folgt erstmal überhaupt nichts, aber ich hoffe, dass es euch weiterbringt in Bezug auf euer Verständnis für Suchmaschinen und in der Folge ihr vielleicht auch ein paar Entscheidungen dann ordentlich treffen könnt.

So! Jetzt gucken wir uns das Ganze mal an. Ich werde euch durch verschiedene Schritte führen, denn damit eine Seite im Index landet, müssen ein paar Sachen hintereinander funktionieren.

  1. Schritt 1 heißt: Discovery. Das heißt, Google muss eine URL erst mal kennen.
  2. Schritt 2 ist Crawling. Das heißt, die Seite wird heruntergeladen von einem Crawler, vom Googlebot.
  3. Schritt 3 ist das Rendern, die Seite wir dargestellt.
  4. Und Schritt 4 ist dann hoffentlich die Indexierung.

Diese 4 Schritte werde ich gleich mit euch durchgehen. Wie gesagt, oder ich versuche, das heute etwas zu vereinfachen, weil ich sage euch, an welchen Schritten ihr wo eingreifen könnt und das ist vielleicht manchmal in einem etwas anderen Schritt verortet, aber damit man es sich leichter vorstellen kann und damit sinnhafter ist, habe ich es jetzt so zusammengestellt, wie ich es hier zusammengestellt habe. Deswegen bitte nicht dafür schelten. Wenn unter euch Suchmaschinenexperten sind, dann könntet ihr vielleicht das eine oder andere anmerken, aber tut ihr natürlich nicht. Ich gehe jetzt mit euch diese 4 Schritte durch und sag mal: Was kann da schiefgehen? Wo habt ihr Einflussmöglichkeiten? Und vor allem: Was ist wichtig?

 

Schritt 1: Discovery

Das heißt: Google muss eine URL kennen. Insgesamt gibt es sowieso immer zwei verschiedene Strategien, die Google fährt. Das heißt, einmal werden sie natürlich Inhalte, die sie schon im Index haben, werden sie aktualisieren. Das ist ein Teil, den der Crawler erledigt. Aber sie wollen natürlich auch neue Inhalte crawlen und indexieren. Und darum geht es jetzt quasi.

Angenommen, ihr habt einen neuen Blogbeitrag geschrieben: Wie kriegt Google den mit? Die einfachste Lösung und typischerweise sind das interne oder externe Links. Das heißt, Google crawlt eure Website, Google kennt eure Website seit Jahren, geht immer wieder auf die Startseite und oh, da ist auf jeden Fall jetzt ein Link auf den neuen Blogbeitrag. Das ist die beste Methode, wie Google eure Inhalte finden kann.

Die zweite Möglichkeit sind XML-Sitemaps. Das ist quasi eine Auflistung aller wichtigen Seiten eurer Website. Das kann in einer Datei sein, das kann über mehrere Dateien verteilt sein, wie auch immer ihr das haben wollt. Ihr könnt Google ein bisschen damit helfen, nämlich, in dieser XML-Sitemap könnt ihr ein Attribut mitgeben und das heißt lastmod. Und lastmod heißt: Wann wurde diese Datei denn das letzte Mal geändert? Natürlich ist es für den Googlebot nicht effizient, wenn sie einfach alle Seiten permanent crawlen und gucken, ob die immer noch da sind, sondern Google wird natürlich irgendwann versuchen oder wird immer versuchen, das Ganze so zu priorisieren. Über das lastmod kann Google sehen, okay, du hast 1000 Seiten auf der Website, aber 995 davon hast du jetzt gerade gar nicht geändert. Also ohne sich die Seite anzugucken, das ist natürlich optimal für Google. Bei 5 ist das Datum auf heute, also renne ich da mal sofort hin und crawle die. Das heißt, wenn ihr dieses lastmod mitliefern könnt, also steht für last modified, letzte Veränderung, dann macht das bitte. Damit könnt ihr wirklich noch mal dafür sorgen, dass Google schneller eure neuen URLs findet und sie dann eben in die nächste Stufe, nämlich in das Crawling, übergibt. Wir sind aber noch beim Discovery, also wie kann Google noch eine URL finden?

Eine andere Möglichkeit wäre zum Beispiel ein Tweet. Das heißt, Google hängt an der Twitter Firehose und es kann sein, dass weil jemand eine ganz bestimmte URL getwittert hat, dass Google das mitbekommt, weil sie eben alle Tweets mitbekommen. Das ist dieser Firehose, der Feuerwehrschlauch von Twitter. Es kann sein, dass sie deswegen dann eine URL crawlen oder dass sie auf anderen Wegen irgendwie das Ding finden.

Es gibt noch eine Möglichkeit, und zwar habt ihr in der Google Search Console das Tool zur URL-Prüfung. Auch damit könnt ihr Google veranlassen, doch bitte jetzt eine bestimmte URL zu crawlen. Das mit dem „jetzt“ ist anscheinend nicht mehr so, sondern es kann durchaus einen halben Tag bis einen ganzen Tag dauern, bis das Ganze gecrawlt wird. Aber genau so könnt ihr Google auch eine bestimmte URL mitteilen. Das ist so im Großen und Ganzen das, was erst mal Google hilft, damit sie die URL erst mal finden.

 

Schritt 2: Crawling

Und dann gehen wir am besten zur nächsten Stufe, nämlich dem Crawling. Also ich habe schon gesagt, es gibt eine Software bei Google, den Googlebot, und der lädt eben Seiten herunter. Das heißt, Google hat über das Discovery eine neue URL gefunden, hat entschieden, dass sie die crawlen möchten heute. Das muss nicht unbedingt so sein, es gibt da sicherlich Pipelines und Queues und so, also wo Sachen irgendwie bewertet werden, was jetzt gerade wichtig ist, was jetzt gerade unwichtig ist, wie auch immer das Ganze funktioniert. Aber angenommen, Google hat sich jetzt entschieden, lädt jetzt diese HTML-Seite herunter. Was könnte alles schiefgehen?

Na, das eine ist natürlich der sogenannte HTTP-Code. Das heißt, alles, was vom Server angefordert wird, liefert eine dreistellige Zahl zurück, und je nachdem welche Zahl ganz vorne steht, sagt das was darüber aus, ob es funktioniert hat oder nicht. Der beste Code ist immer 200, der heißt: okay. Und okay heißt, diese Information, so wie du sie haben wolltest, habe ich dir jetzt gerade perfekt geliefert. Es gibt die Zahlen, wo vorne eine 3 steht. 3 heißt, also zum Beispiel 301 oder 302: Du wolltest die haben, unter der URL habe ich sie nicht, aber unter einer anderen habe ich sie. Dann gibt’s noch die mit einer 4 vorne. 4 heißt: Du wolltest das Ding haben, ich habe es nicht, oder ich habe sie vielleicht, aber ich gebe sie dir jetzt gerade nicht. Und dann gibt’s noch die mit eine 5 vorne, das heißt: Hey! Läuft gerade ganz schlecht. Meinem Server geht’s vielleicht nicht gut. Grad der berühmte Code 503 heißt: Der Server ist gerade down und komm doch bitte morgen noch mal wieder. Also das ist die eine Sache, die passieren kann.

Das Zweite, was passieren kann, es gibt eben die robots.txt und diese Datei verhindert das Crawling von Inhalten. Wenn ich da sowas geschrieben habe wie „disallow: /seite“, werden alle URLs, wo der URL-Pfad mit „seite“ beginnt, nicht dem Crawling zugeführt. Das heißt, nochmal: Google hat sie vielleicht discovered, Google kennt die URL, aber Google darf sie nicht herunterladen. Interessanterweise kann das trotzdem dazu führen, dass sie indexiert wird. Also Schritt 4, kann passieren. Dann wird aber ein so genannter Leereintrag angelegt. Das heißt, da Google die Seite nicht heruntergeladen hat, haben sie unglaublich wenig Informationen über die Seite. Das kann passieren, typischerweise ist das nicht das, was passieren sollte.

Und vielleicht, was auch noch passieren kann, zumindest im Moment noch: In der Google Search Console gibt es, in der alten Google Search Console gibt es einen Report, der heißt „URL Parameter“. Und da könnte ich sagen, wenn dieser URL-Parameter in der URL vorkommt, dann bitte das Ding auch nicht herunterladen. Auch damit könnte ich den Crawler noch beeinflussen.

Grundsätzlich muss man ja immer sagen: Das Crawl-Budget ist begrenzt. Das heißt, Google wird pro Tag soundso viele Seiten, soundso viele Kilo-, Mega-, Gigabyte, wie auch immer, von eurem Server herunterladen. Was euch zusteht, da habt ihr keinen Einfluss drauf, sondern Google berechnet das Ganze quasi basierend auf eurer Website und auf eurem vergangenen Verhalten.

Es ist allerdings möglich, dass der Crawl Demand auf einmal entsteht. Zum Beispiel, ihr macht einen Relaunch und Google erkennt: Hm! Wenn ich dieses Crawl-Budget, so wie ich es bisher hatte, beibehalte, brauche ich fünf Jahre, bis der Relaunch von mir erfasst und indexiert wurde, also lege ich jetzt mal eine Schippe drauf. Falls das aber nicht so ist, also falls ihr jetzt keinen Relaunch habt, dann könnt ihr eigentlich davon ausgehen, dass da immer so ungefähr das Gleiche gecrawlt wird.

Wenn ihr mal wissen wollt, wo ihr da so steht, geht ihr in die Google Search Console, da gibt’s unter „Einstellungen“ die „Crawling Statistiken“ und da könnt ihr euch eben anzeigen lassen, wie viel so gecrawlt wird. Und ihr könnt zum Beispiel auch sehen, wie hoch der Anteil zwischen neuen und alten URLs ist, also zwischen dem, was quasi neu discovered wurde, und dem, was einfach nur eine Überprüfung des Index-Bestandes ist. Also das war Nummer 2.

 

Schritt 3: Rendering

Schritt Nummer 3 ist das so genannte Rendering. Das heißt: Früher war es so, Google hat wirklich nur die HTML-Seite heruntergeladen. Google wusste nicht, wie die Seite dahinter aussieht. Das haben sie einfach nicht gemacht. Das hat dann dazu geführt, dass viele diesen HTML-Code ein bisschen zu Tode optimiert haben. Also zum Beispiel so, dass die Hauptüberschrift wirklich das erste Ding war im HTML-Code und dass der Content ganz vorne platziert wurde, was angeblich wahnsinnig viel gebracht hat.

Heutzutage funktioniert das alles nicht mehr, weil Google die Seite eben rendert. Das heißt: Google lädt den HTML-Code runter, das ist ja schon passiert, und alle Ressourcen, Bilder, JavaScript-Dateien, CSS-Dateien, was auch immer, Fonts, alles, was da noch so dranhängt. Und macht dann genau das Gleiche, was der Browser macht, das heißt, das Ding wird einfach dargestellt.

Und dadurch kann Google natürlich sinnvolle Sachen erkennen, nämlich zum Beispiel, welcher Text ist eigentlich sichtbar. So wie früher, der weiße Text auf weißem Grund, das konnte Google früher nicht erkennen oder nur, ich sag mal, heuristisch. Aber jetzt können sie wirklich erkennen, da ist wirklich Text, der ist weiß auf weißem Grund. Und das ist natürlich ganz hilfreich.

Beim Rendering geht es aber auch darum, dass eben JavaScript heruntergeladen oder ausgeführt wird. Denn JavaScript kann den HTML-Code noch verändern. Das ist natürlich auch ein Thema für den Pagespeed, weil JavaScript hält erst mal das Rendern auf. Soll gar nicht unser Thema sein heute. Sorry, ich schweife ab. Also JavaScript kann den Code verändern.

JavaScript kann zum Beispiel auch Content nachladen. Und genau deswegen ist es eben auch wichtig, dass nicht nur die HTML-Seite angeguckt wird, sondern dass eben auch der JavaScript-Code ausgeführt wird. Das ist also das, was passiert.

Und jetzt ist die Frage: Was kann denn an diesem Schritt schiefgehen? Es kann eine Sache schiefgehen vor allem, und zwar können ganz bestimmte Ressourcen, die wichtig sind, per robots.txt gesperrt sein.

Angenommen, du hast eine CSS-Datei, die brauchst du ja, damit deine Seite ordentlich dargestellt werden kann, und die sperrst du jetzt per robots.txt-Datei. Im Browser wird die immer noch prima funktionieren, weil der Browser kümmert sich nicht um die robots.txt-Datei, der Crawler oder der Renderer aber schon. Das heißt: Google wäre dann nicht mehr in der Lage, die Seite ordentlich darzustellen. Und das könnte eben dazu führen, dass Google manche Entscheidungen nicht mehr treffen kann. Und es kann dann auch dazu führen, dass quasi das Schlimmste von der angenommen wird.

Also deswegen ist es so extrem wichtig, dass die Seite ordentlich gerendert werden kann. Du darfst Ressourcen sperren für Suchmaschinen, überhaupt keine Frage, so Tracking-Skripte und sowas, kannst du alles sperren, aber alles, was wichtig ist für die Darstellung der Seite, darfst du eben nicht sperren.

Was auch noch schiefgehen kann, ist sogenannter Insecure Content oder Mixed Content. Das heißt: Du hast eine HTTPS-Website, hoffe ich zumindest, und auf der bindest du eine HTTP-Ressource ein. Der Browser wird da sowieso sich beschweren. Das ist eigentlich auch im Moment die größte Gefahr, Google hat darauf hingewiesen, dass es in Zukunft auch negative Effekte auf das Rendering haben könnte. Deswegen sollte man das in jedem Fall vermeiden. Also das sind so typischerweise die Sachen, über die man beim Rendern nachdenken sollte. Das war Schritt Nummer 3.

 

Schritt 4: Indexierung

Wenn das Ding gerendert ist, kommt Schritt Nummer 4: Die Indexierung. Was passiert? Die Seite wird zerlegt, das heißt, erst mal legt Google auch vorher noch eine Kopie der Seite an im Cache. Die kann man übrigens auch einsehen über die Suchergebnisse. Dann wird sie in Wörter zerlegt. Ich denke, dass verschiedene Analysen gefahren werden, was da an Content ist und so weiter und so fort. Und dann wird die Seite eben, wenn es richtig gut läuft, in den Index aufgenommen. Das heißt, das ist ja so eine Art Inhaltsverzeichnis und für jedes Wort wird dann gesagt so: Dieses Wort, was da an dritter Position im Content steht, dafür bitte diese Seite oder das kommt in dieser Seite vor. Also man trennt quasi, man hat eine Liste mit allen Wörtern, also weltweit alle Wörter, und rechts hat man eine Liste mit allen Seiten, und zwischen denen zieht man dann so Verbindungen, sodass, wenn ich nach zwei Wörtern suche, kann ich relativ effizient herausfinden, in welchen Seiten das alles vorkommt.

Was kann dabei schiefgehen? Das eine, was schiefgehen kann, ist, die Seite steht auf noindex. Das ist ja ein Robots-Meta-Tag, das kann entweder im HTML-Code ausgespielt werden oder im HTTP-Header, und da steht eben noindex. Und noindex heißt eben genau das, das heißt: Du hast die Seite jetzt discovered, du hast sie gecrawlt, du hast sie gerendert und jetzt schmeiße sie bitte weg. Und genau das wird auch passieren. Es gibt natürlich viele Fälle, wo man das möchte, überhaupt keine Frage, deswegen reden wir auch darüber. Also schiefgehen ist vielleicht das falsche Wort, sondern wo kann man etwas beeinflussen? Natürlich stellt man manche Seiten auf noindex, weil man eben nicht möchte, dass sie im Suchmaschinenindex auftauchen.

Das Zweite, was natürlich auch passieren kann, das ist jetzt nicht so schlimm, aber in meiner Seite ist ein Canonical-Tag, was auf eine andere Seite zeigt. Das macht man typischerweise bei Duplicate Content, dass man eben sagt: Okay! Diese konkrete Seite ist eine Kopie einer anderen Seite. Nimm doch bitte die andere Seite.

Was natürlich auch passieren kann, ist, das muss man übrigens auch ganz klar sagen, dieses Canonical-Tag ist keine sogenannte Direktive. Das heißt, selbst wenn ich das so abbilde und sage, diese Seite enthält Duplicate Content von dieser anderen Seite, kann Google sich trotzdem immer dagegen entscheiden. Das heißt zum Beispiel: Du hast eine ganz bestimmte Nachricht, und auf einer anderen Website ist auch diese Nachricht. Du hast das über das Canonical-Tag vollkommen richtig abgebildet, kann Google sich trotzdem entscheiden, dass es dieses Canonical-Tag ignoriert und anders kanonisiert.

Das passiert nicht so wahnsinnig oft, das kann man in der Google Search Console einsehen, wenn das passiert. Gleichwohl, es kann immer passieren. Das heißt: Google kanonisiert, Google versucht, Dubletten zu vermeiden, sowohl intern als auch extern, und kann sich dann eben, wird sich an diesem Punkt irgendwie entscheiden. Das heißt: Wenn es meine Seite noch 30-mal im Netz verteilt gibt, dann habe ich eine relativ gute Chance, dass sich eben nicht für meine Seite entschieden wird, sondern dass sie vielleicht einfach entweder verworfen wird oder dass eben eine Kanonisierung auf eine andere Seite stattfindet.

Stichwort „Verwerfen“, was auch passieren kann, ist, dass Google sich meine Seite angeguckt hat und sagt: Oh! Die ist ja irgendwie blöd. Das heißt, aus welchen Gründen auch immer, Google kann sich dafür entscheiden, meine Seite jetzt noch wegzuwerfen, vielleicht habe ich keinen Content drauf, vielleicht habe ich miserablen Content drauf, oder wegen Duplicate Content. Und das sieht man in der Google Search Console ganz nett im Report „Abdeckung“, und da gibt es den Filter „Gecrawlt, nicht indexiert“. Das heißt: Google hat die Seite heruntergeladen, hat sie auch gerendert und fand sie dann nicht so besonders. Und das ist ein ganz, ganz, ganz typischer Fall, wenn man halt wirklich eine miserable Content-Strategie hat oder wenn man auch viele Dubletten hat, dann sieht man diese Fehlermeldung leider sehr häufig. Auch vollkommen zu Recht dann natürlich.

Was könnte noch passieren? Es könnte noch ein so genannter Soft 404 passieren. Das heißt, Soft 404 heißt: Google sieht die Seite und entscheidet dann, dass diese eigentlich eher wie eine 404-Seite aussieht, also dass es diese Seite gar nicht mehr gibt. Das passiert zum Beispiel bei Online-Shops, wenn ich eine Produktdetail-Seite habe und das Produkt ist nicht mehr lieferbar. Dann kann es passieren, obwohl diese Seite korrekt gecrawlt, gerendert wird, kann es passieren, dass Google sie dann trotzdem als sogenannten Soft 404 einstuft und sie dann eben nicht indexiert. Passiert nicht immer und nicht immer zielgenau und nicht immer gleich am ersten Tag, aber es kann eben ganz genau passieren. Soft 404 ist so ein relativ blödes Thema, gleichwohl, eigentlich ist es gar nicht mal so schlimm, denn Soft 404 heißt ja, Google hat sich dafür entschieden quasi, diese Seite zu entfernen, zum Beispiel, weil das Produkt nicht mehr lieferbar ist, aber ich habe dadurch erst mal jetzt keinen Malus. Also das heißt, die Seite wird entfernt, aber das wäre sie auch sonst, wenn ich eine 404 ausgeliefert hätte. Und von daher muss man bei vielen Sachen sagen, Soft-404-Fehler sind jetzt nicht so wahnsinnig schlimm. Man muss sich das natürlich angucken, warum die passieren, aber in der Praxis kann man die auch relativ gut aussitzen.

 

Finale

Ja, das war’s eigentlich schon. Das waren diese 4 Schritte, wie gesagt: Discovery, Crawling, Rendering, Indexierung.

Ich wünsche euch natürlich ehrlich gesagt, dass ihr diese 4 Schritte immer schön von oben nach unten durchmacht mit eurer Website, dass ihr immer perfekt im Index seid.

Mein wichtiger Hinweis an dieser Stelle ist: Beschäftigt euch mit der Google Search Console, mit dem Report „Abdeckung“. Weil da könnt ihr wirklich Hinweise kriegen, entweder warum Sachen nicht indexiert wurden oder warum Sachen beim Crawling fehlgelaufen sind. Die Search Console wird euch nicht alles sagen, zum Beispiel das mit dem Mixed Content oder mit dem Insecure Content, das seht ihr dort nicht, aber so klassische Sachen wie, Inhalte stehen auf noindex, beim Canonical-Tag war irgendwas blöd, genau das könnt ihr da alles einsehen. Und deswegen natürlich immer der Hinweis: Beschäftigt euch damit, dafür ist die Google Search Console auch wirklich da.

Aber jetzt wieder zurücknehmen, was ich eben schon gesagt habe: Damit beschäftigen, ja, nicht ausrasten ist trotzdem ganz wichtig, weil oft sind da irgendwie, weiß nicht, du hast eine Website mit 10.000 Seiten und bei zwei Seiten ist irgendein blöder Fehler aufgetreten. Und Leute, ich krieg‘s ja mit, weil ich kriege die alle in der Sprechstunde oder viele sprechen mich auch mal so an, und beschäftigen sich da ewig mit, was überhaupt keine Relevanz hat und was wirklich nur Zeit verbrennen ist. Deswegen drauf gucken, aber nicht ausrasten deswegen.

Mehr zu diesem Thema:
Nächste Events

Nächste Webinare

Alle kommenden Webinare

Nächste Seminare

Alle kommenden Seminare

The following two tabs change content below.
Avatar-Foto
My Instagram profile

Markus Hövener

Markus Hövener ist Gründer und SEO Advocate der auf SEO und SEA spezialisierten Online-Marketing-Agentur Bloofusion. Als geschäftsführender Gesellschafter von Bloofusion Germany ist er verantwortlich für alle Aktivitäten in Deutschland, Österreich und der Schweiz. Markus Hövener ist Buchautor, Podcaster und Autor vieler Artikel und Studien rund um SEO.

Markus hat vier Kinder, spielt in seiner Freizeit gerne Klavier (vor allem Jazz) und genießt das Leben.

7 Kommentare zu “Der Weg in den Google-Index: Was kann schiefgehen? [Search Camp 168]”

  1. Avatar-Foto Gunnar Seidel
    März 16th, 2021 at 20:02

    Sehr guter Input ich bin ein großer Fan

  2. Avatar-Foto Markus Hövener
    März 17th, 2021 at 08:42

    Dank Dir!

  3. Avatar-Foto Melvin Rueth
    April 8th, 2021 at 03:07

    Danke für den Beitrag!

    Wir bevorzugen vor allem die Variante via Google Search Console, um eine neue URL zu indexieren. Allerdings kann es hier dann erfahrungsgemäß doch auch wesentlich länger als nur einen halben Tag dauern, bis die entsprechende URL dann auch tatsächlich im Index ist.

  4. Avatar-Foto Pascal
    April 9th, 2021 at 03:42

    Um die Indexierung zu beschleunigen, macht es ebenfalls Sinn die neu erstellte Seite auf Social Media Kanälen zu posten. Google crawled diese bereits sehr stark und kann dadurch die Seite schnell finden.

    Vor allem Twitter eignet sich besonders gut, um Google zu helfen die neue Seite zu finden. Nachdem man die Seite in einem Link dort geteilt wird Google die Seite schnell finden, da Twitter Google über neue Posts direkt informiert.

    Das ist aber eher nur ein kleiner Hack oder eine Hilfestellung, die genannten Punkte hier sind natürlich von größerer Bedeutung.

  5. Avatar-Foto Melvin
    April 15th, 2021 at 04:07

    Hallo Pascal,

    das Content Seeding via Social Media macht natürlich nicht nur Sinn, um neue Seiten schneller indexieren zu lassen, sondern auch, um den entsprechenden Beitrag bekannter zu machen. 😉

    Freundliche Grüße,
    Melvin

  6. Avatar-Foto Markus Hövener
    April 15th, 2021 at 07:43

    Das sowieso 🙂

  7. Avatar-Foto Niko
    Dezember 22nd, 2023 at 15:44

    Hallöchen, bin durch Zufall auf dein Blog gestoßen, weil ich mich gerade selber mit dem Thema beschäftige. Vielen Dank für deinen Beitrag, hat mir um einiges geholfen!

Kommentieren