SEO-Sprechstunde, 12. November 2021

Dies ist eine Zusammenfassung der interessantesten Fragen und Antworten der Google SEO Office Hours mit John Mueller am 12. November 2021.

Noindex-Seiten in der Google Search Console

8:16 „ [Einige Seiten] wurden fälschlicherweise auf noindex gesetzt. Dies wurde vor ein paar Monaten behoben. […] Wir haben versucht, die Indexierung über die Search Console anzufordern [und] Sitemaps erneut einzureichen, aber wir bekommen diese Seiten trotzdem nicht indexiert. Haben Sie eine Idee, was dazu führen könnte, dass der Googlebot die Indizierungsanfragen nicht abhört, oder ob es bekannte Probleme in der Search Console mit der Indizierung gibt?“

John: „Ich glaube nicht, dass es diesbezüglich bekannte Probleme gibt, aber manchmal sind wir ein bisschen konservativ, wenn es darum geht, Indexierungsanfragen zu stellen, was wahrscheinlich teilweise das ist, was Sie dort sehen. […] Auf der einen Seite, wenn wir sehen, dass eine Seite längere Zeit noindex ist, dann verlangsamen wir normalerweise das Crawling davon. […] Es bedeutet auch, dass wir das Crawling wieder aufnehmen, wenn die Seite indexierbar wird, also ist es im Wesentlichen diese eine Art von Push, die Sie tun müssen.

Eine andere Sache ist, dass, da Search Console im Wesentlichen die URLs meldet, die wir für die Website kennen, es sein kann, dass das Bild schlechter aussieht, als es tatsächlich ist. Das könnten Sie sich beispielsweise ansehen, indem Sie sich den Leistungsbericht ansehen und nach diesem Abschnitt der Website oder diesen URL-Mustern filtern, um zu sehen, ob diese Anzahl von Seiten mit hohem Noindex in der Search Console auf Seiten berichtet, die das sind waren nicht wirklich wichtig und die wichtigen Seiten aus diesen Abschnitten sind tatsächlich indiziert.“

John sagte auch, dass „[…] eine Sitemap im Wesentlichen ein guter Anfang ist, aber eine andere Sache, die Sie tun könnten , wäre, durch interne Verlinkung deutlich zu machen, dass diese Seiten sehr wichtig für die Website sind, damit wir sie ein bisschen schneller crawlen. Das kann eine temporäre interne Verlinkung sein, wo Sie sagen: Wir verlinken für ein paar Wochen auf einzelne Produkte von unserer Homepage. […] Wenn wir feststellen, dass sich die interne Verlinkung erheblich geändert hat, gehen wir normalerweise los und überprüfen diese Seiten auch noch einmal. Das könnte also ein vorübergehender Ansatz sein, um Dinge wieder in den Index zu schieben. Mit interner Verlinkung sagen Sie nicht, dass es sich um wichtige Seiten im gesamten Web handelt, sondern um wichtige Seiten in Bezug auf Ihre Website. Wenn Sie also die interne Verlinkung stark verändern, kann es passieren, dass andere Teile der Website, die vielleicht gerade noch indexiert wurden, irgendwann ausfallen. Deshalb würde ich das temporär machen und sagen, ich möchte diese zurück ins System schieben, damit sie mit der regulären Rate neu gecrawlt werden, und dann ändere ich die interne Verlinkung zurück, damit alles wieder normaler ist .“

In Bezug auf das Hinzufügen von Links zur Fußzeile fügte John hinzu: „Ich denke, das würde auch funktionieren. Es ist normalerweise besser, wenn wir es auf wirklich wichtigen Seiten der Website finden können, normalerweise wie auf Ihrer Homepage, […] wo Sie sagen, dass dies für Sie wichtig ist, deshalb werden wir diese Seite noch einmal überprüfen. ”

Kanonische und alternative Tags

14:25 „Ich verwende eine WordPress-Website und zwei Plugins. Einer [von ihnen] fügt jeder Seite automatisch einen rel="canonical"-Link hinzu. […] [Das andere ist ein Übersetzer-Plugin], das [zu] jeder Seite einen rel="alternativen" Link hinzufügt. Ist es logisch, dass es heißt: Für diese URL ist es kanonisch, aber es ist auch eine Alternative? Kommt es irgendwo im Crawler zu Konflikten?“

John sagte: „Nein. Ich meine, ich weiß nicht genau, was diese beiden Plugins tun. Wenn Sie eine Seite haben, die ein rel=canonical enthält, haben Sie im Allgemeinen ein kanonisches Sprichwort: Der Link, der dort erwähnt wird, ist die bevorzugte URL, die ich möchte. Wenn es sich um dieselbe Seite handelt, ist das perfekt, denn dann erhalten wir die Bestätigung, dass Sie diese Seite indizieren möchten.

Das rel="alternative" bedeutet im Grunde, dass es auch alternative Versionen dieser Seite gibt. Wenn Sie also beispielsweise bei verschiedenen Sprachen eine Seite auf Englisch und eine Seite auf Französisch haben, haben Sie den Link rel="alternative" zwischen diesen beiden Sprachversionen. Und es heißt nicht, dass die Seite, auf der sich dieser Link befindet, die Alternative ist, sondern es ist eher so, als wären dies zwei verschiedene Versionen, eine davon ist auf Englisch, die andere auf Französisch. Sie können beide kanonisch sein, daher ist diese Kombination normalerweise in Ordnung.

Der einzige Ort, an dem Sie ein wenig aufpassen sollten, ist, dass das Kanonische nicht sprachübergreifend sein sollte. Es sollte also nicht sein, dass Sie auf Ihrer französischen Seite einen kanonischen Satz zur englischen Version haben, da es sich im Wesentlichen um unterschiedliche Seiten handelt. Aber die französische Seite kann kanonisch sein und die englische Seite kann kanonisch sein, und Sie haben die alternative Verbindung zwischen den beiden, und das ist im Wesentlichen ein gutes Set.“

Kanonisierung oder noindex-Tag

16:49 „Wir haben eine Website mit einem E-Commerce-Shop mit vielen Produktvariationen, die dünnen oder doppelten Inhalt haben. Ich habe eine Liste aller URLs erstellt, die wir indiziert haben wollen […], und wir wollen nicht indiziert haben. […] Ich bin mir nicht sicher, was besser wäre: Kanonisierung oder Noindex?“

John sagte: „Ich denke, die allgemeine Frage, ob ich noindex oder rel=“canonical“ für eine andere Seite verwenden soll, ist etwas, auf das es wahrscheinlich keine absolute Antwort gibt. […] Wenn Sie damit zu kämpfen haben, sind Sie nicht die einzige Person, die sagt, oh, welche soll ich nehmen? Das bedeutet normalerweise auch, dass beide Optionen in Ordnung sein können. Normalerweise würde ich mir dort ansehen, was Ihre wirklich starke Präferenz ist. Wenn Sie wirklich nicht möchten, dass dieser Inhalt in der Suche angezeigt wird, würde ich noindex verwenden. Wenn Sie es eher bevorzugen, ich möchte wirklich alles auf einer Seite vereint […], dann würde ich ein rel="canonical" verwenden. Letztendlich ist der Effekt ähnlich, da es wahrscheinlich ist, dass die Seite, die Sie sich ansehen, nicht in der Suche angezeigt wird, aber mit einem noindex – sie wird definitiv nicht angezeigt, und mit einem rel = „canonical“ – wird sie eher nicht angezeigt. ”

John fasste zusammen: „ Du kannst auch beides machen. Wenn zum Beispiel externe Links auf diese Seite verweisen, dann hilft es uns, beide dort zu haben, um herauszufinden, ob Sie diese Seite nicht indiziert haben möchten, aber Sie haben auch eine andere angegeben, also können wir vielleicht einige der Signale nur vorwärts.“

Mobile-First-Indexierung und -Crawling

28:26 „[…] Wir optimieren unsere Seite entsprechend [für die Mobile-First-Indexierung]. Für die Konfiguration empfiehlt Google zwei Vorgehensweisen. Das erste ist ein responsives Webdesign und das zweite ist ein dynamisches Serving. Da der erste Weg für uns durch unsere technische Umgebung etwas schwierig zu erreichen ist, verwenden wir den zweiten Weg. Aber wir sehen immer noch, dass es heutzutage über zweihunderttausend tägliche Crawls zu unserer mobilen Domain gibt. Ist das normal zu sehen? […] Wir hatten die m-dot-Domain, dann haben wir sie auf die Hauptdomain umgeleitet.“

John antwortete: „Ein gewisses Maß an Krabbeln ist normal. Es dauert sehr lange, bis unsere Systeme das Crawlen einer Domain vollständig stoppen, selbst nachdem sie umgeleitet wurde, daher würde ich das nicht als Problem ansehen. Unsere Systeme haben für solche Dinge manchmal einen sehr langen Speicher, und wenn man eine Seite von einer Domain auf eine andere umzieht, oder wenn man diesen mobilen Wechsel mit einer Subdomain macht, dauert es manchmal Jahre, bis das Crawling komplett aufhört.“

Webtechnologien vs. Ranking

36:00 „ Gibt es eine Beziehung oder Auswirkung auf die Rankings für die Websites, die mit normalem HTML, CSS, JS und einem anderen – PWA – erstellt wurden? […] Einer unserer Hauptkonkurrenten hat es kürzlich übernommen, und wir haben einen enormen Sprung in seinen SERP-Rankings festgestellt.“

John sagte: „Dies sind im Wesentlichen verschiedene Arten, eine Website zu erstellen, und Sie können eine Website mit vielen verschiedenen Frameworks und Formaten erstellen. Meistens sehen wir diese als normale HTML-Seiten. Wenn es sich also um eine JavaScript-basierte Website handelt, rendern wir sie und verarbeiten sie dann wie eine normale HTML-Seite. Wenn es am Anfang schon HTML ist, können wir das machen. [Es stecken] verschiedene Frameworks und CMS dahinter. Normalerweise ignorieren wir das im Grunde und sagen einfach, na, hier ist eine HTML-Seite, und wir können sie verarbeiten.

Also nur die Tatsache, dass einer Ihrer Konkurrenten von einem Framework zu einem anderen gewechselt ist und eine Verbesserung bei der Suche festgestellt hat, diese Framework-Änderung wäre aus meiner Sicht nicht dafür verantwortlich. Aber vielleicht haben sie jetzt eine neuere Website, zusammen mit dieser Rahmenänderung. Vielleicht hat die neuere Website eine andere interne Verlinkung, andere Inhalte intern, [sie] ist deutlich schneller oder deutlich langsamer, die Benutzer mögen sie wirklich, oder sie haben eine Marketingkampagne zusammen mit dem Start der Website durchgeführt. All diese Dinge spielen dort eine Rolle, und das sind alles Dinge, die nicht auf das Framework beschränkt sind, das Sie verwenden.“

Google PageSpeed ​​Insights vs. Leuchtturm

37:39 „Sind die Ergebnisse in den Labordaten in Google PageSpeed ​​Insights mit den Lighthouse-Ergebnissen in meinem Chrome-Browser identisch? Verwenden sie dieselbe Formel?“

John sagte: „Ich weiß es nicht hundertprozentig, aber sie werden völlig anders gemacht. […] Wenn Sie PageSpeed ​​Insights verwenden, das irgendwo in einem Rechenzentrum mit im Wesentlichen emulierten Geräten ausgeführt wird, wo wir versuchen, uns wie ein normaler Computer zu verhalten, und wir Einschränkungen haben, die es ein bisschen langsamer machen. […] In Lighthouse läuft es im Grunde auf Ihrem Computer mit Ihrer Internetverbindung. Ich denke, Lighthouse in Chrome hat auch einige Einschränkungen , die es anwendet, um es vielleicht ein bisschen langsamer aussehen zu lassen, als es Ihr Computer tun könnte, nur um sicherzustellen, dass es vergleichbar ist.

Aber im Wesentlichen laufen diese in völlig anderen Umgebungen, und deshalb würden Sie dort oft unterschiedliche Zahlen sehen. […] Wenn Sie mit anderen Geschwindigkeitstools testen, die online laufen, sehen Sie möglicherweise [auch] andere Zahlen. Auch die Felddaten, die Daten, die wir für das Suchranking verwenden und die Sie in der Search Console sehen, können auch völlig andere Zahlen sein, nur weil Ihre Benutzer im Durchschnitt ein anderes Gerät oder eine andere Art von Internetverbindung haben. Selbst wenn also die Formeln gleich sind, ist die gesamte Umgebung um diese Systeme herum sehr unterschiedlich.“

Google Entdecken

47:09 „Wir haben ein großes Problem mit Google Discover auf unserer Website bemerkt. Innerhalb von zwei Tagen ging der Verkehr um siebzig Prozent zurück. […] Wir fragen uns also, ob wir etwas falsch gemacht haben? […] Können Sie erklären, was genau passiert ist, da es sich um eine so drastische Auslosung handelt? […] Könnte es ein technischer Fehler sein?“

John sagte: „Ich weiß es nicht genau in Bezug auf Ihre Website, aber ich bekomme Berichte von vielen Leuten, dass Discover-Traffic entweder ein- oder ausgeschaltet ist, in dem Sinne, dass es sehr wenig Platz dazwischen gibt, wenn unsere Algorithmen uns bestimmen im Moment nicht viel Inhalt von dieser Website in Discover anzeigen, dann verschwindet im Grunde der gesamte Datenverkehr. Andererseits ist es dasselbe, wenn wir etwas von Ihrer Website in Discover zeigen, dann haben Sie plötzlich wieder diesen großen Verkehrsansturm.

Wenn es sich um ein technisches Problem handelt, wird dies auch in der Websuche angezeigt, und es werden Crawling-Probleme angezeigt. Ich habe keinen vollständigen Einblick in das, was genau in Discover passiert, aber normalerweise sind die Probleme, über die die Leute sprechen, einerseits Qualitätsprobleme, bei denen die Qualität der Website möglicherweise nicht so gut ist, und in Bezug auf die einzelne Richtlinien, die wir für Discover haben. Insbesondere für Discover haben wir einige Richtlinien, die sich von der Websuche unterscheiden, und Empfehlungen, die sich, glaube ich, in Bezug auf nicht jugendfreie Inhalte und Clickbaity-Inhalte etwas unterscheiden. […] Das ist alles auf der Hilfe-Center-Seite erwähnt, die wir für Discover haben. Ich kann mir vorstellen, dass viele Websites eine kleine Mischung aus all diesen Dingen haben, und ich vermute manchmal, dass unsere Algorithmen einfach ein bisschen zu viel finden, und dann sagen sie, oh, wir müssen jetzt mit dieser Website vorsichtig sein. Ohne Ihre Website zu kennen und ohne die Details darüber zu kennen, was Discover dort genau aufgreift, würde ich dorthin gehen. […]

Aus unserer Sicht ist Discover der Ort, an dem wir versuchen, den Leuten einen Strom von Informationen zu zeigen, und aus diesem Grund haben wir in der Regel nicht viele detaillierte Informationen darüber, was genau Sie dort bereitstellen müssen, um wirklich gut zu funktionieren. Daher ist es manchmal sinnvoll, sich anzusehen, was andere herausgefunden haben.“

Reaktionszeit

50:41 „Was wäre eine gute Reaktionszeit für eine neue Nachrichtenseite?“

Laut John: „ Die Antwortzeit ist etwas, das unsere Fähigkeit beeinflusst, herauszufinden, wie viel Crawling ein Server verträgt. Normalerweise begrenzt oder spielt die Antwortzeit aus praktischer Sicht mit, wie viele parallele Verbindungen zum Crawlen erforderlich wären. Wenn wir also tausend URLs von einer Website crawlen wollen, dann kann die Antwortzeit, um das über einen Tag zu verteilen, ziemlich lang sein. Wenn wir hingegen eine Million URLs von einer Website crawlen wollen und eine hohe Antwortzeit vorhanden ist, bedeutet dies, dass wir am Ende viele parallele Verbindungen zum Server haben. Ich denke, wir haben da einige Grenzen, da wir keine Probleme auf dem Server verursachen wollen, deshalb ist die Antwortzeit direkt mit der Crawling-Rate verbunden.

Bei einer Nachrichten-Website geht es nicht so sehr darum, ob es Neuigkeiten gibt oder nicht, sondern vielmehr um die Anzahl der URLs, die wir pro Tag crawlen müssen. Das ist also der Winkel, den ich dort betrachten würde. Es kann sein, dass wir auf einer Nachrichten-Website täglich zehntausend Seiten crawlen, und das sind die wichtigen Nachrichtenartikel, die alle behandelt werden. Es kann sein, dass wir täglich Millionen von Artikeln crawlen müssen, weil wir das Archiv immer wieder auffrischen müssen […], dann sieht natürlich die Antwortzeit, die Crawlrate, anders aus.“