Feature Detect für Googlebot deaktivieren oder umgehen (während Auslieferung einer JS-App an Crawler)

Ich versuche, Discourse dazu zu bringen, die JS-App vollständig für Googlebot bereitzustellen – ich bin sehr nah dran.

Mit freundlicher Genehmigung von @pfaffman und der Ausführung des folgenden Codes (in der Rails-Konsole) konnte ich die JS-App anzeigen, wenn ich Chrome verwende und den User-Agenten auf Googlebot oder Googlebot Smartphone spooofe.

SiteSetting.non_crawler_user_agents="trident|webkit|gecko|chrome|safari|msie|opera|goanna|discourse"+‘rss|bot|spider|crawler|facebook|archive|wayback|ping|monitor|lighthouse’

Wenn ich jedoch mit dem Google Mobile Friendly Tool (oder der URL-Inspektion in der Google Search Console) teste, erhalte ich einen leeren Screenshot mit dem folgenden HTML:

Bing ist ähnlich, aber bei ihnen wird der Inhalt angezeigt. Ich glaube, Bing zeigt den Inhalt an, weil sein Crawler nicht “mobil” ist. Relevanter Beitrag hier von @sam

Laut @david und diesem Beitrag scheint die “Featureerkennung” der Schuldige zu sein.

Ich bin vorsichtig optimistisch, dass es eine einfache Lösung gibt. Alle 10-20 Versuche bei der Verwendung des Tools rendert Googlebot die APP ordnungsgemäß.

Meine Theorie ist, dass, da Googlebot dafür bekannt ist, nicht jede Ressource beim Zugriff auf eine Seite herunterzuladen, dieses spezifische JS (das die Featureerkennung enthält und den Revert verursacht) nicht geladen wird und die Seite daher gut aussieht.

Wie kann man also die Featureerkennung für Googlebot (oder, wenn es einfacher ist, für alle Crawler/Bots) deaktivieren?

Bearbeiten Nur für den Fall, dass ich mit der Terminologie daneben liege: Wenn auf Meta von “Featureerkennung” die Rede ist, bezieht sich das auf die Browsererkennung? (vielleicht mit Dateien wie browser-detect.js und anderen Abhängigkeiten)

Oder ist “Featureerkennung” ein allgemeiner Begriff für das, was Discourse tut, wenn es versucht, die Technologie zu verstehen, die auf die App zugreift.

Gibt es einen Grund, warum Sie die JS-Version für Googlebot bereitstellen möchten? Google wird wahrscheinlich keine paginierten Listenansichten finden können, einschließlich der paginierten Startseite und Themen mit mehr als einer bestimmten Anzahl von Beiträgen. In der Bot-Ansicht sind die Themenlisten durchsuchbar, aber Googlebot wird wahrscheinlich das endlose Scrollen nicht auslösen.

Gut, dass Sie fragen, ja, ich glaube, das ist der Grund für meine Google „Soft Penalty“.

Lassen Sie mich das näher erläutern.

Wir hatten um September/Oktober 2019 ein sehr schlampiges Website-Update, die Hauptseite stürzte damals ab.

Wir haben uns nie erholt. Die Website war noch nie besser, was SEO angeht. Sicher, sie ist nicht perfekt, aber wir sind Lichtjahre vor einigen unserer Konkurrenten. Websites, die unsere jahrealten Bilder und Texte verwenden, ranken besser als wir. Wir sind auf der 3. Seite und sie vielleicht auf der 2. Seite.

Ich habe unzählige SEO-Blogs, Videos, Posts durchforstet und sogar einige Rückmeldungen von John Mueller (auf Reddit) erhalten.

Das Meiste, was ich von ihm bekam, war, dass es sich um „Qualitätsprobleme“ handeln könnte. Wir haben die Hauptseite seit dem 1. Januar dieses Jahres dramatisch verbessert. Nicht einmal ein Zucken im organischen Traffic.

Discourse: Ich hatte es 2013 installiert und vergessen. Kaum habe ich den Traffic überprüft.

Wenn Sie sich die Analysen der Hauptseite ansehen, werden Sie einen starken Rückgang gegen Ende des Diagramms feststellen. Dies ist, als ich anfing, an Discourse zu arbeiten.

Als ich prerender.io auf Discourse ausprobierte, war der Rang für die Hauptseite völlig durcheinander. Manchmal sprang er über Nacht um 10-15 Plätze nach oben, dann wieder zurück. (Ich habe prerender inzwischen gestoppt, da sie das Hauptmenü, den Login usw. nicht rendern konnten.)

Nach allem, was ich online gelesen habe, ist dies ein Zeichen dafür, dass Google nicht weiß, wo es Sie einordnen soll. Sie sagen, nur ein kleines bisschen „mehr“ und Sie sind auf der guten Seite des Algorithmus.

Nichts, was wir in den letzten 3 Jahren getan haben, hat diese Schwankungen in den SERPs ausgelöst.

(Mit dem Google Disavow-Tool herumspielen, Code bereinigen, saubere URLs, Seitenstruktur, interne Verlinkung, Social Media, Content usw.)

Sie könnten argumentieren, warum hat Google Sie nicht 2018 abgestraft? (Sie hatten Discourse damals auch auf dem Subdomain)

Nun, ich denke, es war eine Vielzahl von Faktoren, die für die Website, ihre Geschichte und ihr Linkprofil einzigartig waren, die dazu führten, dass sie Ende 2019 abstürzte. Es scheint, dass Google den Website-Rang neu gemischt hat und vielleicht den Discourse-URLs mehr Gewicht gegeben hat, als es zuvor der Fall war.

Und das ist das Ding… Ich liebe Discourse. Besonders jetzt, wo ich mehr auf Meta bin, all diese coolen Plugins und Funktionen, von denen ich keine Ahnung hatte, dass sie existieren. Wiki, Abonnementzahlungen, Inhaltsverzeichnis und jetzt der Chat!!

Daher ist ein Umzug von Discourse keine wirkliche Option, zu viel ist zu diesem Zeitpunkt investiert.

Ich habe das in Betracht gezogen und bin bereit, mein Glück zu versuchen. Ich weiß, dass es nicht perfekt sein wird, aber nach allem, was ich gelesen und gesehen habe, ist Google in letzter Zeit wirklich gut darin geworden, JS zu verstehen.

Sie haben sogar das Ajax-Crawling-Schema als veraltet erklärt

Die Zeiten haben sich geändert. Heute, solange Sie Googlebot nicht am Crawlen Ihrer JavaScript- oder CSS-Dateien hindern, können wir Ihre Webseiten wie moderne Browser rendern und verstehen.

Nebenbemerkung: Discourse hat eine Einstellung für Ajax-Crawling – ich schätze, die muss irgendwann wegfallen.


Der Plan ist also, die App für Google bereitzustellen, mein Bestes zu tun, um alle SEO-Probleme zu beheben, die auftreten könnten, und den Anstieg des Traffics zu genießen.

Ich kann dann die Ergebnisse auf Meta berichten und dafür plädieren, dass Discourse die Optimierung von JS für Google in Betracht ziehen sollte.

Zum Beispiel könnte etwas wie dieses (aus dem Google-Blog) bei den Problemen mit Paginierung und Scrollen helfen.

Und die Nicht-Crawler-Version für alte Browser beibehalten.

Wenn ich hinzufügen darf… :smirk:

Bevor ich die JS-Version überhaupt an Google gesendet habe, habe ich damit herumgespielt.

Ich habe getestet, die JS-Version Anfang April oder so an Google zu senden. Ich erinnere mich, dass sie meistens ein Ergebnis zurückgab (auch wenn es kaputt aussah). Mit dem Google Mobile Tool.

Ich dachte, es könnte dieser Commit sein – ich habe die Code-Änderungen vorgenommen, neu gestartet und das gleiche Verhalten.

Vielleicht erinnert sich jemand an einen PR oder Commit in den letzten Monaten, der die Browser- und/oder Crawler-Erkennung geändert haben könnte?

Edit Entschuldigung für all die Updates, je mehr Infos, desto besser, oder?

Während ich letzten Monat Prerender ausprobiert habe, hat Google 2000 URLs zur Forenabdeckung hinzugefügt. ( hauptsächlich diese URLs )

Sie wurden alle in 0,005 Sekunden ausgeliefert, Prerender hatte die URLs im Cache und bereit für den Googlebot. Also hat er sie alle schnell abgerufen.

Der Punkt ist, vielleicht hat sich der Crawler an das No-JS “gewöhnt” und Ressourcen zugewiesen, um diese 2k Seiten abzurufen.

Also greift er jetzt auf die Website auf diese Weise zu, bis er die Dinge herausfindet (und mehr mit JS zugreifen muss), nur eine Theorie.

Haben Sie an etwas gearbeitet, das die Art und Weise, wie Discourse gecrawlt wird, verändert hat, z. B. versucht, Prerender darauf anzuwenden?

Gibt Ihnen Ihr Landingpages-Bericht in GA Hinweise darauf, welcher Teil der Website betroffen war?


Für die Hauptseite gilt: Wenn John Muller auf Qualitätsprobleme hingewiesen hat, sollten Sie seine Qualitätsdokumente durchgehen und sich fragen, ob eines davon zutrifft.

Bei einem schnellen Blick gibt es Weiterleitungsketten von der Website aus dem Jahr 2019, die möglicherweise länger sind, als Google crawlen kann.

Ein möglicher Grund für eine plötzliche Strafe ist, dass URLs von der Website aus dem Jahr 2019 6 Weiterleitungen haben, Google aber empfiehlt, es bei “weniger als 5” zu belassen, da sie sonst die Weiterleitungen möglicherweise nicht befolgen. Das könnte Google den Eindruck vermittelt haben, dass die alten Seiten aus dem Web verschwunden sind.

Beispiel:

curl -sSL -D - http://flynumber.com/virtual-phone-number/united-states_alexandria_1-318 -o /dev/null -H 'User-Agent: header_bot'

Die Weiterleitungen sind wahrscheinlich am einfachsten zu beheben. Anstatt sie so zu machen:

/a/b/c/d/e/final-destination

Ich würde es so machen:

/a/final-destination
/b/final-destination
/c/final-destination
/d/final-destination
/e/final-destination

(Es sieht so aus, als hätten Sie auch Doorway Pages und automatische Synonymisierung, aber ich würde versuchen, das einfachere Problem zuerst zu beheben, da das vielleicht schon ausreicht.)

Danke, Josh, ich weiß das Feedback zu schätzen.

Guter Fang, und obwohl schlecht ausgeführt und viele Monate dauernd, scheint Google herausgefunden zu haben, welche Seiten was bedeuten.

Mit anderen Worten, schließlich begann ich, mehr und mehr der Seiten zu sehen, zu denen ich für die auf den alten Seiten verwendeten Schlüsselwörter 301 weitergeleitet habe.

Das ist sehr sinnvoll und ich werde sehen, wie ich das umsetzen kann. Derzeit zeigt die Search Console nicht oft, dass der Crawler 301-Anfragen erhält. Es scheint, dass sie mehr 301-Anfragen folgen werden, wenn das Ranking besser wird. Kausalität ohne Korrelation vielleicht.


Es ist überhaupt keine Kritik an Discourse – ich bin nur nicht leicht zu überzeugen von „Tausende von Discourse-Benutzern haben großartigen organischen Traffic“.

Google wird es uns auch nicht wirklich sagen.

Wir müssen uns immer daran erinnern, dass Google ein Algorithmus ist, sie betrachten das nicht mit menschlichen Augen.

Obwohl beide Versionen ähnliche Inhalte teilen und Google weiß, dass es sich nicht um böswilliges Cloaking handelt – müssen sie dennoch das Ranking anpassen.

Eine Version sieht viel besser aus, funktioniert besser und vermittelt ein Gefühl der internen Linkstruktur. Die andere ist ein verherrlichtes RSS-Feed.

Google hat keine Ahnung, dass ich dieses schicke Forum habe, das auf allen [modernen] Geräten funktioniert, wirklich zum Diskurs anregt und eines der coolsten Dinge ist, die das Internet je geschaffen hat.

Ich benutze immer gerne den „Powered by Discourse“-do-follow-Link in der Crawler-Version. (nur weil es einfach ist)

Auch hier weiß ich, dass es nicht böswillig ist, aber man muss es durch die Augen von Google betrachten. Sie (FlyNumber, nicht https://community.cloudflare.com/) geben uns diese Crawler-Version mit einem externen Link, den Sie normalen Browsern nicht zeigen.

Ich könnte mir gut vorstellen, dass der Algorithmus das Geschehen erkennt und den externen Link für die Cloudflare-Domain ignoriert (da sie eine solche Autorität hat).

Es ist nicht so, dass das, was Google auf Cloudflare anwendet, auf mich angewendet wird.

Hat Ihnen jemand für diesen externen Link bezahlt, den Sie Bots zeigen (aber normalen Benutzern nicht zeigen wollen)? Es geht mehr darum, wie sie die Website betrachten könnten. Ich sage nicht, dass es das ist – aber es ist eine Möglichkeit, die Sie ausschließen möchten.

Vereinfacht ausgedrückt hat die Crawler-Version kein Menü und keine wirkliche Struktur.

Das sind die Inhalte, die der Algorithmus Ihrer Meinung nach den Endbenutzern zur Verfügung stellen möchte.

Aus einer sehr allgemeinen Perspektive kann ich mir nicht vorstellen, dass der Algorithmus das belohnt.

Vielleicht ist es an der Zeit, dass wir eine echte Überarbeitung der Crawler-Version in Betracht ziehen. Fügen Sie zumindest das Hauptmenü und die vorgeschlagenen Themen unten hinzu.

Interessantes Update: Google hat „JSON“ zu den „Dateitypen“ in den Crawling-Statistiken für meine Discourse-Instanz hinzugefügt. „Javascript“ ist ein separater „Dateityp“.

Ich werde das genau verfolgen, aber ich würde es immer noch lieben, wenn dies im Google-Tool richtig gerendert würde.

Ich fange an zu denken, dass meine Logik von Anfang an fehlerhaft war. Es würde erklären, warum niemand geantwortet hat – vielleicht ist nichts falsch.

Hier ist ein neuer Artikel darüber, dass es normal ist, dass Google eine weiße Seite im Screenshot anzeigt

Ich kann jetzt den „gecrawleten“ HTML-Code für die Homepage sehen, dies ist die indexierte Version, nicht vom „Live-Test“ – sie zeigt die vollständige Seite. Beachten Sie, dass Google dies herausgefunden hat, während es ihnen die vollständige JS-App bereitgestellt hat.

Interessant ist, dass sie bei der Indexierung bis zum 27. Beitrag auf der Homepage heruntergegangen sind. Das Endlos-Scrollen versteht Google also.

Ich bin mir nicht sicher, ob es geholfen hat, aber ich habe die Ajax-Einstellung in den Admin-Einstellungen deaktiviert. Dadurch konnte Google URLs wie die folgende finden (und die Crawler-Version bereitstellen) – ich habe sie deaktiviert, und jetzt zeigt diese URL die JS-Version an

https://discuss.flynumber.com/t/japan-phone-numbers-disconnect-notice/2351?_escaped_fragment_=

Jetzt muss ich nur noch herausfinden, wie ich die zusätzlichen kanonischen URLs bereinigen kann, die Discourse für die Benutzerseiten erstellt.

Nachdem ich die SPA (Full JS-Version) von Discourse mindestens einen Monat lang genutzt habe, bin ich zur Crawler-Version zurückgekehrt.

Sie können meine Post-Historie einsehen, aber ich habe argumentiert, dass Google die JS-Version verstehen und besser ranken könnte als die Crawler-Version. Ich lag falsch.

Hey @j127, du hattest Recht! (Ich werde dir eine PN schicken, mein Guter)

Es scheint, dass Google die Seite zwar herausgefunden hat, sie aber ungefähr gleich (wenn nicht sogar etwas schlechter) eingestuft hat.

Die Crawler-Version wurde im April/Mai auch in Bezug auf Linkfarben, Format usw. aktualisiert, was eine gute Hilfe ist.

Meiner Meinung nach würde es die SEO aller verbessern, wenn wir der Crawler-Version ein einfaches Menü und die “vorgeschlagenen Themen” hinzufügen würden.

Ansonsten wollte ich das nur mal so in die Runde geben, falls jemand neugierig war.

Tolle Arbeit, Leute!

2 „Gefällt mir“

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.