SEO-Sprechstunde, 3. Juni 2022

Dies ist eine Zusammenfassung der interessantesten Fragen und Antworten der Google SEO Office Hours mit John Mueller am 3. Juni 2022.

Kann ich zwei HTTP-Ergebniscodes auf einer Seite verwenden?

1:22 „[…] Es ist theoretisch möglich, zwei verschiedene HTTP-Ergebniscodes auf einer Seite zu haben, aber was macht Google mit diesen beiden Codes? Wird Google sie überhaupt sehen? Und wenn ja, was wird Google tun? Zum Beispiel ein 503 plus ein 302.“

Johns Antwort war: „[…] Mit den HTTP-Ergebniscodes können Sie viele verschiedene Dinge einbeziehen. Google wird sich den ersten HTTP-Ergebniscode ansehen und diesen im Wesentlichen verarbeiten.

Und Sie können dort theoretisch immer noch zwei oder mehr HTTP-Ergebniscodes haben, wenn es sich um Weiterleitungen handelt , die zu einer endgültigen Seite führen. So könnten Sie beispielsweise eine Weiterleitung von einer Seite auf eine andere Seite haben. Das ist ein Ergebniscode. Und dann könnten Sie auf dieser anderen Seite einen anderen Ergebniscode liefern. Das könnte also eine 301-Weiterleitung auf eine 404-Seite sein […]. Und aus unserer Sicht werden wir uns in diesen Kettensituationen, in denen wir der Umleitung folgen können, um ein Endergebnis zu erhalten, im Wesentlichen nur auf dieses Endergebnis konzentrieren.

Und wenn dieses Endergebnis Inhalt hat, dann können wir das vielleicht für die Kanonisierung verwenden. Wenn das Endergebnis eine Fehlerseite ist, dann ist es eine Fehlerseite. Und das ist auch gut für uns.“

Verbessert die Verwendung eines CDN das Ranking, wenn meine Website in meinem Hauptland bereits schnell ist?

2:50 „[…] Wir bekommen den Großteil unseres Traffics aus einem bestimmten Land. Wir haben unsere Website auf einem Server in diesem Land gehostet. Schlagen Sie vor, unsere gesamte Website hinter ein CDN zu stellen, um die Seitengeschwindigkeit für Benutzer weltweit zu verbessern, oder ist das in unserem Fall nicht erforderlich?“

John antwortete: „ Ich glaube nicht, dass es in Bezug auf SEO einen großen Einfluss auf Google haben würde.

Der einzige Effekt, bei dem ich mir vorstellen könnte, dass etwas passieren könnte, ist das, was die Benutzer am Ende sehen. […] Wenn die Mehrheit Ihrer Nutzer bereits eine sehr schnelle Website sieht, weil Ihr Server dort steht, dann machen Sie […] das Richtige. Aber natürlich, wenn Benutzer an anderen Standorten ein sehr langsames Ergebnis sehen, weil vielleicht die Verbindung zu Ihrem Land nicht so gut ist, dann haben Sie vielleicht Möglichkeiten, dies zu verbessern.

[…] Wenn es etwas gibt, was Sie tun können, um die Dinge für Ihre Website global zu verbessern, halte ich das für eine gute Idee. Ich denke nicht, dass es kritisch ist […]. Aber es ist etwas, was Sie tun können, um […] Ihre Website über Ihr aktuelles Land hinaus zu erweitern.

Vielleicht sollte ich eines klarstellen: Wenn das Crawling von Google wirklich, wirklich langsam ist, dann kann das natürlich beeinflussen, wie viel wir von der Website crawlen und indizieren können […]. Ich habe dies nicht wirklich als Problem in Bezug auf Websites gesehen, die nicht Millionen und Abermillionen von Seiten groß sind […].

Sie können überprüfen, wie schnell Google in der Search Console und in den Crawling-Statistiken crawlt. Und wenn das vernünftig aussieht, auch wenn das nicht superschnell ist, dann würde ich mir darüber keine Gedanken machen.“

Sollte ich API-Anfragen verbieten, um das Crawling zu reduzieren?

5:20 „[…] Unsere Website gibt derzeit etwa 20 % des Crawl-Budgets für die API-Subdomain aus, weitere 20 % für Miniaturansichten von Videos. Keine dieser Subdomains hat Inhalte, die Teil unserer SEO-Strategie sind. Sollten wir das Crawlen dieser Subdomains verbieten, oder wie werden die API-Endpunkte erkannt oder verwendet?“

Wie John sagte: „[…] In vielen Fällen werden API-Endpunkte von JavaScript auf einer Website verwendet , und wir rendern Ihre Seiten. Und wenn sie auf eine API zugreifen, die sich auf Ihrer Website befindet, versuchen wir, den Inhalt von dieser API zu laden und ihn zum Rendern der Seite zu verwenden.

Und je nachdem, wie Ihre API und Ihr JavaScript eingerichtet sind, kann es für uns schwierig sein, diese API-Ergebnisse zwischenzuspeichern, was bedeutet, dass wir möglicherweise viele dieser API-Anfragen crawlen, um zu versuchen, eine gerenderte Version zu erhalten Ihrer Seiten, damit wir diese für die Indexierung verwenden können. Das ist also normalerweise der Ort, an dem dies entdeckt wird. Und dazu können Sie beitragen, indem Sie sicherstellen, dass die API-Ergebnisse zwischengespeichert werden können, dass Sie keine Zeitstempel in URLs einfügen […], wenn Sie JavaScript für die API verwenden […].

Wenn Ihnen der Inhalt, der mit diesen API-Endpunkten zurückgegeben wird, egal ist, können Sie natürlich mit der robots.txt-Datei das Crawlen dieser gesamten Subdomain blockieren. Und das wird im Wesentlichen alle diese API-Anfragen blockieren.

[…] Sie müssen zunächst herausfinden, ob diese API-Ergebnisse […] Teil von […] kritischen Inhalten sind, die ich von Google indexieren lassen möchte? Und wenn ja, dann sollten Sie das Crawlen wahrscheinlich nicht blockieren. Aber wenn […] es […] etwas generiert, […] das für Ihre Seiten nicht kritisch ist […], dann könnte es sich lohnen, noch einmal zu überprüfen, wie es aussieht, wenn sie blockiert sind.

Und eine Möglichkeit, dies zu überprüfen, besteht darin, eine separate Testseite zu erstellen, die die API nicht aufruft oder eine fehlerhafte URL für den API-Endpunkt verwendet. […] Sie können sehen, wie diese Seite tatsächlich in meinem Browser gerendert wird? Wie wird es für Google gerendert?“

Soll ich rel="nofollow" bei internen Links verwenden?

8:05 „Ist es angemessen, ein nofollow-Attribut für interne Links zu verwenden, um unnötige Crawler-Anfragen an URLs zu vermeiden, die wir nicht gecrawlt oder indexiert haben möchten?“

Hier ist, wie John geantwortet hat: „[…] Ich denke, zum größten Teil macht es sehr wenig Sinn, nofollow auf internen Links zu verwenden. Aber wenn du das machen willst, dann tu es.

In den meisten Fällen werde ich versuchen, so etwas wie die Verwendung von rel=canonical zu verwenden, um auf URLs zu verweisen, die Sie indexiert haben möchten, oder die robots.txt für Dinge zu verwenden, die Sie wirklich nicht gecrawlt haben möchten.

Versuchen Sie herauszufinden, ob es eher eine subtile Sache ist […], die Sie lieber indizieren lassen und dafür rel=canonical verwenden? Oder ist es etwas, wo Sie sagen – tatsächlich, wenn der Googlebot auf diese URLs zugreift, verursacht es Probleme für meinen Server. Es verursacht eine große Belastung. Es macht alles sehr langsam. Es ist teuer oder was hast du.

Und für diese Fälle würde ich das Crawlen dieser URLs einfach verbieten. […] Bei rel=canonical müssen wir diese Seite natürlich zuerst crawlen, um rel=canonical zu sehen. Aber im Laufe der Zeit werden wir uns auf das von Ihnen definierte Canonical konzentrieren. Und wir werden diesen hauptsächlich zum Crawlen und Indizieren verwenden.“

Gibt es eine Möglichkeit, die Anzeige von Sitelinks zu erzwingen?

16:02 „Gibt es eine Strategie, mit der gewünschte Seiten als Website-Link in den Google-Suchergebnissen erscheinen können?“

John stellte klar, dass „[…] es kein Meta-Tag oder strukturierte Daten gibt, die Sie verwenden können, um zu erzwingen, dass ein Site-Link angezeigt wird .

[…] Unsere Systeme versuchen herauszufinden, was für Benutzer […] relevant oder relevant ist, wenn sie sich diese eine Webseite ansehen […]? […] Unsere Empfehlung besteht im Wesentlichen darin, eine gute Website-Struktur zu haben, klare interne Links zu haben, damit wir leicht erkennen können, welche Seiten mit diesen Seiten verbunden sind, und klare Titel zu haben, die wir verwenden und als […] anzeigen können ein Seitenlink.

[…] Es ist nicht so, dass es eine Garantie gibt, dass irgendetwas davon so gezeigt wird. Aber es hilft uns irgendwie herauszufinden, was damit zusammenhängt. Und wenn wir der Meinung sind, dass es sinnvoll ist, einen Site-Link anzuzeigen, ist es für uns viel einfacher, auf der Grundlage dieser Informationen tatsächlich einen auszuwählen.“

Unsere Website bettet PDFs mit Iframes ein, sollten wir den Text mit OCR versehen?

17:14 „Unsere Website verwendet Iframes und ein Skript, um PDF-Dateien auf unseren Seiten und unserer Website einzubetten. Gibt es einen Vorteil, den OCR-Text des PDFs zu nehmen und ihn für SEO-Zwecke irgendwo in den HTML-Code des Dokuments einzufügen, oder wird Google einfach den PDF-Inhalt mit der gleichen Gewichtung und Relevanz parsen, um den Inhalt zu indizieren?“

John antwortete: „[…] Es hört sich so an, als wollten Sie den Text der PDF-Datei nehmen und […] für SEO-Zwecke im HTML-Code verstecken. Und das ist etwas, was ich definitiv nicht empfehlen würde. Wenn Sie den Inhalt indexierbar haben möchten, dann machen Sie ihn auf der Seite sichtbar.

[…] Wir versuchen, den Text aus den PDFs zu nehmen und diesen für die PDFs selbst zu indizieren. Aus praktischer Sicht ist das, was mit einem PDF passiert, als einer der ersten Schritte, wir wandeln es in eine HTML-Seite um und versuchen, diese wie eine HTML-Seite zu indizieren. […] Was Sie tun, ist […] das Iframen einer indirekten HTML-Seite. Und wenn es um Iframes geht, können wir diese Inhalte für die Indexierung auf der Primärseite berücksichtigen. Es kann aber auch passieren, dass wir das PDF trotzdem separat indizieren. […] Ich würde die Frage umdrehen und formulieren, was soll geschehen?

Und wenn Sie möchten, dass Ihre normalen Webseiten mit dem Inhalt der PDF-Datei indexiert werden, dann machen Sie es so, dass dieser Inhalt sofort auf der HTML-Seite sichtbar ist. Anstatt also das PDF als primären Inhalt einzubetten, machen Sie den HTML-Inhalt zum primären Inhalt und verlinken Sie ihn mit der PDF-Datei.

Und dann stellt sich die Frage, ob diese PDFs separat indiziert werden sollen oder nicht? Manchmal möchten Sie PDFs separat indexieren lassen. Und wenn Sie sie separat indizieren möchten, dann ist das Verlinken großartig.

Wenn Sie nicht möchten, dass sie separat indiziert werden, ist die Verwendung von robots.txt zum Blockieren ihrer Indizierung ebenfalls in Ordnung. Sie können auch den noindex [? x-Roboter ?] HTTP-Header. Es ist ein bisschen komplizierter, weil Sie das als Header für die PDF-Dateien bereitstellen müssen, wenn Sie diese PDF-Dateien im Iframe verfügbar, aber nicht wirklich indiziert haben möchten.“

Crawlt Google URLs im strukturierten Daten-Markup?

23:24 „Crawlt Google URLs, die sich in strukturiertem Daten-Markup befinden, oder speichert Google nur die Daten?“

John erklärte: „ Wenn wir uns HTML-Seiten ansehen und etwas sehen, das wie ein Link aussieht, könnten wir meistens auch diese URL ausprobieren. […] Wenn wir eine URL in JavaScript finden, können wir versuchen, diese aufzugreifen und zu verwenden. Wenn wir einen Link in einer Textdatei auf einer Website finden, können wir versuchen, diesen zu crawlen und zu verwenden. Aber es ist nicht wirklich ein normaler Link.

[…] Wenn Sie möchten, dass Google diese URL durchsucht und crawlt, stellen Sie sicher, dass es einen natürlichen HTML-Link zu dieser URL gibt, auch mit einem klaren Ankertext, der einige Informationen über die Zielseite enthält.

Wenn Sie nicht möchten, dass Google diese bestimmte URL crawlt, blockieren Sie sie möglicherweise mit robots.txt oder verwenden Sie auf dieser Seite ein rel=canonical, das auf Ihre bevorzugte Version verweist, oder so etwas. […] Ich würde nicht blind annehmen, dass es nicht gefunden wird, nur weil es in strukturierten Daten ist, noch würde ich blind annehmen, dass es gefunden wird, nur weil es in strukturierten Daten ist.

[…] Ich würde mich stattdessen darauf konzentrieren, was Sie dort geschehen lassen wollen. Wenn Sie möchten, dass es als Link gesehen wird, dann machen Sie es zu einem Link. Wenn Sie nicht möchten, dass es gecrawlt oder indexiert wird, blockieren Sie das Crawling oder die Indexierung […].“