Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Für die Suche relevante JavaScript-Probleme beheben
Mithilfe dieser Anleitung kannst du JavaScript-Probleme finden und beheben, durch die deine Seite oder bestimmte Inhalte auf JavaScript-Seiten nicht in der Google Suche angezeigt werden. Die Google Suche kann JavaScript zwar grundsätzlich ausführen, allerdings musst du beim Design deiner Seiten und Apps einige Unterschiede und Beschränkungen beachten, damit Google deine Inhalte auch richtig crawlt und rendert. In unserem Leitfaden zu den Grundlagen von JavaScript SEO findest du weitere Informationen dazu, wie du deine JavaScript-Website für die Google-Suche optimieren kannst.
Der Googlebot ist ein verantwortungsvoller Akteur im Web. Seine wichtigste Aufgabe ist es, Websites zu crawlen, ohne dabei die Nutzererfahrung auf diesen Websites zu beeinträchtigen. Der Googlebot und sein Web-Renderingdienst (Web Rendering Service, WRS) analysieren und identifizieren fortlaufend Ressourcen, die keine wesentlichen Seiteninhalte liefern. Solche Ressourcen werden dann unter Umständen nicht abgerufen. Berichts- und Fehleranfragen, die nicht zu wesentlichen Seiteninhalten führen, und ähnliche Arten von Anfragen werden beispielsweise nicht verwendet bzw. werden zum Extrahieren wesentlicher Seiteninhalte nicht benötigt. Durch clientseitige Analysen werden die Aktivitäten des Googlebot und des WRS auf deiner Website möglicherweise nicht vollständig oder nicht korrekt dargestellt. Im Bericht „Crawling-Statistik“ in der Google Search Console kannst du die Googlebot- und WRS-Aktivitäten sowie Feedback zu deiner Website im Blick behalten.
Wenn du vermutest, dass deine Seite oder bestimmte Inhalte auf JavaScript-Seiten nicht in der Google Suche angezeigt werden, weil Probleme mit JavaScript auftreten, geh so vor: Wenn du dir nicht sicher bist, ob JavaScript die Hauptursache ist, folge unserer allgemeinen Fehlerbehebung, um das Problem einzugrenzen.
- Um zu sehen, wie Google eine URL crawlt und rendert, verwende den Test für Rich-Suchergebnisse oder das URL-Prüftool in der Search Console. Dabei kannst du dir die geladenen Ressourcen, die Ausgabe und Ausnahmen der JavaScript-Konsole, das gerenderte DOM sowie zusätzliche Details ansehen.
Wir empfehlen außerdem, JavaScript-Fehler zu erfassen und zu prüfen, die von Nutzern auf deiner Website festgestellt wurden. Dazu gehört auch der Googlebot. So lassen sich mögliche Probleme erkennen, die sich auf die Darstellung von Inhalten auswirken können. Im folgenden Beispiel siehst du, wie JavaScript-Fehler aus dem globalen onerror-Handler protokolliert werden. Einige Arten von JavaScript-Fehlern, wie etwa Fehler beim Parsen, können mit dieser Methode nicht protokolliert werden.
window.addEventListener('error', function(e) { var errorText = [ e.message, 'URL: ' + e.filename, 'Line: ' + e.lineno + ', Column: ' + e.colno, 'Stack: ' + (e.error && e.error.stack || '(no stack trace)') ].join('\n'); // Example: log errors as visual output into the host page. // Note: you probably don't want to show such errors to users, or // have the errors get indexed by Googlebot; however, it may // be a useful feature while actively debugging the page. var DOM_ID = 'rendering-debug-pre'; if (!document.getElementById(DOM_ID)) { var log = document.createElement('pre'); log.id = DOM_ID; log.style.whiteSpace = 'pre-wrap'; log.textContent = errorText; if (!document.body) document.body = document.createElement('body'); document.body.insertBefore(log, document.body.firstChild); } else { document.getElementById(DOM_ID).textContent += '\n\n' + errorText; } // Example: log the error to remote service. // Note: you can log errors to a remote service, to understand // and monitor the types of errors encountered by regular users, // Googlebot, and other crawlers. var client = new XMLHttpRequest(); client.open('POST', 'https://example.com/logError'); client.setRequestHeader('Content-Type', 'text/plain;charset=UTF-8'); client.send(errorText); }); - Achten Sie darauf,
soft 404-Fehler zu vermeiden. In einer Single-Page-Anwendung (SPA) kann das besonders schwierig sein. Wenn du verhindern möchtest, dass Fehlerseiten indexiert werden, kannst du eine oder beide der folgenden Strategien verwenden: - Zu einer URL weiterleiten, unter der vom Server ein
404-Statuscode zurückgegeben wird fetch(`https://api.kitten.club/cats/${id}`) .then(res => res.json()) .then((cat) => { if (!cat.exists) { // redirect to page that gives a 404 window.location.href = '/not-found'; } }); - robots-
meta-Tag mit noindex neu hinzufügen oder vorhandenes Tag entsprechend ändern fetch(`https://api.kitten.club/cats/${id}`) .then(res => res.json()) .then((cat) => { if (!cat.exists) { const metaRobots = document.createElement('meta'); metaRobots.name = 'robots'; metaRobots.content = 'noindex'; document.head.appendChild(metaRobots); } });
Wenn eine SPA clientseitiges JavaScript zur Fehlerbehandlung verwendet, meldet sie oft den HTTP-Statuscode 200 anstelle des richtigen Statuscodes. Dies kann dazu führen, dass Fehlerseiten indexiert und in den Suchergebnissen angezeigt werden.
- Der Googlebot lehnt in der Regel Anfragen nach Nutzerberechtigungen ab.
Funktionen, die eine Nutzerberechtigung erfordern, sind für den Googlebot nicht sinnvoll. Dies gilt dann genauso für alle Nutzer. Wenn du beispielsweise die Camera API als erforderlich angibst, für die eine Nutzerberechtigung benötigt wird, dann kann der Googlebot keine Kamera zur Verfügung stellen. Biete Nutzern stattdessen die Möglichkeit, auf deine Inhalte zuzugreifen, ohne Kamerazugriff erlauben zu müssen. - Verwende keine URL-Fragmente, um unterschiedliche Inhalte zu laden.
Eine SPA kann URL-Fragmente verwenden, z. B. https://beispiel.de/#/produkte, um verschiedene Ansichten zu laden. Das AJAX-Crawlingschema wurde 2015 eingestellt. Du kannst dich also nicht darauf verlassen, dass URL-Fragmente mit dem Googlebot funktionieren. Wir empfehlen dir, die History API zu verwenden, um verschiedene Inhalte basierend auf der URL in einer SPA zu laden. - Bei der Darstellung von Inhalten ist keine Datenpersistenz gewährleistet.
Der WRS lädt jede URL anhand von Server- und Clientweiterleitungen genau wie bei einem regulären Browser. Einen Überblick darüber, wie Inhalte von Google erkannt werden, bietet der Artikel So funktioniert die Google Suche. Der beim ersten Laden erfasste Zustand wird jedoch vom WRS bei wiederholten Seitenaufbauvorgängen nicht beibehalten: - Lokale Speicher- und Sitzungsspeicherdaten werden beim Seitenaufbau gelöscht.
- HTTP-Cookies werden beim Seitenaufbau gelöscht.
- Verwende Inhalts-Fingerabdrücke, um Caching-Probleme mit dem Googlebot zu vermeiden.
Der Googlebot speichert offensiv im Cache, um Netzwerkanfragen und Ressourcennutzung zu reduzieren. Der WRS ignoriert Caching-Header möglicherweise. Dies kann dazu führen, dass der WRS veraltete JavaScript- oder CSS-Ressourcen verwendet. Durch Inhalts-Fingerabdrücke wird dieses Problem vermieden, da ein Fingerabdruck des Inhalts Teil des Dateinamens wird, z. B. main.2bb85551.js. Der Fingerabdruck hängt vom Inhalt der Datei ab, sodass bei Aktualisierungen jedes Mal ein anderer Dateiname generiert wird. Mehr dazu erfährst du im web.dev-Leitfaden zu langlebigen Caching-Strategien. - Nutze in deiner App die Funktionserkennung für alle kritischen APIs und gib bei Bedarf ein Fallback-Verhalten oder Polyfill an.
Manche Webfunktionen werden eventuell noch nicht von allen User-Agents unterstützt oder in bestimmten Fällen absichtlich von diesen deaktiviert. Wenn du beispielsweise Fotoeffekte mit WebGL im Browser renderst, zeigt die Funktionserkennung, dass WebGL vom Googlebot nicht unterstützt wird. Du könntest dann den Fotoeffekt entweder weglassen oder mithilfe von serverseitigem Rendering vorab rendern. Dadurch stünden deine Inhalte allen Nutzern zur Verfügung, auch dem Googlebot. - Prüfe, ob deine Inhalte mit HTTP-Verbindungen kompatibel sind.
Der Googlebot verwendet HTTP-Anfragen, um Inhalte von deinem Server abzurufen. Andere Verbindungstypen wie WebSockets- oder WebRTC-Verbindungen werden nicht unterstützt. Um Probleme mit solchen Verbindungen zu vermeiden, musst du einen HTTP-Fallback-Parameter für das Abrufen von Inhalten bereitstellen sowie über eine robuste Fehlerbehandlung und Funktionserkennung verfügen. - Kontrolliere, ob deine Webkomponenten wie erwartet gerendert werden. Mit dem Test für Rich-Suchergebnisse oder dem URL-Prüftool kannst du prüfen, ob das gerenderte HTML alle erwarteten Inhalte enthält.
WRS fasst Light DOM und Shadow DOM zusammen. Wenn die von dir verwendeten Webkomponenten den <slot>-Mechanismus für Light DOM-Inhalte nicht verwenden, lies in der Dokumentation zur Webkomponente nach, welche Möglichkeiten es gibt, oder verwende stattdessen eine andere Webkomponente. Weitere Informationen zu Best Practices für Webkomponenten - Teste deine Seite anschließend noch einmal mit dem Test für Rich-Suchergebnisse oder dem URL-Prüftool in der Search Console.
Wenn das Problem behoben wurde, sehen Sie ein grünes Häkchen und es werden keine Fehler angezeigt. Falls weiterhin Fehler angezeigt werden, kannst du einen Beitrag im Search Central-Hilfeforum posten.
Sofern nicht anders angegeben, sind die Inhalte dieser Seite unter der Creative Commons Attribution 4.0 License und Codebeispiele unter der Apache 2.0 License lizenziert. Weitere Informationen finden Sie in den Websiterichtlinien von Google Developers. Java ist eine eingetragene Marke von Oracle und/oder seinen Partnern.
Zuletzt aktualisiert: 2025-08-04 (UTC).
[null,null,["Zuletzt aktualisiert: 2025-08-04 (UTC)."],[[["\u003cp\u003eThis guide helps you identify and fix JavaScript issues that may be preventing your website content from appearing correctly in Google Search.\u003c/p\u003e\n"],["\u003cp\u003eUse the Rich Results Test or the URL Inspection Tool to see how Googlebot crawls and renders your web pages, including loaded resources, JavaScript errors, and the rendered DOM.\u003c/p\u003e\n"],["\u003cp\u003eEnsure your single-page application handles soft 404 errors correctly by redirecting to a 404 page or using the noindex meta tag for error pages.\u003c/p\u003e\n"],["\u003cp\u003eAvoid using URL fragments for loading content and rely on the History API instead, and ensure your web components render as expected by using the \u003ccode\u003e<slot>\u003c/code\u003e mechanism for light DOM content.\u003c/p\u003e\n"],["\u003cp\u003eGooglebot has limitations, such as declining permission requests and not supporting data persistence or connections like WebSockets and WebRTC, so design your content accordingly with fallbacks.\u003c/p\u003e\n"]]],["To resolve JavaScript-related search issues, first, test how Google crawls and renders your URLs using the Rich Results Test or URL Inspection Tool. Collect and audit JavaScript errors. Prevent soft 404 errors by redirecting or adding a \"noindex\" meta tag. Avoid relying on user permission requests, URL fragments, or data persistence. Employ content fingerprinting to avoid caching issues. Use feature detection for critical APIs, ensure HTTP connection compatibility, and verify web component rendering. Finally, retest your page after fixes.\n"],null,["Fix Search-related JavaScript problems\n\n\nThis guide helps you identify and fix JavaScript issues that may be blocking your page, or specific content on JavaScript powered pages, from showing up in Google Search.\nWhile Google Search does run JavaScript, there are some differences and limitations that you need to account for when designing your pages and applications to accommodate how crawlers access and render your content.\nOur [guide on JavaScript SEO basics](/search/docs/guides/javascript-seo-basics) has more information on how you can optimize your JavaScript site for Google Search.\n\nGooglebot is designed to be a good citizen of the web. Crawling is its [main priority](/search/blog/2017/01/what-crawl-budget-means-for-googlebot), while making sure it doesn't degrade the experience of users visiting the site.\nGooglebot and its Web Rendering Service (WRS) component continuously analyze and identify resources that don't contribute to essential page content and may not fetch such resources.\nFor example, reporting and error requests that don't contribute to essential page content, and other similar types of requests are unused or unnecessary to extract essential page content. Client-side analytics may not provide a full or accurate representation of Googlebot and WRS activity on your site.\nUse [the crawl stats report in Google Search Console](https://support.google.com/webmasters/answer/9679690) to monitor Googlebot and WRS activity and feedback on your site.\n\n\nIf you suspect that JavaScript issues might be blocking your page, or specific content on JavaScript powered pages, from showing up in Google Search, follow these steps. If you're not sure if JavaScript is the main cause, follow our [general debugging guide](/search/docs/guides/debug) to determine the specific issue.\n\n1. **To test how Google crawls and renders a URL** , use the [Rich Results Test](https://search.google.com/test/rich-results) or the [URL Inspection Tool](https://support.google.com/webmasters/answer/9012289) in Search Console. You can see loaded resources, JavaScript console output and exceptions, rendered DOM, and more information.\n\n\n Optionally, we also recommend collecting and auditing JavaScript errors encountered by users, including Googlebot, on your site to identify potential issues that may affect how content is rendered.\n Here's an example that shows how to log JavaScript errors that are logged in the [global onerror handler](https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onerror). Note that some types of JavaScript errors, such as a parse error, cannot be logged with this method. \n\n ```javascript\n window.addEventListener('error', function(e) {\n var errorText = [\n e.message,\n 'URL: ' + e.filename,\n 'Line: ' + e.lineno + ', Column: ' + e.colno,\n 'Stack: ' + (e.error && e.error.stack || '(no stack trace)')\n ].join('\\n');\n\n // Example: log errors as visual output into the host page.\n // Note: you probably don't want to show such errors to users, or\n // have the errors get indexed by Googlebot; however, it may\n // be a useful feature while actively debugging the page.\n var DOM_ID = 'rendering-debug-pre';\n if (!document.getElementById(DOM_ID)) {\n var log = document.createElement('pre');\n log.id = DOM_ID;\n log.style.whiteSpace = 'pre-wrap';\n log.textContent = errorText;\n if (!document.body) document.body = document.createElement('body');\n document.body.insertBefore(log, document.body.firstChild);\n } else {\n document.getElementById(DOM_ID).textContent += '\\n\\n' + errorText;\n }\n\n // Example: log the error to remote service.\n // Note: you can log errors to a remote service, to understand\n // and monitor the types of errors encountered by regular users,\n // Googlebot, and other crawlers.\n var client = new XMLHttpRequest();\n client.open('POST', 'https://example.com/logError');\n client.setRequestHeader('Content-Type', 'text/plain;charset=UTF-8');\n client.send(errorText);\n\n });\n ```\n2. **Make sure to prevent [`soft 404` errors](/search/docs/crawling-indexing/http-network-errors#soft-404-errors).** In a single-page application (SPA), this can be especially difficult. To prevent error pages from being indexed, you can use one or both of the following strategies:\n - Redirect to a URL where the server responds with a `404` status code. \n\n ```javascript\n fetch(`https://api.kitten.club/cats/${id}`)\n .then(res =\u003e res.json())\n .then((cat) =\u003e {\n if (!cat.exists) {\n // redirect to page that gives a 404\n window.location.href = '/not-found';\n }\n });\n ```\n - Add or change the robots `meta` tag to `noindex`. \n\n ```javascript\n fetch(`https://api.kitten.club/cats/${id}`)\n .then(res =\u003e res.json())\n .then((cat) =\u003e {\n if (!cat.exists) {\n const metaRobots = document.createElement('meta');\n metaRobots.name = 'robots';\n metaRobots.content = 'noindex';\n document.head.appendChild(metaRobots);\n }\n });\n ```\n\n\n When a SPA is using client-side JavaScript to handle errors they often report a `200` HTTP status code instead of the [appropriate status code](/search/docs/crawling-indexing/javascript/javascript-seo-basics#use-meaningful-http-status-codes). This can lead to error pages being indexed and possibly shown in search results.\n3. **Expect Googlebot to decline [user permission requests](https://w3c.github.io/permissions/#permission-registry).** \n Features that require user permission don't make sense for Googlebot, or for all users. For example, if you make the `Camera API` required, Googlebot can't provide a camera to you. Instead, provide a way for users to access your content without being forced to allow camera access.\n4. **Don't use URL fragments to load different content.** \n A SPA may use URL fragments (for example https://example.com/#/products) for loading different views. The [AJAX-crawling scheme has been deprecated](/search/blog/2015/10/deprecating-our-ajax-crawling-scheme) since 2015, so you can't rely on URL fragments to work with Googlebot. We recommend using the [History API](https://developer.mozilla.org/en-US/docs/Web/API/History) to load different content based on the URL in a SPA.\n5. **Don't rely on data persistence to serve content.** \n WRS loads each URL (refer to [How Google Search Works](/search/docs/fundamentals/how-search-works) for an overview of how Google discovers content), following server and client redirects, same as a regular browser. However, WRS does not retain state across page loads:\n - Local Storage and Session Storage data are cleared across page loads.\n - HTTP Cookies are cleared across page loads.\n6. **Use content fingerprinting to avoid caching issues with Googlebot.** \n Googlebot caches aggressively in order to reduce network requests and resource usage. WRS may ignore caching headers. This may lead WRS to use outdated JavaScript or CSS resources. Content fingerprinting avoids this problem by making a fingerprint of the content part of the filename, like `main.2bb85551.js`. The fingerprint depends on the content of the file, so updates generate a different filename every time. Check out the [web.dev guide on long-lived caching strategies](https://web.dev/articles/http-cache#versioned-urls) to learn more.\n7. **Ensure that your application uses [feature detection](https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Feature_detection) for all critical APIs that it needs and provide a fallback behavior or polyfill where applicable.** \n Some web features may not yet be adopted by all user agents and some may intentionally disable certain features. For example, if you use WebGL to render photo effects in the browser, feature detection shows that Googlebot doesn't support WebGL. To fix this, you could skip the photo effect or decide to use server-side rendering to prerender the photo effects, which makes your content accessible to everyone, including Googlebot.\n8. **Make sure your content works with HTTP connections.** \n Googlebot uses HTTP requests to retrieve content from your server. It does not support other types of connections, such as [WebSockets](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API) or [WebRTC](https://developer.mozilla.org/en-US/docs/Glossary/WebRTC) connections. To avoid problems with such connections, make sure to provide an HTTP fallback to retrieve content and use robust error handling and [feature detection](#feature-detection).\n9. **Make sure your web components render as expected.** Use the [Rich Results Test](https://search.google.com/test/rich-results) or the [URL Inspection Tool](https://support.google.com/webmasters/answer/9012289) to check if the rendered HTML has all content you expect. \n WRS flattens the [light DOM and shadow DOM](/web/fundamentals/web-components/shadowdom#lightdom). If the web components you use aren't using [`\u003cslot\u003e` mechanism](/web/fundamentals/web-components/shadowdom#slots) for light DOM content, consult the documentation of the web component for further information or use another web component instead. For more information, see [best practices for web components](/search/docs/guides/javascript-seo-basics#web-components).\n10. **After you fix the items in this checklist, test your page** with the [Rich Results Test](https://search.google.com/test/rich-results) or the [URL inspection tool](https://search.google.com/search-console) in Search Console again.\n\n If you fixed the issue, a green check mark appears and no errors display. If you still see errors, post in the [Search Central help community](https://support.google.com/webmasters/community)."]]
