Was SEOs wirklich über JavaScript SEO wissen müssen
Wussten Sie, dass der Ahrefs-Blog zwar mit WordPress betrieben wird, ein Großteil der übrigen Website aber mit JavaScript wie React?
Die Realität des heutigen Webs ist, dass JavaScript überall zu finden ist. Die meisten Websites verwenden irgendeine Art von JavaScript, um Interaktivität hinzuzufügen und die Benutzerfreundlichkeit zu verbessern.
Dennoch hat das meiste JavaScript, das auf so vielen Websites verwendet wird, keinerlei Auswirkungen auf die Suchmaschinenoptimierung. Wenn Sie eine normale WordPress-Installation ohne viele Anpassungen haben, dann wird wahrscheinlich keines der Probleme auf Sie zutreffen.
Problematisch wird es, wenn JavaScript verwendet wird, um eine ganze Seite zu erstellen, Elemente hinzuzufügen oder zu entfernen oder bereits vorhandene Elemente auf der Seite zu ändern. Einige Websites verwenden es für Menüs, zum Einfügen von Produkten oder Preisen, zum Abrufen von Inhalten aus verschiedenen Quellen oder in einigen Fällen für die gesamte Website. Wenn dies auf Ihre Website zutrifft, lesen Sie weiter.
Wir sehen ganze Systeme und Anwendungen, die mit JavaScript-Frameworks gebaut wurden, und sogar einige traditionelle CMS mit JavaScript-Flair, die ohne Kopfhörer oder entkoppelt sind. Das CMS wird als Backend-Datenquelle verwendet, aber die Frontend-Darstellung wird von JavaScript übernommen.
Ich sage nicht, dass SEOs losziehen und lernen müssen, wie man JavaScript programmiert. Ich empfehle es nicht, weil es unwahrscheinlich ist, dass Sie den Code jemals anfassen werden. Was SEOs wissen müssen, ist, wie Google mit JavaScript umgeht und wie man Probleme behebt.
JavaScript-SEO ist ein Teil der technischen SEO (Suchmaschinenoptimierung), der dafür sorgt, dass JavaScript-lastige Websites leicht zu crawlen und zu indexieren sowie suchmaschinenfreundlich sind. Ziel ist es, dass diese Websites in den Suchmaschinen gefunden werden und einen höheren Rang einnehmen.
JavaScript ist nicht schlecht für die Suchmaschinenoptimierung, und es ist auch nicht böse. Es ist nur anders als das, was viele SEOs gewohnt sind, und es gibt eine gewisse Lernkurve.
Viele der Prozesse ähneln denen, die SEOs bereits gewohnt sind, aber es kann leichte Unterschiede geben. Sie werden sich immer noch hauptsächlich HTML-Code ansehen und nicht wirklich JavaScript.
Alle normalen Best Practices für On-Page-SEO gelten weiterhin. Siehe unseren Leitfaden zur On-Page-SEO.
Sie werden sogar vertraute Plugin-Optionen finden, um viele der grundlegenden SEO-Elemente zu handhaben, wenn diese nicht bereits in dem von Ihnen verwendeten Framework integriert sind. Bei JavaScript-Frameworks werden diese als Module bezeichnet, und Sie finden viele Paketoptionen, um sie zu installieren.
Es gibt Versionen für viele der beliebten Frameworks wie React, Vue, Angular und Svelte, die Sie finden können, indem Sie nach dem Namen des Frameworks + des Moduls suchen, z. B. “React Helmet”. Meta-Tags, Helmet und Head sind beliebte Module mit ähnlicher Funktionalität, mit denen viele der für SEO benötigten Tags gesetzt werden können.
In mancher Hinsicht ist JavaScript besser als traditionelles HTML, z. B. in Bezug auf einfache Erstellung und Leistung. In mancher Hinsicht ist JavaScript schlechter, da es nicht progressiv geparst werden kann (wie HTML und CSS), und es kann das Laden der Seite und die Leistung beeinträchtigen. Oft muss man Leistung gegen Funktionalität eintauschen.
JavaScript ist nicht perfekt, und es ist nicht immer das richtige Werkzeug für die Aufgabe. Entwickler verwenden es übermäßig für Dinge, für die es wahrscheinlich eine bessere Lösung gibt. Aber manchmal muss man mit dem arbeiten, was einem gegeben ist.
Dies sind viele der üblichen SEO-Probleme, auf die Sie bei der Arbeit mit JavaScript-Sites stoßen können.
Einzigartige Titel-Tags und Meta-Beschreibungen
Sie sollten immer noch eindeutige Titel-Tags und Meta-Beschreibungen für alle Ihre Seiten haben. Da viele JavaScript-Frameworks mit Vorlagen arbeiten, können Sie leicht in eine Situation geraten, in der derselbe Titel oder dieselbe Meta-Beschreibung für alle Seiten oder eine Gruppe von Seiten verwendet wird.
Prüfen Sie die Duplikate Bericht in Ahrefs’ Site Audit und klicken Sie auf eine der Gruppierungen, um weitere Daten zu den von uns gefundenen Problemen zu sehen.
Sie können eines der SEO-Module wie Helmet verwenden, um benutzerdefinierte Tags für jede Seite festzulegen.
JavaScript kann auch verwendet werden, um von Ihnen festgelegte Standardwerte zu überschreiben. Google wird dies verarbeiten und den überschriebenen Titel oder die Beschreibung verwenden. Für die Nutzer können Titel jedoch problematisch sein, da ein Titel im Browser erscheinen kann und sie einen Blitz bemerken, wenn er überschrieben wird.
Wenn Sie sehen, dass der Titel blinkt, können Sie die SEO-Toolbar von Ahrefs verwenden, um sowohl die rohe HTML-Version als auch die gerenderte Version zu sehen.
Google verwendet Ihre Titel oder Meta-Beschreibungen möglicherweise ohnehin nicht. Wie ich bereits erwähnt habe, lohnt es sich, die Titel für die Nutzer zu bereinigen. Die Korrektur der Meta-Beschreibungen wird jedoch nicht wirklich einen Unterschied machen.
Als wir Googles Rewriting untersuchten, fanden wir heraus, dass Google Titel in 33,4 % der Fälle und Meta-Beschreibungen in 62,78 % der Fälle überschreibt. In Site Audit zeigen wir Ihnen sogar, welche Ihrer Titel-Tags Google geändert hat.
Probleme mit kanonischen Tags
Jahrelang sagte Google, dass es kanonische Tags, die mit JavaScript eingefügt wurden, nicht respektiert. Schließlich wurde in der Dokumentation eine Ausnahme für Fälle hinzugefügt, in denen noch kein Tag vorhanden war. Ich habe diese Änderung verursacht. Ich habe Tests durchgeführt, um zu zeigen, dass es funktioniert, während Google behauptet hat, dass es nicht funktioniert.
Wenn bereits ein kanonisches Tag vorhanden war und Sie ein weiteres hinzufügen oder das vorhandene mit JavaScript überschreiben, dann geben Sie ihnen zwei kanonische Tags. In diesem Fall muss Google herausfinden, welches zu verwenden ist oder die kanonischen Tags zugunsten anderer Kanonisierungssignale ignorieren.
Der Standard-SEO-Ratschlag “jede Seite sollte ein selbstreferenzierendes kanonisches Tag haben” bringt viele SEOs in Schwierigkeiten. Ein Entwickler nimmt diese Anforderung und macht Seiten mit und ohne nachgestellten Schrägstrich selbst-kanonisch.
example.com/page mit einem canonical von example.com/page und example.com/page/ mit einem Kanonischen von example.com/page/. Ups, das ist falsch! Sie wollen wahrscheinlich eine dieser Versionen auf die andere umleiten.
Das Gleiche kann mit parametrisierten Versionen passieren, die Sie vielleicht kombinieren möchten, aber jede Version ist selbstreferenzierend.
Google verwendet den restriktivsten Meta-Robots-Tag
Bei Meta-Robots-Tags wird Google immer die restriktivste Option wählen, die es sieht – unabhängig vom Standort.
Wenn Sie ein index-Tag im Roh-HTML und ein noindex-Tag im gerenderten HTML haben, wird Google es als noindex behandeln. Wenn Sie ein noindex-Tag im Roh-HTML haben, es aber mit einem index-Tag mit JavaScript überschreiben, wird die Seite trotzdem als noindex behandelt.
Das Gleiche gilt für nofollow-Tags. Google wird die restriktivste Option wählen.
Alt-Attribute für Bilder setzen
Fehlende alt-Attribute sind ein Problem der Zugänglichkeit, das zu einem rechtlichen Problem werden kann. Die meisten großen Unternehmen wurden wegen Problemen mit der ADA-Konformität ihrer Websites verklagt, und einige werden mehrmals im Jahr verklagt. Ich würde dies für die Bilder des Hauptinhalts beheben, aber nicht für Dinge wie Platzhalter oder dekorative Bilder, bei denen Sie die alt-Attribute leer lassen können.
Für die Websuche zählt der Text in den alt-Attributen als Text auf der Seite, aber das ist wirklich die einzige Rolle, die er spielt. Seine Bedeutung für die Suchmaschinenoptimierung wird meiner Meinung nach oft überschätzt. Er hilft jedoch bei der Bildersuche und der Platzierung von Bildern.
Viele JavaScript-Entwickler lassen die alt-Attribute leer, daher sollten Sie überprüfen, ob Ihre Attribute vorhanden sind. Sehen Sie sich die Bilder Bericht in Site Audit, um diese zu finden.
Crawling von JavaScript-Dateien zulassen
Blockieren Sie nicht den Zugriff auf Ressourcen, wenn diese für den Aufbau der Seite oder die Ergänzung des Inhalts benötigt werden. Google muss auf die Ressourcen zugreifen und sie herunterladen, damit es die Seiten richtig darstellen kann. In Ihrer robots.txt ist es am einfachsten, das Crawlen der benötigten Ressourcen zuzulassen, indem Sie Folgendes hinzufügen:
User-Agent: GooglebotAllow: .jsAllow: .css
Überprüfen Sie auch die robots.txt-Dateien für alle Subdomains oder zusätzlichen Domains, von denen aus Sie möglicherweise Anfragen stellen, z. B. für Ihre API-Aufrufe.
Wenn Sie Ressourcen mit robots.txt blockiert haben, können Sie überprüfen, ob sich dies auf den Seiteninhalt auswirkt, indem Sie die Blockieroptionen auf der Registerkarte “Netzwerk” in den Entwicklungswerkzeugen von Chrome verwenden. Wählen Sie die Datei aus und blockieren Sie sie. Laden Sie dann die Seite neu, um zu sehen, ob Änderungen vorgenommen wurden.
Prüfen Sie, ob Google Ihren Inhalt sieht
Viele Seiten mit JavaScript-Funktionen zeigen Google möglicherweise nicht standardmäßig den gesamten Inhalt an. Wenn Sie mit Ihren Entwicklern sprechen, bezeichnen sie dies möglicherweise als “not Document Object Model (DOM) loaded”. Das bedeutet, dass der Inhalt nicht standardmäßig geladen wurde und möglicherweise erst später durch eine Aktion wie einen Klick geladen wird.
Eine schnelle Überprüfung können Sie durchführen, indem Sie einfach in Google nach einem Ausschnitt Ihres Inhalts in Anführungszeichen suchen. Suchen Sie nach “einer Phrase aus Ihrem Inhalt” und sehen Sie nach, ob die Seite in den Suchergebnissen erscheint. Wenn dies der Fall ist, wurde Ihr Inhalt wahrscheinlich gesehen.
Nebenbemerkung.
Inhalte, die standardmäßig ausgeblendet sind, werden möglicherweise nicht in Ihrem Snippet auf den SERPs angezeigt. Es ist besonders wichtig, Ihre mobile Version zu überprüfen, da diese oft aus Gründen der Benutzerfreundlichkeit reduziert wird.
Sie können auch mit der rechten Maustaste klicken und die Option “Untersuchen” verwenden. Suchen Sie auf der Registerkarte “Elemente” nach dem Text.
Die beste Überprüfung ist die Suche innerhalb des Inhalts eines der Testtools von Google, z. B. des Tools zur URL-Prüfung in der Google Search Console. Ich werde später mehr darüber sprechen.
Ich würde auf jeden Fall alles überprüfen, was sich hinter einem Akkordeon oder einem Dropdown-Element befindet. Diese Elemente stellen oft Anfragen, die Inhalte auf die Seite laden, wenn sie angeklickt werden. Google klickt nicht, also sieht es den Inhalt auch nicht.
Wenn Sie die Inspektionsmethode verwenden, um Inhalte zu suchen, stellen Sie sicher, dass Sie den Inhalt kopieren und dann die Seite neu laden oder in einem Inkognito-Fenster öffnen, bevor Sie die Suche starten.
Wenn Sie auf das Element geklickt haben und der Inhalt zum Zeitpunkt dieser Aktion geladen wurde, finden Sie den Inhalt. Bei einem erneuten Laden der Seite wird möglicherweise nicht das gleiche Ergebnis angezeigt.
Probleme mit doppeltem Inhalt
Bei JavaScript kann es mehrere URLs für denselben Inhalt geben, was zu Problemen mit doppeltem Inhalt führt. Dies kann durch Großschreibung, Schrägstriche am Ende, IDs, Parameter mit IDs usw. verursacht werden. All dies kann also vorkommen:
domain.com/Abcdomain.com/abcdomain.com/123domain.com/?id=123
Wenn Sie nur eine Version indiziert haben wollen, sollten Sie einen selbstreferenzierenden Canonical setzen und entweder kanonische Tags von anderen Versionen, die auf die Hauptversion verweisen, oder idealerweise die anderen Versionen auf die Hauptversion umleiten.
Prüfen Sie die Duplikate Bericht in Site Audit. Wir schlüsseln auf, welche Duplikat-Cluster kanonische Tags gesetzt haben und welche Probleme aufweisen.
Ein häufiges Problem bei JavaScript-Frameworks ist, dass Seiten mit und ohne den abschließenden Schrägstrich existieren können. Idealerweise wählen Sie die Version aus, die Sie bevorzugen, und stellen sicher, dass diese Version ein selbstreferenzierendes kanonisches Tag hat, und leiten dann die andere Version auf Ihre bevorzugte Version um.
Bei App-Shell-Modellen werden in der anfänglichen HTML-Antwort möglicherweise nur sehr wenig Inhalt und Code angezeigt. Tatsächlich kann auf jeder Seite der Website derselbe Code angezeigt werden, und dieser Code kann genau derselbe sein wie der Code auf einigen anderen Websites.
Wenn Sie in Site Audit viele URLs mit einer niedrigen Wortanzahl sehen, kann dies ein Hinweis auf dieses Problem sein.
Dies kann manchmal dazu führen, dass Seiten als Duplikate behandelt werden und nicht sofort zum Rendering gehen. Schlimmer noch, die falsche Seite oder sogar die falsche Website kann in den Suchergebnissen angezeigt werden. Dies sollte sich im Laufe der Zeit von selbst erledigen, kann aber vor allem bei neueren Websites problematisch sein.
Verwenden Sie keine Fragmente (#) in URLs
# hat in Browsern bereits eine bestimmte Funktion. Es verweist auf einen anderen Teil einer Seite, wenn es angeklickt wird – wie unsere “Inhaltsverzeichnis”-Funktion im Blog. Server verarbeiten im Allgemeinen nichts nach einem #. Bei einer URL wie abc.com/#somethingwird alles, was nach einem # kommt, normalerweise ignoriert.
JavaScript-Entwickler haben beschlossen, # als Auslöser für verschiedene Zwecke zu verwenden, und das sorgt für Verwirrung. Am häufigsten werden sie für das Routing und für URL-Parameter missbraucht. Ja, sie funktionieren. Nein, man sollte es nicht tun.
JavaScript-Frameworks verfügen in der Regel über Router, die so genannte Routen (Pfade) auf saubere URLs abbilden. Viele JavaScript-Entwickler verwenden Hashes (#) für das Routing. Dies ist insbesondere ein Problem für Vue und einige der früheren Versionen von Angular.
Um dies für Vue zu beheben, können Sie mit Ihrem Entwickler zusammenarbeiten, um das Folgende zu ändern:
Vue router: Use ‘History’ Mode instead of the traditional ‘Hash’ Mode.
const router = new VueRouter ({mode: ‘history’,router: [] //the array of router links)}
Es gibt einen wachsenden Trend, bei dem die Leute # anstelle von ? als Fragment-Identifikator verwenden, insbesondere für passive URL-Parameter wie die, die für das Tracking verwendet werden. Ich neige dazu, wegen der ganzen Verwirrung und Probleme davon abzuraten. Situationsbedingt könnte ich damit einverstanden sein, wenn dadurch eine Menge unnötiger Parameter wegfallen.
Erstellen Sie eine Sitemap
Die Router-Optionen, die saubere URLs ermöglichen, haben normalerweise ein zusätzliches Modul, das auch Sitemaps erstellen kann. Sie können sie finden, indem Sie nach Ihrem System + Router-Sitemap suchen, z. B. “Vue router sitemap”.
Viele der Rendering-Lösungen können auch Sitemap-Optionen haben. Suchen Sie einfach nach dem System, das Sie verwenden, und googeln Sie nach System + Sitemap, z. B. “Gatsby-Sitemap”, und Sie werden mit Sicherheit eine Lösung finden, die bereits existiert.
Statuscodes und weiche 404er
Da JavaScript-Frameworks nicht serverseitig sind, können sie nicht wirklich einen Serverfehler wie einen 404 auslösen. Sie haben ein paar verschiedene Optionen für Fehlerseiten, wie zum Beispiel:
- Verwendung einer JavaScript-Umleitung zu einer Seite, die mit einem 404-Statuscode antwortet.
- Hinzufügen eines noindex-Tags zu der Seite, die nicht funktioniert, zusammen mit einer Fehlermeldung wie “404 Page Not Found”. Dies wird als weicher 404 behandelt, da der tatsächliche Statuscode ein 200 okay sein wird.
JavaScript-Weiterleitungen sind OK, aber nicht bevorzugt
SEOs sind an 301/302-Weiterleitungen gewöhnt, die serverseitig sind. JavaScript wird normalerweise clientseitig ausgeführt. Serverseitige Weiterleitungen und sogar Meta-Refresh-Weiterleitungen sind für Google einfacher zu verarbeiten als JavaScript-Weiterleitungen, da die Seite nicht gerendert werden muss, um sie zu sehen.
JavaScript-Weiterleitungen werden während des Renderings immer noch gesehen und verarbeitet und sollten in den meisten Fällen in Ordnung sein – sie sind nur nicht so ideal wie andere Weiterleitungsarten. Sie werden als permanente Weiterleitungen behandelt und geben weiterhin alle Signale wie PageRank weiter.
Sie können diese Weiterleitungen oft im Code finden, indem Sie nach “window.location.href” suchen. Die Weiterleitungen könnten auch in der Konfigurationsdatei zu finden sein. In der Next.js-Konfiguration gibt es eine Redirect-Funktion, mit der Sie Umleitungen festlegen können. In anderen Systemen finden Sie sie möglicherweise im Router.
Probleme mit der Internationalisierung
Es gibt in der Regel ein paar Moduloptionen für verschiedene Frameworks, die einige für die Internationalisierung benötigte Funktionen wie hreflang unterstützen. Sie wurden in der Regel auf die verschiedenen Systeme portiert und enthalten i18n, intl oder oft können die gleichen Module, die für Header-Tags wie Helmet verwendet werden, verwendet werden, um die benötigten Tags hinzuzufügen.
Wir kennzeichnen hreflang-Probleme in der Lokalisierung Bericht in Site Audit. Wir haben auch eine Studie durchgeführt und festgestellt, dass 67 % der Domänen, die hreflang verwenden, Probleme haben.
Sie müssen auch darauf achten, ob Ihre Website Besucher aus einem bestimmten Land oder mit einer bestimmten IP-Adresse blockiert oder auf unterschiedliche Weise behandelt. Dies kann dazu führen, dass Ihr Inhalt von Googlebot nicht gesehen wird. Wenn Sie eine Logik haben, die Nutzer umleitet, sollten Sie Bots von dieser Logik ausschließen.
Wir teilen Ihnen mit, ob dies bei der Einrichtung eines Projekts in Site Audit der Fall ist.
Strukturierte Daten verwenden
JavaScript kann verwendet werden, um strukturierte Daten zu generieren oder in Ihre Seiten einzufügen. Es ist ziemlich üblich, dies mit JSON-LD zu tun und wird wahrscheinlich keine Probleme verursachen, aber führen Sie einige Tests durch, um sicherzustellen, dass alles so kommt, wie Sie es erwarten.
Wir markieren alle strukturierten Daten, die wir in der Probleme Bericht in Site Audit. Suchen Sie nach dem Fehler “Structured data has schema.org validation”. Wir sagen Ihnen genau, was für jede Seite falsch ist.
Links im Standardformat verwenden
Links zu anderen Seiten sollten im Web-Standardformat angelegt sein. Interne und externe Links müssen ein <a> Tag mit einem href Attribut. Es gibt viele Möglichkeiten, wie Sie Links für Benutzer mit JavaScript funktionieren lassen können, die nicht suchfreundlich sind.
Sehr gut:
<a href=”/page”>simple is good</a>
<a href=”/page” onclick=”goTo(‘page’)”>still okay</a>
Schlecht:
<a onclick=”goTo(‘page’)”>nope, no href</a>
<a href=”javascript:goTo(‘page’)”>nope, missing link</a>
<a href=”javascript:void(0)”>nope, missing link</a>
<span onclick=”goTo(‘page’)”>not the right HTML element</span>
<option value="page">nope, wrong HTML element</option>
<a href=”#”>no link</a>
Button, ng-click, es gibt viele weitere Möglichkeiten, dies falsch zu machen.
Meiner Erfahrung nach verarbeitet Google immer noch viele der schlechten Links und crawlt sie, aber ich bin mir nicht sicher, wie es sie in Bezug auf weiterführende Signale wie PageRank behandelt. Das Web ist ein chaotischer Ort, und die Parser von Google sind oft recht nachsichtig.
Es ist auch erwähnenswert, dass interne Links, die mit JavaScript hinzugefügt werden, erst nach dem Rendering erkannt werden. Das sollte relativ schnell gehen und in den meisten Fällen kein Grund zur Sorge sein.
Verwenden Sie die Dateiversionierung, um zu verhindern, dass unmögliche Zustände indiziert werden
Google legt alle Ressourcen auf seiner Seite in einem Cache ab. Ich werde später noch etwas ausführlicher darauf eingehen, aber Sie sollten wissen, dass dieses System dazu führen kann, dass einige unmögliche Zustände indiziert werden. Dies ist eine Eigenart des Systems. In diesen Fällen werden frühere Dateiversionen für den Rendering-Prozess verwendet, und die indizierte Version einer Seite kann Teile älterer Dateien enthalten.
Sie können die Dateiversionierung oder das Fingerprinting (file.12345.js) verwenden, um neue Dateinamen zu generieren, wenn wesentliche Änderungen vorgenommen werden, so dass Google die aktualisierte Version der Ressource für das Rendering herunterladen muss.
Sie sehen möglicherweise nicht, was Googlebot angezeigt wird
Möglicherweise müssen Sie Ihren Benutzer-Agenten ändern, um einige Probleme richtig zu diagnostizieren. Inhalte können für verschiedene Benutzer-Agenten oder sogar IPs unterschiedlich dargestellt werden. Sie sollten prüfen, was Google mit seinen Testtools tatsächlich sieht, und darauf werde ich gleich noch eingehen.
Sie können mit Chrome DevTools einen benutzerdefinierten User-Agent festlegen, um Websites zu testen, die auf der Grundlage bestimmter User-Agents gerendert werden, oder Sie können dies auch einfach mit unserer Toolbar tun.
Verwendung von Polyfills für nicht unterstützte Funktionen
Es kann Funktionen geben, die von Entwicklern verwendet werden, die von Googlebot nicht unterstützt werden. Ihre Entwickler können verwenden Feature-Erkennung. Und wenn ein Merkmal fehlt, können sie wählen, ob sie diese Funktionalität überspringen oder eine Ausweichmethode mit einer Polyfill um zu sehen, ob sie es zum Laufen bringen können.
Dies ist hauptsächlich eine Information für SEOs. Wenn Sie etwas sehen, von dem Sie denken, dass Google es sehen sollte, es aber nicht sieht, könnte es an der Implementierung liegen.
Verwenden Sie “Lazy Loading
Seit ich diesen Artikel geschrieben habe, ist Lazy Loading größtenteils nicht mehr JavaScript-gesteuert, sondern wird von Browsern gehandhabt.
Sie können immer noch auf einige JavaScript-gesteuerte Lazy-Load-Konfigurationen stoßen. In den meisten Fällen sind sie wahrscheinlich in Ordnung, wenn das faule Laden für Bilder ist. Ich würde vor allem überprüfen, ob der Inhalt verzögert geladen wird. Siehe dazu den Abschnitt “Prüfen Sie, ob Google Ihren Content sieht” weiter oben. Diese Art von Konfigurationen hat zu Problemen mit der korrekten Erfassung des Inhalts geführt.
Probleme beim unendlichen Scrollen
Wenn Sie eine Infinite-Scroll-Einrichtung haben, empfehle ich immer noch eine paginierte Seitenversion, damit Google noch richtig crawlen kann.
Ein weiteres Problem, das ich bei dieser Einrichtung beobachtet habe, ist, dass gelegentlich zwei Seiten als eine indexiert werden. Ich habe das ein paar Mal erlebt, als Leute sagten, sie könnten ihre Seite nicht indiziert bekommen. Aber ich habe festgestellt, dass ihr Inhalt als Teil einer anderen Seite indiziert wurde, die normalerweise der vorherige Beitrag von ihnen ist.
Meine Theorie ist, dass Google, als es die Größe des Ansichtsfensters änderte, um länger zu sein (mehr dazu später), das unendliche Scrollen auslöste und einen anderen Artikel lud, als er gerendert wurde. In diesem Fall empfehle ich, die JavaScript-Datei zu blockieren, die das unendliche Scrollen steuert, damit die Funktion nicht ausgelöst werden kann.
Probleme mit der Leistung
Viele der JavaScript-Frameworks kümmern sich um eine Menge moderner Leistungsoptimierung für Sie.
Alle traditionellen Best Practices für die Leistungsoptimierung gelten nach wie vor, aber Sie erhalten einige ausgefallene neue Optionen. Code-Splitting unterteilt die Dateien in kleinere Dateien. Tree Shaking bricht benötigte Teile heraus, so dass Sie nicht alles für jede Seite laden müssen, wie es bei traditionellen monolithischen Setups der Fall ist.
Gut gemachte JavaScript-Setups sind eine schöne Sache. JavaScript-Setups, die nicht gut gemacht sind, können aufgebläht sein und lange Ladezeiten verursachen.
Weitere Informationen über die Leistung von Websites finden Sie in unserem Leitfaden Core Web Vitals.
JavaScript-Sites verbrauchen mehr Crawl-Budget
JavaScript XHR-Anfragen fressen Crawl-Budget, und ich meine, sie verschlingen es. Im Gegensatz zu den meisten anderen Ressourcen, die zwischengespeichert werden, werden diese live während des Rendering-Prozesses abgerufen.
Ein weiteres interessantes Detail ist, dass der Rendering-Dienst versucht, keine Ressourcen abzurufen, die nicht zum Inhalt der Seite beitragen. Wenn dies nicht der Fall ist, kann es sein, dass Sie Inhalte verpassen.
Worker werden nicht unterstützt, oder doch?
Während Google traditionell sagt, dass es Service Worker ablehnt und Service Worker das DOM nicht bearbeiten können, deutete Googles eigener Martin Splitt an, dass man manchmal mit der Verwendung von Web Workern davonkommen kann.
HTTP-Verbindungen verwenden
Googlebot unterstützt HTTP-Anfragen, aber keine anderen Verbindungstypen wie WebSockets oder WebRTC. Wenn Sie diese verwenden, stellen Sie einen Fallback bereit, der HTTP-Verbindungen verwendet.
Ein “Problem” bei JavaScript-Seiten ist, dass sie das DOM teilweise aktualisieren können. Wenn ein Benutzer eine andere Seite aufruft, werden möglicherweise einige Aspekte wie Titel-Tags oder kanonische Tags im DOM nicht aktualisiert, aber das ist für Suchmaschinen kein Problem.
Google lädt jede Seite zustandslos, als ob sie neu geladen würde. Es speichert keine vorherigen Informationen und navigiert nicht zwischen den Seiten.
Ich habe schon erlebt, dass SEOs aufgrund dessen, was sie nach der Navigation von einer Seite zur anderen sehen, wie z. B. ein kanonisches Tag, das nicht aktualisiert wird, auf die Idee kommen, dass es ein Problem gibt. Aber Google sieht diesen Zustand vielleicht nie.
Entwickler können dies beheben, indem sie den Status mit dem so genannten Geschichte API. Aber wie gesagt, vielleicht ist es kein Problem. Oft sind es nur SEOs, die den Entwicklern Schwierigkeiten machen, weil es für sie seltsam aussieht. Aktualisieren Sie die Seite und sehen Sie, was Sie sehen. Oder noch besser, lassen Sie die Seite durch eines der Google-Testtools laufen, um zu sehen, was es sieht.
Apropos Test-Tools, lassen Sie uns über diese sprechen.
Google Test-Tools
Google verfügt über mehrere Test-Tools, die für JavaScript nützlich sind.
URL-Prüfungstool in der Google Search Console
Dies sollte Ihre Quelle der Wahrheit sein. Wenn Sie eine URL überprüfen, erhalten Sie viele Informationen darüber, was Google gesehen hat, und den tatsächlich gerenderten HTML-Code von seinem System.
Sie haben auch die Möglichkeit, einen Live-Test durchzuführen.
Es gibt einige Unterschiede zwischen dem Haupt-Renderer und dem Live-Test. Der Renderer verwendet zwischengespeicherte Ressourcen und ist ziemlich geduldig. Der Live-Test und andere Testwerkzeuge verwenden Live-Ressourcen und brechen das Rendering frühzeitig ab, weil Sie auf ein Ergebnis warten. Darauf werde ich später im Abschnitt über das Rendering noch genauer eingehen.
Die Screenshots in diesen Tools zeigen auch Seiten mit gemalten Pixeln, was Google beim Rendern einer Seite nicht tut.
Die Tools sind nützlich, um zu sehen, ob Inhalte im DOM geladen sind. Das in diesen Tools angezeigte HTML ist das gerenderte DOM. Sie können nach einem Textausschnitt suchen, um zu sehen, ob er standardmäßig geladen wurde.
Die Tools zeigen Ihnen auch Ressourcen an, die möglicherweise blockiert sind, sowie Fehlermeldungen auf der Konsole, die für die Fehlersuche nützlich sind.
Wenn Sie keinen Zugriff auf die Google Search Console-Eigenschaft für eine Website haben, können Sie trotzdem einen Live-Test durchführen. Wenn Sie auf Ihrer eigenen Website eine Weiterleitung zu einer Eigenschaft hinzufügen, auf die Sie Zugriff auf die Google Search Console haben, können Sie diese URL untersuchen, und das Inspektionstool folgt der Weiterleitung und zeigt Ihnen das Live-Testergebnis für die Seite auf der anderen Domain.
Im Screenshot unten habe ich eine Weiterleitung von meiner Website zur Google-Startseite hinzugefügt. Der Live-Test folgt der Weiterleitung und zeigt mir die Google-Homepage an. Ich habe keinen Zugang zu Googles Google Search Console-Konto, obwohl ich mir das wünschte.
Rich Results Test Werkzeug
Die Rich Results Test Werkzeug ermöglicht es Ihnen, Ihre gerenderte Seite so zu überprüfen, wie Googlebot sie auf dem Handy oder auf dem Desktop sehen würde.
Mobile-Friendly-Test-Tool
Sie können weiterhin das Mobile-Friendly-Test-Tool aber Google hat angekündigt, dass es im Dezember 2023 abgeschaltet wird.
Es hat die gleichen Macken wie die anderen Test-Tools von Google.
Ahrefs
Ahrefs ist das einzige große SEO-Tool, das beim Crawlen des Webs Webseiten rendert, so dass wir Daten von JavaScript-Seiten haben, die kein anderes Tool hat. Wir rendern ~200 Millionen Seiten pro Tag, aber das ist nur ein Bruchteil dessen, was wir crawlen.
Damit können wir nach JavaScript-Weiterleitungen suchen. Wir können auch Links anzeigen, die mit JavaScript eingefügt wurden, was wir mit einem JS-Tag in den Link-Berichten anzeigen:
Im Dropdown-Menü für Seiten im Site Explorer haben wir auch eine Inspektionsoption, mit der Sie den Verlauf einer Seite sehen und mit anderen Crawls vergleichen können. Wir haben dort eine JS-Markierung für Seiten, die mit aktiviertem JavaScript gerendert wurden.
Sie können JavaScript in Site Audit Crawls aktivieren, um mehr Daten in Ihren Audits freizuschalten.
Wenn Sie das JavaScript-Rendering aktiviert haben, stellen wir für jede Seite das rohe und gerenderte HTML zur Verfügung. Verwenden Sie die Lupenoption neben einer Seite im Page Explorer und gehen Sie im Menü auf “View source”. Sie können auch mit früheren Crawls vergleichen und innerhalb des rohen oder gerenderten HTML auf allen Seiten der Website suchen.
Wenn Sie einen Crawl ohne JavaScript und dann einen weiteren mit JavaScript durchführen, können Sie unsere Crawl-Vergleichsfunktionen nutzen, um die Unterschiede zwischen den Versionen zu sehen.
Die SEO Toolbar von Ahrefs unterstützt auch JavaScript und ermöglicht den Vergleich zwischen HTML und gerenderten Versionen von Tags.
Quelle anzeigen vs. inspizieren
Wenn Sie mit der rechten Maustaste in ein Browserfenster klicken, sehen Sie mehrere Optionen, um den Quellcode der Seite anzuzeigen und die Seite zu überprüfen. Quelltext anzeigen” zeigt Ihnen das Gleiche wie eine GET-Anfrage. Dies ist der rohe HTML-Code der Seite.
Inspect zeigt Ihnen das verarbeitete DOM, nachdem Änderungen vorgenommen wurden, und ist näher an dem Inhalt, den Googlebot sieht. Es handelt sich um die Seite, nachdem JavaScript ausgeführt wurde und Änderungen vorgenommen wurden.
Wenn Sie mit JavaScript arbeiten, sollten Sie meistens Inspect statt View Source verwenden.
Manchmal müssen Sie den Quelltext der Ansicht überprüfen
Da Google bei einigen Problemen sowohl das rohe als auch das gerenderte HTML prüft, müssen Sie manchmal dennoch den Quelltext der Ansicht überprüfen. Wenn die Google-Tools Ihnen beispielsweise mitteilen, dass die Seite als noindex markiert ist, Sie aber kein noindex-Tag in der gerenderten HTML-Datei sehen, ist es möglich, dass es in der rohen HTML-Datei vorhanden war und überschrieben wurde.
Für Dinge wie noindex-, nofollow- und canonical-Tags müssen Sie möglicherweise das rohe HTML überprüfen, da sich Probleme übertragen können. Denken Sie daran, dass Google die restriktivsten Anweisungen, die es für die Meta-Robots-Tags gesehen hat, übernimmt und kanonische Tags ignoriert, wenn Sie ihm mehrere kanonische Tags zeigen.
Browsen Sie nicht mit ausgeschaltetem JavaScript
Ich habe diese Empfehlung schon viel zu oft gesehen. Google rendert JavaScript, so dass das, was Sie ohne JavaScript sehen, ganz und gar nicht dem entspricht, was Google sieht. Das ist einfach nur dumm.
Verwenden Sie keinen Google-Cache
Der Cache von Google ist keine zuverlässige Methode, um zu überprüfen, was Googlebot sieht. Was Sie normalerweise im Cache sehen, ist der rohe HTML-Schnappschuss. Ihr Browser feuert dann das JavaScript ab, auf das im HTML verwiesen wird. Das ist nicht das, was Google gesehen hat, als es die Seite gerendert hat.
Um die Sache noch komplizierter zu machen, können Websites ihre Ursprungsübergreifende Ressourcennutzung (CORS) Richtlinie so einrichten, dass die benötigten Ressourcen nicht aus einer anderen Domäne geladen werden können.
Der Cache wird auf webcache.googleusercontent.com gehostet. Wenn diese Domäne versucht, die Ressourcen von der eigentlichen Domäne anzufordern, sagt die CORS-Richtlinie: “Nein, Sie können nicht auf meine Dateien zugreifen.” Dann werden die Dateien nicht geladen, und die Seite sieht im Cache fehlerhaft aus.
Das Cache-System wurde entwickelt, um den Inhalt zu sehen, wenn eine Website nicht verfügbar ist. Als Debugging-Tool ist es nicht besonders nützlich.
In den Anfängen der Suchmaschinen reichte eine heruntergeladene HTML-Antwort aus, um den Inhalt der meisten Seiten zu sehen. Dank des Aufkommens von JavaScript müssen Suchmaschinen nun viele Seiten so darstellen, wie es ein Browser tun würde, damit sie den Inhalt so sehen können, wie ein Nutzer ihn sieht.
Das System, das den Rendering-Prozess bei Google verwaltet, heißt Web Rendering Service (WRS). Google hat ein einfaches Diagramm zur Verfügung gestellt, um zu zeigen, wie dieser Prozess funktioniert.
Nehmen wir an, wir beginnen den Prozess bei URL.
1. Crawler
Der Crawler sendet GET-Anfragen an den Server. Der Server antwortet mit Kopfzeilen und dem Inhalt der Datei, die dann gespeichert wird. Die Kopfzeilen und der Inhalt werden in der Regel in der gleichen Anfrage übermittelt.
Die Anfrage kommt wahrscheinlich von einem mobilen User-Agent, da Google jetzt auf Mobile-First-Indizierung umgestellt hat, aber es wird auch weiterhin mit dem Desktop-User-Agent gecrawlt.
Die Anfragen kommen meist aus Mountain View (CA, USA), aber es gibt auch einige Crawler für lokal angepasste Seiten Wie ich bereits erwähnt habe, kann dies zu Problemen führen, wenn Websites Besucher aus einem bestimmten Land blockieren oder unterschiedlich behandeln.
Es ist auch wichtig zu beachten, dass Google die Ausgabe des Crawling-Prozesses auf dem Bild oben zwar als “HTML” angibt, in Wirklichkeit aber die Ressourcen crawlt und speichert, die für den Aufbau der Seite benötigt werden, wie HTML-, JavaScript- und CSS-Dateien. Außerdem gibt es eine Größenbeschränkung von 15 MB für HTML-Dateien.
2. Verarbeitung
Es gibt eine Menge Systeme, die durch den Begriff “Processing” im Bild verschleiert werden. Ich werde ein paar davon behandeln, die für JavaScript relevant sind.
Ressourcen und Links
Google navigiert nicht von Seite zu Seite, wie es ein Nutzer tun würde. Ein Teil der “Verarbeitung” besteht darin, die Seite auf Links zu anderen Seiten und Dateien zu überprüfen, die zum Aufbau der Seite benötigt werden. Diese Links werden herausgezogen und der Crawl-Warteschlange hinzugefügt, die Google zur Priorisierung und Planung des Crawlings verwendet.
Google zieht Ressourcen-Links (CSS, JS, etc.), die zum Aufbau einer Seite benötigt werden, aus Dingen wie <link> Tags.
Wie bereits erwähnt, werden interne Links, die mit JavaScript hinzugefügt wurden, erst nach dem Rendering erkannt. Das sollte relativ schnell gehen und in den meisten Fällen kein Grund zur Sorge sein. Dinge wie Nachrichtenseiten können die Ausnahme sein, wo jede Sekunde zählt.
Caching
Jede Datei, die Google herunterlädt, einschließlich HTML-Seiten, JavaScript-Dateien, CSS-Dateien usw., wird aggressiv zwischengespeichert. Google wird Ihre Cache-Zeiten ignorieren und eine neue Kopie abrufen, wenn es das möchte. Ich werde im Abschnitt “Renderer” etwas mehr darüber erzählen und erklären, warum das so wichtig ist.
Beseitigung von Duplikaten
Doppelte Inhalte können aus dem heruntergeladenen HTML-Code entfernt werden, bevor er zum Rendering gesendet wird. Darüber habe ich bereits im Abschnitt “Doppelte Inhalte” weiter oben gesprochen.
Die restriktivsten Direktiven
Wie ich bereits erwähnt habe, wählt Google die restriktivsten Anweisungen zwischen HTML und der gerenderten Version einer Seite. Wenn JavaScript eine Anweisung ändert und diese mit der Anweisung in HTML kollidiert, befolgt Google einfach diejenige, die am restriktivsten ist. Noindex hat Vorrang vor index, und noindex in HTML überspringt das Rendering ganz.
3. Rendering-Warteschlange
Eine der größten Befürchtungen vieler SEOs in Bezug auf JavaScript und die zweistufige Indizierung (erst HTML, dann gerenderte Seite) ist, dass die Seiten möglicherweise erst nach Tagen oder sogar Wochen gerendert werden. Als Google dies untersuchte, fand es Folgendes heraus dass die Seiten im Durchschnitt innerhalb von fünf Sekunden zum Renderer gelangen, und das 90. Perzentil lag bei Minuten. Die Zeitspanne zwischen dem Abruf der HTML-Daten und dem Rendering der Seiten sollte also in den meisten Fällen kein Problem darstellen.
Google rendert jedoch nicht alle Seiten. Wie bereits erwähnt, wird eine Seite mit einem Robots-Meta-Tag oder einer Kopfzeile, die ein Noindex-Tag enthält, nicht an den Renderer gesendet. Google wird keine Ressourcen für das Rendern einer Seite verschwenden, die es ohnehin nicht indizieren kann.
Bei diesem Prozess gibt es auch Qualitätskontrollen. Wenn es sich den HTML-Code ansieht oder aus anderen Signalen oder Mustern erkennen kann, dass eine Seite nicht hochwertig genug ist, um indiziert zu werden, dann wird es sich nicht die Mühe machen, diese Seite an den Renderer zu senden.
Es gibt auch eine Besonderheit bei Nachrichtenseiten. Google möchte Seiten auf Nachrichtenseiten schnell indizieren, damit es die Seiten zuerst auf der Grundlage des HTML-Inhalts indizieren und später zurückkommen kann, um diese Seiten zu rendern.
4. Renderer
Der Renderer ist der Bereich, in dem Google eine Seite rendert, um zu sehen, was ein Nutzer sieht. Hier werden das JavaScript und alle Änderungen, die durch JavaScript an der Seite vorgenommen werden, verarbeitet. DOM.
Dazu verwendet Google einen Headless Chrome-Browser, der jetzt “immergrün” ist, d. h. er sollte die neueste Chrome-Version verwenden und die neuesten Funktionen unterstützen. Vor Jahren renderte Google mit Chrome 41, und viele Funktionen wurden damals noch nicht unterstützt.
Google hat mehr Informationen über das WRSdie Dinge wie die Verweigerung von Berechtigungen, Zustandslosigkeit, Abflachung von Light-DOM und Shadow-DOM und vieles mehr enthält, das es wert ist, gelesen zu werden.
Rendering im Web-Maßstab ist vielleicht das achte Weltwunder. Es ist ein ernsthaftes Unterfangen und erfordert eine enorme Menge an Ressourcen. Aufgrund des Umfangs nimmt Google viele Abkürzungen beim Rendering-Prozess, um die Dinge zu beschleunigen.
Zwischengespeicherte Ressourcen
Google verlässt sich stark auf das Caching von Ressourcen. Seiten werden zwischengespeichert. Dateien werden im Cache gespeichert. Nahezu alles wird zwischengespeichert, bevor es an den Renderer gesendet wird. Google lädt nicht bei jedem Seitenaufruf jede einzelne Ressource herunter, denn das wäre für das Unternehmen und die Website-Besitzer zu teuer. Stattdessen werden diese zwischengespeicherten Ressourcen genutzt, um effizienter zu sein.
Eine Ausnahme bilden XHR-Anforderungen, die der Renderer in Echtzeit ausführt.
Es gibt keine Fünf-Sekunden-Zeitüberschreitung
Ein weit verbreiteter SEO-Mythos besagt, dass Google nur fünf Sekunden wartet, um Ihre Seite zu laden. Es ist zwar immer eine gute Idee, Ihre Website schneller zu machen, aber dieser Mythos macht angesichts der oben erwähnten Art und Weise, wie Google Dateien zwischenspeichert, nicht wirklich Sinn. Es lädt eine Seite bereits mit allem, was in seinen Systemen zwischengespeichert ist, und stellt keine Anfragen für neue Ressourcen.
Bei einer Wartezeit von nur fünf Sekunden würde eine Menge Inhalt verpasst.
Der Mythos kommt wahrscheinlich von den Testtools wie dem URL-Inspektions-Tool, bei dem die Ressourcen live abgerufen und nicht zwischengespeichert werden, und sie müssen den Nutzern innerhalb eines angemessenen Zeitraums ein Ergebnis liefern. Es könnte auch daran liegen, dass Seiten für das Crawling nicht priorisiert werden, was den Eindruck erweckt, dass sie lange auf das Rendern und Indizieren warten.
Es gibt kein festes Zeitlimit für den Renderer. Er läuft mit einem beschleunigten Timer, um zu sehen, ob zu einem späteren Zeitpunkt etwas hinzugefügt wird. Er schaut auch in die Ereignisschleife des Browsers, um zu sehen, wann alle Aktionen durchgeführt worden sind. Er ist sehr geduldig, und Sie sollten sich keine Sorgen um eine bestimmte Zeitspanne machen.
Es ist geduldig, aber es hat auch Sicherheitsvorkehrungen für den Fall, dass etwas stecken bleibt oder jemand versucht, Bitcoin auf seinen Seiten zu schürfen. Ja, das ist ein Ding. Wir mussten auch Sicherheitsvorkehrungen für das Bitcoin-Mining einführen und haben sogar eine Studie darüber veröffentlicht.
Was Googlebot sieht
Googlebot wird auf Webseiten nicht aktiv. Er wird nicht auf Dinge klicken oder scrollen, aber das bedeutet nicht, dass er keine Umgehungsmöglichkeiten hat. Solange der Inhalt im DOM geladen wird, ohne dass eine Aktion erforderlich ist, wird Google ihn sehen. Wenn er erst nach einem Klick in den DOM geladen wird, wird der Inhalt nicht gefunden.
Google braucht auch nicht zu scrollen, um Ihren Inhalt zu sehen, denn es hat eine clevere Lösung, um den Inhalt zu sehen. Bei mobilen Geräten lädt es die Seite mit einer Bildschirmgröße von 411×731 Pixeln und passt die Länge auf 12.140 Pixel an.
Im Wesentlichen wird es ein sehr langes Telefon mit einer Bildschirmgröße von 411×12140 Pixeln. Für den Desktop gilt das Gleiche und geht von 1024×768 Pixel auf 1024×9307 Pixel. Ich habe keine aktuellen Tests für diese Zahlen gesehen, und es kann sich ändern, je nachdem wie lang die Seiten sind.
Eine weitere interessante Abkürzung ist, dass Google die Pixel während des Rendering-Prozesses nicht malt. Es braucht Zeit und zusätzliche Ressourcen, um das Laden einer Seite abzuschließen, und es muss nicht unbedingt den endgültigen Zustand mit den gemalten Pixeln sehen. Außerdem sind Grafikkarten in den Bereichen Gaming, Krypto-Mining und KI sehr teuer.
Google muss nur die Struktur und das Layout kennen, und das bekommt es, ohne die Pixel tatsächlich zu malen. Wie Martin drückt es so aus:
Bei der Google-Suche sind uns die Pixel nicht wirklich wichtig, weil wir sie nicht wirklich jemandem zeigen wollen. Wir wollen die Informationen und die semantischen Informationen verarbeiten, also brauchen wir etwas im Zwischenzustand. Wir müssen die Pixel nicht wirklich malen.
Eine visuelle Darstellung kann helfen, das Ausgeschnittene etwas besser zu erklären. Wenn Sie in den Entwicklungswerkzeugen von Chrome auf der Registerkarte “Leistung” einen Test durchführen, erhalten Sie ein Ladediagramm. Der durchgezogene grüne Teil hier stellt die Malphase dar. Für Googlebot passiert das nie, also spart es Ressourcen.
Graue = Downloads
Blau = HTML
Gelb = JavaScript
Lila = Layout
Grün = Malerei
5. Kriechende Warteschlange
Google hat eine Ressource, die ein wenig über Crawl-Budget spricht. Sie sollten jedoch wissen, dass jede Website ihr eigenes Crawl-Budget hat und dass jede Anfrage nach Priorität geordnet werden muss. Google muss auch abwägen zwischen dem Crawlen Ihrer Seiten und dem jeder anderen Seite im Internet.
Neuere Websites im Allgemeinen oder Websites mit vielen dynamischen Seiten werden wahrscheinlich langsamer gecrawlt. Einige Seiten werden seltener aktualisiert als andere, und einige Ressourcen werden möglicherweise auch weniger häufig angefordert.
Für die Darstellung von JavaScript gibt es eine Vielzahl von Optionen. Google hat ein solides Diagramm, das ich nur kurz zeigen werde. Jede Art von SSR, statischem Rendering und Prerendering-Setup ist für Suchmaschinen geeignet. Gatsby, Next, Nuxt, etc. sind alle großartig.
Am problematischsten wird das vollständige clientseitige Rendering sein, bei dem das gesamte Rendering im Browser stattfindet. Während Google wahrscheinlich mit dem clientseitigen Rendering einverstanden sein wird, ist es am besten, eine andere Rendering-Option zu wählen, um andere Suchmaschinen zu unterstützen.
Bing hat auch Unterstützung für JavaScript-Rendering, aber der Umfang ist unbekannt. Soweit ich weiß, unterstützen Yandex und Baidu JavaScript nur in begrenztem Umfang, und viele andere Suchmaschinen haben wenig bis gar keine Unterstützung für JavaScript. Unsere eigene Suchmaschine, Ja,hat Unterstützung, und wir rendern ~200 Millionen Seiten pro Tag. Aber wir rendern nicht jede Seite, die wir crawlen.
Es gibt auch die Möglichkeit der dynamisches Rendering, das Rendering für bestimmte Benutzer-Agenten. Dies ist eine Umgehung, die ich ehrlich gesagt nie empfohlen habe, und ich bin froh, dass Google jetzt auch davon abrät.
In bestimmten Situationen kann es sinnvoll sein, es für bestimmte Bots wie Suchmaschinen oder sogar Social Media Bots zu verwenden. Social Media Bots führen kein JavaScript aus, so dass Dinge wie OG-Tags nicht gesehen werden, es sei denn, Sie rendern den Inhalt, bevor Sie ihn ihnen zur Verfügung stellen.
In der Praxis macht dies die Einrichtung komplexer und erschwert die Fehlerbehebung für SEOs. Es ist definitiv Cloakingobwohl Google sagt, dass dies nicht der Fall ist und dass es damit einverstanden ist.
Hinweis
Wenn Sie das alte AJAX-Crawling-Schema mit Hashbangs (#!), wissen, dass dies veraltet ist und nicht mehr unterstützt wird.
Abschließende Überlegungen
JavaScript ist für SEOs nichts, wovor sie sich fürchten müssen. Hoffentlich hat dieser Artikel dazu beigetragen, dass Sie besser mit JavaScript arbeiten können.
Scheuen Sie sich nicht, auf Ihre Entwickler zuzugehen, mit ihnen zu arbeiten und ihnen Fragen zu stellen. Sie werden Ihre besten Verbündeten sein, wenn es darum geht, Ihre JavaScript-Site für Suchmaschinen zu verbessern.
Haben Sie Fragen? Lassen Sie es mich wissen auf Twitter.
