JavaScript SEO: Wie verarbeitet Google JavaScript Seiten?

Wir bei Talha Aslan und Team erleben genau an dieser Stelle in technischen Audits die meisten Überraschungen. Zum Beispiel sieht ein Produktraster im Browser perfekt aus, kommt aber im ersten HTML bei Google fast leer an. In diesem Leitfaden erklären wir JavaScript SEO Schritt für Schritt auf Basis der offiziellen Google Dokumentation. Außerdem zeigen wir, wie Sie mit der URL Prüfung in der Search Console sehen, was Google tatsächlich erfasst.

In welchen drei Phasen verarbeitet Google eine JavaScript Seite?

Die Google Dokumentation zu den JavaScript SEO Grundlagen teilt den Ablauf in Crawling, Rendering und Indexierung. Diese Trennung ist wichtig, denn jede Phase scheitert auf ihre eigene Weise. Deshalb finden Sie keine Lösung, solange Sie das Problem keiner Phase zuordnen.

• Crawling: Der Googlebot ruft die URL ab, prüft die robots.txt und erhält das rohe HTML vom Server.
• Rendering: Google führt das JavaScript der Seite in einer aktuellen Umgebung auf Chromium Basis aus und baut daraus das DOM.
• Indexierung: Google bewertet Text, Links und Tags im gerenderten HTML. Danach entscheidet Google, ob die Seite in den Index kommt.

Kurz gesagt: Die Seite in Ihrem Browser und die erste Antwort an Google sind nicht dasselbe. Dazwischen liegt ein Renderschritt, und dieser Schritt kostet Zeit und Ressourcen. Der Kern von JavaScript SEO besteht also darin, den Abstand zwischen beiden Versionen zu verkleinern.

Was sieht der Googlebot beim Crawling zuerst?

Bei der ersten Anfrage erhält der Googlebot nur das rohe HTML, das Ihr Server sendet. Enthält dieses HTML bereits Titel, Meta Tags, Links und Fließtext, versteht Google die Seite sofort. Entsteht der Inhalt dagegen komplett im Browser, besteht das rohe HTML oft nur aus einem leeren Container und einigen Dateiverweisen.

Beim Crawling prüft der Googlebot zuerst die robots.txt. Sperrt sie die URL, fragt Google die Seite gar nicht ab, folglich erreicht sie auch kein Rendering. Danach liest der Googlebot die href Werte im rohen HTML aus und stellt neue URLs in die Crawlwarteschlange. Deshalb beschleunigen Links im ersten HTML die Entdeckung.

Ein Beispielszenario: Ein Onlineshop auf example.com lädt die Produkte einer Kategorie erst nach dem Seitenaufruf über eine API. Beim ersten Crawl sieht der Googlebot also weder Produktnamen noch Produktlinks. Die Produkte erscheinen erst nach dem Rendering. Somit entdeckt Google neue Produkte langsamer.

Was ist die Renderwarteschlange und warum verzögert sie die Indexierung?

Laut Google stellt der Googlebot alle Seiten mit dem HTTP Statuscode 200 in die Warteschlange für das Rendering. Eine Ausnahme bilden Seiten, bei denen ein Robots Meta Tag oder Header die Indexierung untersagt. Die Seiten warten, bis Google Ressourcen frei hat, und diese Wartezeit unterscheidet sich von Website zu Website.

Google nennt keine feste Dauer für diese Verzögerung. Daher können wir Ihnen keine verlässliche Zahl dazu geben, wie lange das Rendering dauert. Bekannt ist nur, dass Rendering getrennt vom Crawling stattfindet. Zudem lässt sich von außen nicht immer erkennen, in welcher Phase eine Seite gerade steckt.

In der Praxis bedeutet das: Wenn Sie wichtige Inhalte und Links dem JavaScript überlassen, kommt ein zusätzlicher Schritt hinzu. Besonders spürbar ist das bei schnell wechselnden Inhalten wie News, Aktionen oder Lagerbeständen. Außerdem kann ein Skript, das beim Rendering abbricht, den Inhalt komplett verschwinden lassen.

Warum entscheidet das gerenderte HTML über die Indexierung?

Nach dem Rendering trifft Google die Entscheidung über die Indexierung anhand des gerenderten HTML. Das heißt, die Version, die um Rankings konkurriert, entsteht in der Renderumgebung von Google. Sie entspricht nicht zwingend dem Endzustand im Browser Ihrer Besucher. Meist stimmen beide überein, allerdings können Zeitüberschreitungen, gesperrte Dateien oder fehlerhafter Code den Unterschied vergrößern.

Google liest zudem die Links aus dem gerenderten HTML erneut aus und schickt neue URLs ins Crawling. Somit findet Google auch Links, die JavaScript nachträglich einfügt. Trotzdem geschieht diese Entdeckung erst in einem zweiten Durchlauf. Sicher sieht Google nur den Inhalt, der nach dem Rendering tatsächlich im DOM steht.

Die allgemeine Diagnose nicht indexierter Seiten ist nicht Thema dieses Artikels. Dafür empfehlen wir unsere Anleitung zu nicht indexierten Seiten in der Search Console. Hier konzentrieren wir uns nur auf Ursachen, die aus JavaScript stammen.

Was unterscheidet clientseitiges und serverseitiges Rendering?

Beim clientseitigen Rendering (CSR) entsteht das HTML im Browser des Besuchers durch JavaScript. Beim serverseitigen Rendering (SSR) baut der Server das HTML und sendet eine fertige Seite. Statisches Rendering erzeugt die Seiten vorab beim Build. Hydration macht anschließend das vom Server gelieferte HTML im Browser interaktiv.

Die Tabelle zeigt es deutlich: Auf Seiten mit Suchtraffic beseitigt der Inhalt in der ersten Antwort die meisten JavaScript SEO Risiken von Anfang an.

Welche Renderingmethode passt zu Ihrer Website?

Die passende Methode hängt vom Zweck der Seite ab. Zum Beispiel erscheint ein Verwaltungsbereich hinter einem Login nie in den Suchergebnissen, daher funktioniert dort clientseitiges Rendering problemlos. Kategorie, Produkt, Leistungs und Blogseiten tragen dagegen organischen Traffic. Für diese Seiten ist HTML vom Server oder aus dem Build die sicherere Wahl.

Serverseitiges Rendering für Vue Projekte haben wir in unserem Artikel Was ist Nuxt und wann brauchen Sie Vue SSR beschrieben. Nutzen Sie React oder ein anderes Framework, gilt dieselbe Logik. Seiten, die für die Suche zählen, sollten in der ersten Antwort aussagekräftiges HTML liefern.

Bei dieser Entscheidung stellen wir drei Fragen. Erstens: Erwartet die Seite Besucher aus der Suche? Zweitens: Wie oft ändert sich ihr Inhalt? Drittens: Kann das Entwicklerteam serverseitigen Code dauerhaft pflegen? Die Antwort liegt meist dort, wo sich alle drei überschneiden. So begrenzen Sie außerdem technische Schulden von Anfang an.

Sollten Sie dynamisches Rendering noch einsetzen?

Dynamisches Rendering bedeutet, dass Bots vorgerendertes HTML erhalten, während Nutzer die JavaScript lastige Version bekommen. In der Dokumentation zum dynamischen Rendering bezeichnet Google dieses Verfahren als Behelfslösung und nicht als empfohlene Lösung. Als Grund nennt Google die zusätzliche Komplexität und den Ressourcenbedarf.

Stattdessen empfiehlt Google serverseitiges Rendering, statisches Rendering oder Hydration. Laut Google gilt dynamisches Rendering für sich genommen in der Regel nicht als Cloaking. Liefern Sie Nutzern und Crawlern allerdings völlig unterschiedliche Inhalte, kann das als Cloaking gelten. Beide Versionen müssen also inhaltlich ähnlich bleiben.

Betreiben Sie bereits ein älteres Setup mit dynamischem Rendering, müssen Sie es nicht sofort abschalten. Für ein neues Projekt lohnt sich dieser Weg trotzdem kaum, weil es dauerhafte Lösungen gibt. Sonst halten Sie zwei Versionen ständig synchron, und Fehler entstehen genau in diesen Lücken.

Warum sollten Links immer a Elemente mit href sein?

Google erkennt Links zuverlässig nur dann, wenn sie a Elemente mit einem href Attribut sind. Laut der Dokumentation zu crawlbaren Links funktionieren auch Links, die JavaScript später einfügt, solange sie dieses Markup behalten. Probleme entstehen bei Elementen, die auf Klicks reagieren, aber keine echte URL tragen.

Nach den Beispielen in der Google Dokumentation gelten folgende Muster:

• Empfohlen: ein a Element mit echter URL im href, etwa ein Link auf /produkte/kategorie/schuhe.
• Empfohlen: ein a Element mit echtem href und zusätzlichem onclick. Der Browser führt das Ereignis aus, Google folgt der URL.
• Nicht empfohlen: ein a Element, das ohne href nur über onclick navigiert.
• Nicht empfohlen: ein href auf einem span oder ähnlichen Element sowie frameworkeigene Attribute wie routerLink.
• Riskant: ein href Wert, der mit javascript: beginnt.

Codiert ein Menü seine Kategorien zum Beispiel nur als Buttons, findet Google den Weg zu diesen Kategorien schwer. Die Lösung ist einfach: Geben Sie jedem Navigationspunkt eine echte URL und steuern Sie das Klickverhalten dann mit JavaScript.

Wie strukturieren Sie URLs in einer Single Page Application?

Eine Single Page Application (SPA) tauscht Ansichten innerhalb eines einzigen HTML Dokuments aus. Ältere Setups trennten diese Ansichten über den Teil der URL nach dem Zeichen #, etwa example.com/#/produkte. Google rät davon ab, über solche Fragmente unterschiedliche Inhalte zu laden.

Stattdessen empfiehlt Google die History API. Damit erhält jede Ansicht eine eigene echte URL, zum Beispiel example.com/produkte/. Zudem schreiben Sie Links mit echtem href und steuern die Navigation über pushState. Folglich landet ein Besucher nach dem Neuladen oder Teilen der URL auf demselben Inhalt.

Prüfen Sie dann noch einen Punkt: Liefert der Server beim direkten Aufruf einer Ansicht den richtigen Inhalt? In manchen Setups zeigt jede URL außer der Startseite beim direkten Aufruf eine leere Seite oder einen Fehler. Dann kann der Googlebot diese URLs nicht rendern und somit auch nicht indexieren.

Warum funktioniert ein per JavaScript gesetztes oder entferntes noindex oft nicht?

Laut Google kann Google beim Auftreffen auf ein noindex Tag das Rendering und die Ausführung von JavaScript überspringen. Steht noindex also im rohen HTML, bringt das Entfernen per JavaScript möglicherweise nichts. Google kann die Seite ausschließen, ohne sie je zu rendern.

Auch der umgekehrte Weg ist riskant. Fehlt noindex im rohen HTML und fügt JavaScript es später hinzu, bleibt unklar, in welcher Phase Google es sieht. Kurz gesagt: Seiten, die in den Index sollen, dürfen im ursprünglichen Code kein noindex enthalten. Bei Seiten, die draußen bleiben sollen, gehört das Tag direkt in die Serverantwort.

Zeigt die Search Console diesen Status für Ihre Seiten, erklärt unser Artikel Durch noindex Tag ausgeschlossen das Vorgehen Schritt für Schritt. Entscheidend ist hier, ob das Tag vom Server oder aus einem Skript stammt.

Wie vermeiden Sie Soft 404 Fehler in einer Single Page Application?

Ein Soft 404 liegt vor, wenn eine nicht existierende Seite trotzdem den Statuscode 200 liefert. In SPAs passiert das häufig, denn der Server sendet für jede URL dieselbe App Datei und erst der Code im Browser zeigt die Fehlermeldung. Die Google Dokumentation räumt ein, dass aussagekräftige Statuscodes in diesem Aufbau unmöglich oder unpraktisch sein können.

Für diesen Fall nennt Google zwei Wege:

1. Leiten Sie per JavaScript auf eine URL weiter, bei der der Server tatsächlich den Statuscode 404 liefert.
2. Ergänzen Sie in der Fehleransicht per JavaScript ein noindex Robots Meta Tag.

Der zweite Weg scheint der obigen noindex Warnung zu widersprechen. Hier soll die Seite allerdings ohnehin nicht in den Index, und Google schließt sie aus, sobald es das Tag sieht. Trotzdem bleibt ein echter Statuscode 404 oder 410 vom Server die sauberste Lösung, wann immer das möglich ist.

Können Sie Titel, Meta Description und strukturierte Daten per JavaScript setzen?

Ja. Laut Google Dokumentation können Sie das title Element und die Meta Description per JavaScript setzen oder ändern. Ebenso können Sie strukturierte Daten im Format JSON-LD per JavaScript erzeugen und in die Seite einfügen. Google empfiehlt in jedem Fall, diese Umsetzung zu testen.

In der Praxis birgt die Auslieferung im ersten HTML allerdings weniger Risiko. Denn Vorschauen in sozialen Netzwerken und manche anderen Crawler führen kein JavaScript aus. Außerdem treten Fehler wie derselbe Titel auf allen Seiten häufiger in Apps mit clientseitigem Routing auf.

Ein Beispielszenario: Eine SPA auf example.com vergisst, den Titel beim Wechsel auf eine Produktseite zu aktualisieren. Folglich tragen alle Produktseiten den Titel der Startseite. Solche Fehler finden wir schnell über das gerenderte HTML in der URL Prüfung. Die Kontrolle dauert wenige Minuten und verhindert echte Verluste.

Was passiert, wenn die robots.txt Ihre JavaScript Dateien sperrt?

Google rendert kein JavaScript aus gesperrten Dateien oder auf gesperrten Seiten. Sperrt die robots.txt also das Skript, das Ihren Inhalt erzeugt, bleibt die gerenderte Seite unvollständig. Dasselbe passiert, wenn die robots.txt die API Adressen sperrt, die Ihre Daten liefern.

Teams machen diesen Fehler meist in guter Absicht. Zum Beispiel sperrt jemand den Ordner /api/ oder /assets/, um Crawlbudget zu sparen, und übersieht, dass der Seiteninhalt davon abhängt. Im Browser wirkt die Seite voll, für Google bleibt sie leer.

Zur Kontrolle prüfen Sie in der URL Prüfung die geladenen Seitenressourcen, denn dort erscheinen gesperrte Ressourcen. Weitere häufige Probleme haben wir in unserem Artikel zu typischen Fehlern in der robots.txt gesammelt. Kurz gesagt: Sperren Sie keine Ressource, die Inhalte erzeugt.

Wie sehen Sie das gerenderte HTML in der URL Prüfung der Search Console?

Das Tool zur URL Prüfung (englisch URL Inspection) in der Search Console ist der offizielle Weg, um zu sehen, wie Google Ihre Seite erfasst. Laut der Search Console Hilfe zeigt es das zurückgegebene rohe HTML, die HTTP Header, die Ausgabe der Konsole und die geladenen Seitenressourcen. Für die Diagnose bei JavaScript SEO gehen Sie so vor:

1. Öffnen Sie die Property in der Search Console und geben Sie oben im Suchfeld die vollständige URL ein.
2. Für die indexierte Version öffnen Sie „Gecrawlte Seite anzeigen“.
3. Den aktuellen Stand prüfen Sie im Livetest (englisch Test live URL): Starten Sie ihn und öffnen Sie danach „Getestete Seite anzeigen“.
4. Suchen Sie im HTML nach wichtigen Inhalten wie Produktname, Haupttext und Links.
5. Prüfen Sie den Screenshot. Laut Hilfe gibt es den Screenshot der gerenderten Seite nur im Livetest.
6. Kontrollieren Sie unter „Weitere Informationen“ nicht geladene Ressourcen und die Ausgabe der Konsole.

Diese zusätzlichen Antwortdaten erscheinen nicht in jedem Fall. Für die indexierte Version zeigt die Hilfe sie nur, wenn die URL bei Google ist. Im Livetest erscheinen sie nur, wenn die URL für Google verfügbar ist.

Wie vergleichen Sie rohes HTML mit gerendertem HTML?

Ziel des Vergleichs ist die Prüfung, ob der Inhalt nach dem Rendering bei Google dem entspricht, was Sie im Browser sehen. Öffnen Sie zunächst den Seitenquelltext im Browser, also das rohe HTML vom Server. Sehen Sie sich dann die HTML Ausgabe der getesteten Seite in der URL Prüfung an, also den gerenderten Zustand.

Beim Vergleich prüfen wir diese Punkte einzeln:

• Stimmen Titel und Meta Description in beiden Versionen?
• Stehen Haupttext, Produktnamen und Preise im gerenderten HTML?
• Widersprechen Canonical und Robots Meta Tag der Serverantwort?
• Erscheinen Navigation und interne Links als a Elemente mit href?
• Sind die strukturierten Daten im gerenderten HTML vollständig?

Ändert JavaScript das Canonical Tag, wählt Google unter Umständen eine andere Version. Solche Konflikte behandeln wir ausführlich in unserem Leitfaden zu Canonical Fehlern in der Search Console. Meist genügt der Vergleich einmal pro Template.

Warum sind Caching und Content Fingerprinting wichtig?

Laut Google Dokumentation cacht der Googlebot aggressiv, um Netzwerkanfragen und Ressourcenverbrauch zu senken. Zudem ignoriert der Web Rendering Service (WRS) unter Umständen Cache Header. Daher kann Google Ihre Seite mit einer veralteten JavaScript oder CSS Datei rendern.

Als Lösung empfiehlt Google Content Fingerprinting. Dabei nehmen Sie einen Hash des Dateiinhalts in den Dateinamen auf, etwa main.2bb85551.js. Ändert sich die Datei, ändert sich auch der Name, also lädt Google sie als neue Ressource. Die meisten modernen Buildtools erledigen das bereits standardmäßig.

Ein Beispielszenario: example.com veröffentlicht ein neues Release, aber das Skript behält seinen Dateinamen. Das neue HTML passt nicht mehr zum alten Skript, deshalb bricht das Rendering ab und Inhalte fehlen. Dateinamen mit Fingerprint beseitigen dieses Risiko weitgehend.

Welche Browserfunktionen nutzt der Googlebot nicht?

Die Google Dokumentation zur Fehlerbehebung bei JavaScript erklärt, dass der Googlebot bestimmte Browserzustände nicht wie ein Nutzer beibehält. Hängt Ihr Inhalt davon ab, sieht Google ihn eventuell nicht. Deshalb sollten Sie diese Punkte schon in der Konzeptphase einplanen:

• Berechtigungsanfragen: Der Googlebot lehnt Anfragen wie den Kamerazugriff ab, also darf Inhalt nie davon abhängen.
• Zustand: Local Storage, Session Storage und HTTP Cookies bleiben zwischen Seitenaufrufen nicht erhalten.
• Verbindungsarten: Der Googlebot unterstützt keine WebSockets oder WebRTC, daher brauchen Sie einen Weg über HTTP.
• Funktionsumfang: WebGL etwa unterstützt der Googlebot nicht. Nutzen Sie Feature Detection und Ausweichlösungen für kritische APIs.
• Web Components: Beim Rendering verschmilzt Light DOM mit Shadow DOM. Komponenten ohne slot verlieren dabei womöglich Inhalte.

Speichert eine Website zum Beispiel die Sprachwahl im Speicher und zeigt Inhalte danach an, sieht der Googlebot jedes Mal den ersten Bildschirm. Der Hauptinhalt muss also ohne jede Interaktion auf der Seite stehen.

Verstecken Lazy Loading und Infinite Scroll Inhalte vor Google?

Lazy Loading lädt Bilder und manche Inhalte erst, wenn der Besucher sie gleich sieht. Google nennt das eine gute Strategie für Bandbreite und Performance, verlangt aber die Einhaltung seiner Richtlinien zum Lazy Loading. Kritisch wird es, wenn Inhalte erst nach einer Interaktion wie Scrollen oder Klicken erscheinen.

Der Googlebot bewegt sich nicht wie ein Mensch über die Seite. Deshalb fehlen Produkte hinter einem Button zum Nachladen oder Bewertungen, die beim Scrollen kommen, womöglich im gerenderten HTML. Geben Sie stattdessen jeder Seite einer paginierten Liste eine echte URL und verlinken Sie diese mit a href.

Die richtige Einrichtung für Bilder erklären wir im Artikel Was ist Lazy Loading. Die Ladezeit Seite von JavaScript behandelt unser Leitfaden JavaScript Ladezeit und Performance optimieren. Hier geht es um Sichtbarkeit, nicht um Geschwindigkeit.

Schadet JavaScript grundsätzlich der SEO?

Nein, JavaScript schadet der SEO nicht grundsätzlich. Google führt JavaScript in einer aktuellen Umgebung auf Chromium Basis aus, und viele Websites mit modernen Frameworks ranken problemlos. Das Problem liegt nicht in der Sprache. Es beginnt dann, wenn Inhalte und Links nur im Browser existieren.

In Audits teilen wir JavaScript in zwei Gruppen. Die erste Gruppe verbessert die Interaktion: Filteranimationen, Warenkorbfenster und Formularprüfung. Dieser Code birgt selten ein SEO Risiko. Die zweite Gruppe erzeugt Inhalte und Navigation. Genau sie verdient Aufmerksamkeit, weil der Text, den Google sieht, direkt von ihr abhängt.

Daher ist „JavaScript entfernen“ meist die falsche Entscheidung. Liefern Sie stattdessen den Hauptinhalt in der ersten Antwort und überlassen Sie die Interaktion dem JavaScript. Das schützt sowohl die Nutzererfahrung als auch die Sichtbarkeit. Weitere technische Grundlagen finden Sie in unseren zehn Tipps zum technischen SEO.

Wie protokollieren Sie JavaScript Fehler, die Google betreffen?

Die Google Dokumentation zur Fehlerbehebung nennt einen globalen onerror Handler, um JavaScript Fehler von Nutzern und vom Googlebot zu protokollieren. Allerdings weist dieselbe Seite darauf hin, dass manche Fehlerarten wie Parse Fehler so nicht im Protokoll landen. Betrachten Sie dieses Protokoll also als nützlichen Hinweis, nicht als vollständige Liste.

Auch der Rich Results Test und die URL Prüfung zeigen geladene Ressourcen, die Ausgabe der Konsole und das gerenderte DOM. Bei der laufenden Wartung prüfen wir zuerst diese Tools und danach die Serverlogs. So erkennen wir, ob ein Fehler aus dem Skript oder vom Server kommt.

Wiederholen Sie nach einer Korrektur denselben Test, denn auch Google empfiehlt diesen letzten Schritt. Für einen schnellen Blick auf den allgemeinen technischen Zustand einer Seite prüft unser SEO Check Titel, Meta Tags und Linkstruktur.

Wie sieht eine JavaScript SEO Checkliste Schritt für Schritt aus?

Diese Reihenfolge nutzen wir vor jedem neuen Template und jedem großen Release. Die Reihenfolge zählt, denn ein Problem in einem frühen Schritt verfälscht die Ergebnisse späterer Schritte.

1. Listen Sie die Seitentypen mit Suchtraffic auf: Startseite, Kategorie, Produkt, Leistung und Blog.
2. Prüfen Sie das rohe HTML jedes Typs. Stehen Titel, Haupttext und Links in der ersten Antwort?
3. Fehlt der Inhalt dort, planen Sie den Wechsel zu serverseitigem oder statischem Rendering.
4. Stellen Sie sicher, dass jeder Navigationspunkt ein a Element mit echtem href ist.
5. Überführen Sie Ansichten mit # über die History API in echte URLs.
6. Bestätigen Sie, dass die robots.txt Skripte und API Adressen für Inhalte erlaubt.
7. Liefern Sie noindex, Canonical und Titel korrekt im rohen HTML aus.
8. Richten Sie für nicht existierende Seiten einen echten Statuscode 404 oder eine noindex Lösung ein.
9. Verwenden Sie Content Fingerprinting in Dateinamen.
10. Starten Sie in der URL Prüfung einen Livetest und vergleichen Sie gerendertes mit rohem HTML.

Für eine schnelle Prüfung einzelner Seiten hilft Ihnen zudem unser Leitfaden zum SEO Check einer Seite in zehn Minuten.

Wer behebt und überwacht JavaScript SEO Probleme auf Ihrer Website?

JavaScript SEO Probleme verschwinden selten durch eine einzige Einstellung. Entwicklung, Content und SEO müssen auf dasselbe Bild schauen. Deshalb erfassen wir bei Talha Aslan und Team zunächst für jedes Template den Unterschied zwischen rohem und gerendertem HTML. Danach erhalten Ihre Entwickler eine Liste mit umsetzbaren Korrekturen.

Mit dem Release endet die Arbeit nicht. Über Wochen beobachten wir in der Search Console den Indexierungsstatus, die gecrawlten Seiten und Renderfehler. Den vollständigen Umfang dieses Prozesses finden Sie auf unserer Seite zur SEO Beratung. Rankings garantieren wir nicht. Wir schaffen jedoch die technische Grundlage, damit Google Ihre Seiten vollständig sieht.

Vermuten Sie ein ähnliches Problem auf Ihrer Website, senden Sie uns einige Beispiel URLs. Ein Angebot mit Umfang und Ablauf für Ihre Website können Sie über unsere Leistungsseite zur SEO Beratung anfordern. Gemeinsam klären wir dann, ob das Problem aus JavaScript oder aus einer anderen technischen Ursache stammt.

Grundlagen: Was ist Online Marketing? Arten, Beispiele und Vorgehen auf einer Seite, mit einem interaktiven Film durch das Gehirn.