Senden Sie stattdessen einen canonical-Link-Header anstelle eines noindex-Headers.
Das Senden eines canonical-Headers hat wahrscheinlich den gleichen Vorteil für das Crawling-Budget wie das Senden eines noindex-Headers – ohne die SEO-Auswirkungen des Ausschlusses von URLs, die möglicherweise Backlinks über noindex haben.
Wenn Sie Ihren Server konfigurieren können, können Sie einen rel="canonical"HTTP-Header (anstelle eines HTML-Tags) verwenden, um die kanonische URL für ein von Search unterstütztes Dokument anzugeben, einschließlich Nicht-HTML-Dokumenten wie PDF-Dateien.
Wir können unseren Server konfigurieren.
Betont use a rel="canonical" HTTP header rather than an HTML tag eine Präferenz für die HTTP-Header-Lösung?
Googlebot behandelt No-Index-Header sehr elegant. Es wird empfohlen, so viele Routen wie möglich offen zu lassen und Header für hochpräzise Regeln bezüglich Indizes zu verwenden.
Vielleicht behandelt Google canonical-Link-Header genauso elegant wie no-index-Header.
Ich habe damit zu kämpfen, da die Empfehlung von Google so aussieht, als ob sie sich nicht besonders darum kümmert.
Die Empfehlungen für den rel="canonical" HTTP-Header sind die gleichen wie für das rel="canonical"link-Tag.
Ich schätze, es gibt nicht viel zu verlieren, und es ist möglich, dass eine Mischung aus No-Index und Rel-Canonical das richtige Rezept für Google ist. Aber ich bin mir einfach nicht sicher.
Dies macht die kürzlich eingeführte Website-Einstellung rückgängig, was im Grunde zu einer No-op wird (wir senden das, was wir als Head-Tag in einem Header senden, ohne semantische Änderung).
[quote=“sam, post:2, topic:220213”]
Ich schätze, es gibt nicht viel zu verlieren, und es ist möglich, dass eine Mischung aus noindex plus rel canonical das richtige Google-Rezept ist. Aber ich bin mir einfach nicht sicher.
[/quote]Für die neue Standardeinstellung SiteSetting.allow_indexing_non_canonical_urls = false ist dies die derzeit implementierte Vorgehensweise – und sie bleibt so:
Header noindex
HTML Link-Tag canonical (kann ignoriert werden)
Ohne Patch und SiteSetting.allow_indexing_non_canonical_urls = true
– kein Header –
HTML Link-Tag canonical
Mit Patch und SiteSetting.allow_indexing_non_canonical_urls = true
HTML Link-Tag canonical (kann ignoriert werden – aber sowieso derselbe wie im Header)
Die gesamte Idee dahinter:
Setze canonical als HTTP-Header, um denselben Vorteil wie beim noindexHTTP-Header zu erzielen – nämlich schnellere Crawling-Zeiten.
Dadurch könnte noindex mit seinen unsicheren Implikationen obsolet werden.
Ein weiterer Punkt zu noindex vs. canonical:
noindex ist mehr als ein sehr starkes Signal, die Seite nicht in den Suchindex aufzunehmen.
Aber mit noindex wird der Seiteninhalt immer noch vom Google Bot verarbeitet, um Links zu extrahieren (es gibt die zusätzliche Option nofollow, um dies zu deaktivieren).
canonical ist ein starkes Signal, dass der zu crawelnde Inhalt unter einer anderen kanonischen URL zu finden ist.
Wenn der Google Bot beschließt, dieses Signal für eine Seite zu akzeptieren, besteht eine hohe Wahrscheinlichkeit, dass er den Seiteninhalt überhaupt nicht verarbeitet – und nur die kanonische URL verarbeitet.
Dies ist ein Gedankenexperiment. Es ist nirgendwo implementiert – und ich empfehle niemals, es zu implementieren:
Header noindex
HTML Meta-Tag noindex (anstelle von: HTML Link-Tag canonical)
Diese Änderung ist kein ‘Noop’:
Google kann Header und HTML-Inhalte in verschiedenen Phasen seiner Verarbeitungs-Warteschlangen behandeln. Durch das Senden von Headern können wir weitere Verarbeitungs-Warteschlangen (z. B. Render Queue) überspringen und dadurch Crawl-Budget für wichtigere Seiten freigeben.
Nicht stark dagegen, aber es fühlt sich so geringfügig an. Google lädt heutzutage immer Inhalte herunter. Ich bezweifle, dass das Speichern einer HTML-Analyse wirklich einen wesentlichen Unterschied machen wird.
Es gibt viele andere Bereiche, auf die man sich zuerst konzentrieren muss. Die Mikrodaten sind wahrscheinlich der erste Bereich, der etwas Pflege benötigt.
Wir können unseren Server konfigurieren.