Hier findet Ihr das deutsche Transkript des Google Webmaster Hangout vom 27. Juli 2018:
Canonical-Tag
Zeit: 0:23
Frage: Ich bin Produktmanager für einen großen Website-Provider und eine digitale Werbeplattform im Bereich Automotive und wir sehen einige Schwankungen bei Cross Canonical und Cross Cashing. Ein Beispiel ist: Ich mache eine Site- Suche auf einer unserer Domains. Einige der angezeigten Ergebnisse zeigen Daten von einer anderen Website auf unserer Plattform. Wenn wir diese Seiten in der Suchkonsole überprüfen, heißt es, dass Google ein anderes Canonical als der Nutzer gewählt hat. Wenn ich den Google-Cache dieser Seiten überprüfe, wird die andere Website angezeigt, von der die Daten abgerufen werden. In vielen Fällen gibt es die Inhalte völlig anders wieder: Zum Beispiel habe ich eine Seite, wo die Mitarbeiter alle aufgeführt sind, mit Bildern, Telefonnummern der Abteilung etc., aber Google sagt „nein das ist nicht die Canonical, diese Seite dort ist es“ und dies ist dann eine völlig andere Filiale in einem anderen Land. Und die Seite, die Google als das Canonical auswählt ist leer, keine Mitarbeiter, keine Telefonnummern, nichts. Die angezeigte Filiale benutzt diese Seite nicht einmal. Daher möchten wir nun wissen warum das passiert und wie wir es lösen können.
Antwort: Da muss ich mir auch die genaue URL anschauen. Im Allgemeinen, was hier evtl. passiert ist, dass wir versuchen doppelten Inhalt in verschiedenen Phasen unserer Pipeline zu erkennen. Nach der Indexierung haben wir ggfs. gesehen, dass die Seiten fast gleich sind und wir sie somit zusammenfassen können. Dies machen wir im Wesentlichen schon vor dem Crawlen, wenn wir basierend auf der Vergangenheit zwei URLS betrachten und glauben, dass diese beiden URLs anscheinend gleich sind. Das macht normalerweise Sinn, wenn wir klare Muster besonders innerhalb einer Website erkennen können, in der wir sehen können, dass alles in dem Unterverzeichnis dasselbe ist wie in der Subdomain, schon allein wegen der Art, wie das Hosting eingerichtet wird. Wir können also blindlings davon ausgehen, dass diese URLs gleich sind, ohne sie wirklich anzusehen. Gerade bei diesen Website-Providern, welche oft verschiedenen Websites mit dem gleichen Hosting-Setup haben und die Seiten auf eine ähnliche Weise eigerichtet sind, kann das passieren.
Das ist ein Fehler unsererseits, den wir beheben müssen. Wir bearbeiten das mit Eurer URL direkt.
HTTP zu HTTPS
Zeit: 11:34
Frage: Wir sind vor ca. einem Jahr von HTTP zu HTTPS umgezogen, seitdem sind unsere Bewertungen schlechter.
Antwort: Wenn wir solche Umzüge sehen, hat es meistens mit den wiederkehrenden Problemen zu tun, die bereits des Öfteren besprochen wurden. Jedoch geht es in diesem Falle darum, dass dies im Laufe eines Jahres passiert ist. Der Abfall des Rankings hat wahrscheinlich nichts mit dem Umzug von HTTP zu HTTPS vor einem Jahr zu tun, eher mit der Website selbst, mit den normalen Such-Rankings, Änderungen die Ihr im Laufe des Jahres vorgenommen habt oder ähnliches.
multilinguale Websites
Zeit: 13:01
Frage: Wie sieht es aus mit englischen Anfragen bei nicht-englischen Websites? Z. B. Wenn man nach „Game of Thrones“ sucht und es gibt eine tschechische Website, welche Informationen zu „Game of Thrones“ anbietet. Wie wird sichergestellt, dass Google diese Seite rankt? Wie geht Google mit dem Umschalten der Sprachen um?
Antwort: Im Allgemeinen empfehlen wir eine Hauptsprache auf einer Seite zu haben, aber wir können auch mit mehrsprachigen Seiten umgehen. Das kann etwas sehr Natürliches sein. Der Titel ist beispielsweise „Game of Thrones“ und der Rest der Seite ist auf einer nicht englischen Sprache. Ein typischer Fall zu diesem Thema sind zum Beispiel Urlaubs-Websites. Es geht um Wohnungen in Spanien, aber die Seite ist auf Englisch. Dennoch sind natürlich die Städte auf Spanisch, die Straßennamen, oder auch die Restaurantnamen. Wenn unser Algorithmus diese Seite sieht, erkennt er sowohl englischen, als auch spanischen Inhalt, trotzdem sagen wir nicht, dass dies definitiv eine spanische Seite ist, die wir nicht in den englischen Anfragen zeigen wollen. Wir sagen aber auch nicht, dass dies definitiv eine englische Seite ist, die wir nicht in den spanischen Anfragen anzeigen. Wir versuchen, die verschiedenen Sprachen, die wir auf einer Seite finden, zu berücksichtigen. Also ist es in der Praxis nichts Unmögliches für uns zu ranken. Ich gehe davon aus, dass unser Algorithmus versucht, in diesen Fällen eine Balance zu finden.
In dem Fall der tschechischen Website sehe ich beim Design nichts, das verhindern könnte, dass diese Seite für solche Anfragen ranken kann. Ich würde hier weiter dran arbeiten, das sieht alles sehr gut aus.
Umzug
Zeit: 15:49
Frage: Wir planen, eine Subdomain in ein Unterverzeichnis umzuziehen, und derzeit ist „noindex“ gesetzt.
Antwort: Dieser Fall ist etwas verzwickter, als ein normaler Umzug. Einerseits, wenn Ihr im Moment ein "noindex" gesetzt habt und Ihr diese Seite später umleiten möchtet, dann ist das wie eine andere Ebene der Komplexität, die dort in Bezug auf das Verschieben hinzugefügt wird, weil wir zuerst den "noindex" verarbeiten und uns denken: "Oh, hier gibt es nichts zu indexieren." Normalerweise reduzieren wir das Crawlen dieses Inhalts ein wenig, weil wir denken: "Wenn wir es nicht indexieren können, müssen wir es nicht so oft crawlen." Wenn man dann an diesem Punkt Weiterleitungen einstellt, brauchen wir dann etwas länger diese Weiterleitungen zu verarbeiten und die Dinge zu verschieben.
Fragesteller konkretisiert seine Frage: Eine Seite wurde in eine größere Website gesteckt, quasi als Abschnitt auf einer größeren Website hinzugefügt.
John: Das ist dementsprechend absolut kein Problem. Wir würden das jedoch nicht als einen Seitenumzug sehen, wir würden diese URL Umzüge individuell bearbeiten. Was Ihr tun könnt, um uns dabei zu helfen, ist möglicherweise eine Sitemap-Datei für die alten URLs und für die neuen URLs zu erstellen (vielleicht mit neuen Änderungsdatum), so dass wir die alten URLs ein wenig schneller crawlen können bis sich alles eingependelt hat. Wenn der alte Teil dann wieder indexierbar ist, können wir entweder die alte Version oder die neue Version indexieren und während dieser Migration von einem Teil zum anderen wird es immer noch sichtbar sein.
Lazy Loading Images
Zeit: 20:48
Frage: Empfehlungen zum verzögerten Laden von Bildern: Kann eine Image-Sitemap alle potenziellen Probleme beheben, während sichergestellt wird, dass Bilder gleichzeitig gecrawlt und indexiert werden können?
Antwort: Die aktuelle Empfehlung, die wir für Lazy-Loaded-Images haben, besteht darin, ein Image-Tag in ein „noscript“-Element unter dem Lazy-Loaded-Element zu setzen, so wie Ihr es auch getan habt. Auf diese Weise können wir definitiv verstehen, welche Bilder wo hingehören, wo sie gezeigt werden sollten und wir können diese normal verarbeiten und indexieren.
Eine Image-Sitemap kann uns etwas helfen, aber es löst nicht das Problem, uns Inhalt zu dem Bild zu geben. Mit der Image-Sitemap könnt Ihr uns mitteilen, dass sich diese Bilder auf dieser Seite befinden. Wir können diese Bilder mit der Landing Page verknüpfen, aber wir bekommen keine weiteren Informationen über diese Bilder. Insbesondere bei Bildern könnt ihr uns einen Alt-Text geben, Ihr könnt das Alt-Attribut verwenden, um uns eine Beschreibung des Bildes zu geben. Ihr könnt Überschriften über dem Bild oder Untertitel unter dem Bild, Text um das Bild herum auf der Seite haben, und all das hilft uns besser zu verstehen, wie dieses Bild in die Seite passt. Das sind Dinge, die wir verlieren würden, wenn wir nur das Bild in der Sitemap-Datei hätten. Wenn Ihr Euch also sicher sein wollt, dass Ihr in der Google-Bildersuche gefunden werdet, müsst Ihr klarstellen, dass Ihr uns so viel zusätzlichen Inhalt um das Bild herum bietet, wie es nur möglich ist.
Pop-Ups
Zeit: 23:54
Frage: Gibt es ein Risiko für Rankings, wenn wir oberhalb des Home-Bereichs und über alle unsere Artikel auf der Website eine Standard-Nachricht für Benutzer platzieren, die dazu aufruft ein Abonnement abzuschließen?
Antwort: Das hört sich ziemlich nach einem Interstitial oder etwas Pop-Up ähnlichen an, daher wäre ich etwas vorsichtig damit. Wenn der Nutzer etwas sucht, geht er davon aus, etwas Brauchbares zu finden. Trifft er aber jetzt auf eine Seite, die Google ihm vorschlägt, wo er erst mal dazu aufgefordert wird einen Newsletter zu abonnieren, bekommt er wahrscheinlich das Gefühl, dass Google ihn zu einer falschen Seite geleitet hat.
Google Search Console
Zeit: 26:09
Frage: Ich kann keine URL an das Google-URL-Tool senden.
Antwort: Wir haben das vor kurzem noch bei Twitter besprochen. Wir haben die öffentlichen nicht signierenden Versionen des URL-Tools für die Übermittlung verschoben.
Wir haben gerade einige Probleme mit diesen Tools gesehen und wir haben entschieden, dass es hier der beste Ansatz ist zu sagen, dass dieses Tool innerhalb der Suchkonsole eine Möglichkeit ist. Ich würde also empfehlen, die Suchkonsole zu durchsuchen und das Tool "Fetch as Google" zu verwenden, um die Indexfunktion dort einzureichen. Falls Ihr Eure Website noch nicht bei Google Serach Console verifiziert habt, wäre das somit ja ein guter Grund mal zu tun. Wenn Ihr Eure Website in der Search Console nicht verifizieren könnt, würde ich mal mit dem Host sprechen, damit ggfs. etwas im Setup verändert werden kann, um die Seite für die Search Console zu verifizieren. Wir haben eine Reihe von Möglichkeiten zur Verifizierung in der Suchkonsole. Wenn Ihr also beispielsweise kein Meta-Tag zu eurer Seite hinzufügen könnt, könnt Ihr vielleicht etwas mit den DMS-Einstellungen machen. Vielleicht könnt Ihr etwas mit dieser Datei machen, die ihr dort kopieren könnt. Es lohnt es sich mal verschiedene Möglichkeiten zu prüfen.
em-Tag
Zeit: 29:07
Frage: Unterscheidet Google starke und dicke Tags? Werden diese mehr gewichtet oder beide ignoriert? Was ist mit dem em-Tag?
Antwort: Früher gab es dort mal Unterschiede, aber essentiell sind sie alle gleich. Wenn Ihr also Inhalte auf einer Seite hervorhebt und uns somit mitteilen wollt, dass dieser Teil besonders wichtig für Euch ist, würden wir euch das auch glauben. Es ist ähnlich wie mit Überschriften, hier erkennen wir auch an Überschriften oder Unterüberschriften und an den Texten, was zusammengehört und was nicht. All diese Dinge geben uns etwas mehr extra Informationen über den Inhalt auf der Seite. Also würde ich mir nicht zu viele Gedanken darüber machen, welche dieser Tags Ihr verwendet, um Inhalte auf einer Seite zu betonen. Manche Leute unterstreichen, manche markieren fett, manche benutzen beides. Es liegt an Euch!
Titel
Zeit: 30:32
Frage: Wie entfernt man Seiten-Namen, die im Titel erscheinen, wie zum Beispiel bei .com-Anfragen?
Antwort: Ich bin mir nicht sicher wie Ihr das meint. Was die Leute im Allgemeinen manchmal abschreckt, ist, dass unsere Algorithmen versuchen zu erkennen, wann es sinnvoll ist, einen Titel in den Suchergebnissen neu zu schreiben. Das machen wir hauptsächlich wenn wir denken, dass der Titel, der auf der Seite angegeben ist, nicht wirklich klar ist oder eher wie eine Auflistung an Schlagwörtern wirkt. Vielleicht ist der Titel sehr lang und wir müssen ihn etwas kürzen. Dies alles könnten Gründe sein, dass wir Titel abändern, damit der Nutzer bei der Suche auch erkennt, dass diese Seite relevant sein kann. Hier gibt es keinen Weg um Google dazu zu bringen, dies nicht zu tun, wie z. B. durch Meta-Tags oder ähnlichem. Am besten ist es, direkt die Titel auf Euren Seiten besser zu machen, je kürzer und beschreibender Eure Titel sind, desto höher ist die Chance, dass wir sie sie benutzen.
Mobile-Speed-Ranking
Zeit: 33:27
Frage: Gibt es irgendeine Verbindung zu dem lokalen Mobile-Speed-Ranking-Faktor und den Statistiken in der Google-Suchkonsole?
Antwort: Im Allgemein nein. Wenn es um die Mobile-Speed-Ranking-Änderung geht, betrachten wir eine Reihe verschiedener Faktoren. Einige werden basierend auf dem berechnet, was wir auf Euren Webseiten bestimmen können und einige basieren auf tatsächlichen Messungen, die wir gesehen haben. Die Crawl-Statistiken, die Ihr in der Suchkonsole seht, basieren ausschließlich auf dem Crawlen einzelner URLs, während die mobilen Geschwindigkeiten darauf basieren, dass die gesamte Seite auch auf alle eingebetteten URLs gerendert wird. Das sind also zwei verschiedene Dinge.
Eure Frage hört sich danach an, dass Ihr langsame, bzw. schlechte Zahlen in eure Crawl-Statistiken seht und dies einen Effekt darauf haben kann, wie Google die Geschwindigkeit Eurer Seite sieht. Wenn Ihr eine langsame Crawl-Nummer habt, kann dies Auswirkungen darauf haben, wie schnell wir Inhalte von Eurer Website crawlen und Indexieren. Wenn Ihr beispielsweise im Crawl-Statistik-Bereich Zahlen seht, die ein paar Tausend Millisekunden umfassen, um einzelne URLs von Eurer Website zu crawlen, dann bedeutet das für uns, dass etwas mit eurer Website nicht stimmt und es würde wahrscheinlich dazu führen, dass wir nicht so schnell crawlen könnten, wie wir es sonst könnten. Wenn Eure Seite oft neue und aktuelle Inhalte hat und wir diese nicht schnell genug crawlen können, kann es passieren, dass wir einige neue Inhalte verpassen. Demnach lohnt es sich hier etwas zu verbessern.
Migration
Zeit: 36:46
Frage: Eine Seite soll in ein Unterverzeichnis migriert werden, das Tool dafür ist nicht verfügbar.
Antwort: Das ist ähnlich wie einige vorherige Fragen. Wenn wir einen klaren Seitenwechsel von einer Domain zur anderen erkennen oder von HTTP zu HTTPS, dann macht es uns das um einiges leichter, da man das Umzugs-Tool in der Search Console benutzen kann. Wenn alles wirklich sauber konfiguriert ist, können wir das in der Regel sehr schnell bearbeiten. Hingegen jedoch, wenn Ihr Dinge in Unterverzeichnisse verschiebt oder in Unterdomains, quasi Seiten innerhalb einer Website zusammen mixt, kann die Bearbeitung länger dauern. Ihr müsst wirklich darauf achten alle Weiterleitungen richtig zu setzen, uns die alten und neuen URLs, vielleicht mit einer Sitemap-Datei, richtig erkenntlich zu machen. Wir haben eine Menge an Informationen über Seitenumzüge im Allgemeinen im Help Center notiert. Ihr solltet dort einmal reinschauen und eine Check-Liste erstellen und versuchen, so viele Punkte wie möglich davon einzuhalten.
Mobile First Indexing
Zeit: 43:30
Frage: Unsere Desktop-Navigation hat viele Kategorien und aufgrund technischer Schwierigkeiten hat unsere mobile Version nicht so viele. Ist es möglich, dass wir einige Rankings verlieren, wenn wir zu Mobile First Indixing wechseln?
Antwort: Ja, theoretisch ist es möglich. Wenn Ihr also wirklich eine separate mobile Website habt, also nicht nur ein Responsive Design, wo Ihr den gleichen Inhalt nur unterschiedlich sichtbar macht, wenn es wirklich eine separate mobile Website ist und die interne Verknüpfung ist schlechter als die Desktop-Website und wir auf Mobile First Indexing für diese Website wechseln, werden wir diese mobile interne Verlinkung für Eure Website im Allgemeinen verwenden. Wenn also diese interne Mobilverknüpfung schlechter ist, wenn es wirklich weniger Verbindungen gibt, wenn wir den Kontext nicht richtig ermitteln können, könnte dies theoretisch die Art und Weise beeinflussen, in der wir Eure Seite indexieren und ranken. Daher würde ich das mal doppelt checken.
Viele der Tools zum Crawlen von Websites unterstützen jetzt auch mobile Benutzeragenten. Dinge wie "Beat Crawl" und "Screaming Frog", sie alle können überprüfen, wie Eure Website aussieht wenn sie mobile versus auf dem Desktop gecrawlt wird.
Menge an internen Verlinkungen
Zeit: 46:31
Frage: Sind interne Links wichtig, zum Beispiel eine Seite hat fünf Millionen Seiten und die andere Seite hat nur 50.000 Seiten? Wäre die andere Seite stärker oder würde sie automatisch besser ranken?
Antwort: Es ist eigentlich nicht möglich, diese zwei Seiten isoliert zu betrachten.
Andererseits: Wenn ihr eine Website mit 50.000 Seiten nehmt und diese einfach „aufblast“ oder alle diese Seiten in separate Seiten aufteilt und daraus fünf Millionen Seiten erstellt, dann verwässert Ihr offensichtlich die Menge dieser einzelnen Seiten und es wird für die Suche schwerer. Ich würde versuchen sicherzustellen, dass man nur Dinge aufteilt, wenn man das unbedingt tun muss, wenn man auf diesen Seiten wirklich unterschiedliche Zwecke verfolgt und so viel wie möglich kombiniert, um eine stärkere Seite zu haben. Aber manchmal muss man verschiedene Seiten haben und diese behalten. Wenn Ihr zum Beispiel eine Nachrichtenwebsite habt mit einem alten Archiv mit vielen Artikeln, dann würdet Ihr nicht an Wert gewinnen, indem Ihr alles löscht, weil die Leute diese Artikel auch nicht finden könnten.
Zwei-Wort-Kombination
Zeit: 49:32
Frage: Könntest Du beschreiben, wie man für Zwei-Wort-Kombination wie „Mexiko / Flagge“ rankt, wenn die Seite für die mexikanische Flagge gut ausgerichtet ist? Wann zeigt Google die Seite für weiter gefasste Keywords an?
Antwort: Das ist etwas, was organisch mit der Zeit passiert. Es ist nicht so, dass es einen magischen Trick gibt, um die umfassenderen Anfragen zu erreichen. Es ist etwas, das wir im Laufe der Zeit lernen und wir erkennen: „Diese Seite ist tatsächlich ziemlich relevant für nicht nur diese spezifische Abfrage, sondern auch für einige weiter gefassten Anfragen.“
Das passiert also von alleine, wenn man an seiner Seite arbeitet und versucht sie stärker zu machen.
Überschriften
Zeit: 50:21
Frage: Wenn Überschrift-Tags wie H1 und Inline-CSS verwendet werden, um die Textgröße zu reduzieren, wirkt sich das auf SEO aus?
Antwort: Ich denke das ist so was wie Text-versus-Code-Verhältnis. Darüber machen wir uns nicht so wirklich Sorgen. Wenn ihr also viel HTML, JavaScript oder Inline-CSS auf Euren Seiten habt, ist das nicht etwas, was wir gegen Euch halten würden. Es gibt nur ein bestimmtes Limit, worauf Ihr achten solltet. Und zwar gibt es ein Maximum an Seitengröße, welches wir für die Suche verwenden. Wenn Ihr also Hunderte von Megabytes Inline CSS auf Eurer Seite habt, bevor Ihr tatsächlich irgendeinen Inhalt anzeigt, dann macht es einerseits wahrscheinlich keinen Sinn, andererseits könnte es sein, dass unsere Systeme nach dem Indexen von zum Beispiel 200 Megabytes und ohne sichtbaren Text zu finden irgendwann denken, dass es sich nicht lohnt, diese Seite weiterhin zu indexieren.
hreflang
Zeit: 52:09
Frage: Ich erstelle ein Verzeichnis für ccTLD für eine Schule in Australien mit einer .edu.au-Domain. Kann ich hreflang benutzen, um auf verschiedene Länder zu zielen, wie zum Beispiel auf Kanada?
Antwort: Ja, Ihr könnt hreflang benutzen, um uns zu zeigen, welche Seiten für Kanada relevant sind, aber Ihr könnt die Seiten nicht auf Kanada ausrichten („Geo-Targeting“). Wenn sich der Inhalt also auf einer ccTLD befindet, die wir anhand von „.au“ für Australien erkennen, könnt ihr den Inhalt nicht geografisch auf andere Länder ausrichten. Bei Geo-Targeting fördern wir Inhalte leicht in den Suchergebnissen für dieses Land, wenn wir feststellen können, dass jemand nach etwas Lokalem sucht. Mit hreflang ändern wir das Ranking überhaupt nicht, wir schalten nur die URLs für die relevanteren lokalen Versionen aus. Bei einer Schule, die zeigen will, dass es sie in Australien gibt, kann es helfen, hreflang alleine deshalb zu benutzen, um an die richtigen Nutzer zu gelangen.
Ist der Campus jedoch in Kanada, aber ist die Top-Level-Domain australisch, also .au, das wäre eine Situation, wo es sich ggfs. lohnen würde, herauszufinden, wie man das Geo-Targeting anwendet. Hreflang macht Sinn in Situationen, bei denen man z. B Inhalte auf australischem Englisch hat und Inhalt auf z. B amerikanischen Englisch, in dem sich Wörter teilweise unterschieden können und man sicher gehen will, dass die jeweils passende Version dem australischen oder amerikanischen Nutzer gezeigt wird. Es könnte auch in anderen Sprachen ähnlich sein. Wenn Ihr also zum Beispiel eine spanische Seite über das College in Australien habt und jemand nur nach dem College Namen sucht, dann wissen wir vielleicht nicht, ob nach spanischem oder englischem Inhalt gesucht wird. Wenn Ihr hreflang einrichtet und wir sehen, dass der Browser oder die Suche des Suchenden auf Spanisch eingestellt ist, dann können wir mit hreflang sehen, dass die englische Seite zwar ranken würde, aber wir haben eine alternative spanische Seite, also würden wir diese anzeigen.
[su_youtube url="https://www.youtube.com/watch?v=3C6p_ip9ang"]
Constanze Bettendorf und Jochen Moschko 