TL;DR Google rendert JavaScript, die meisten KI-Crawler tun das nicht. Elementor-Tabs, Akkordeons und Toggles liegen serverseitig im DOM und sind nur per CSS oder JS versteckt. Im Roh-HTML stehen sie also grundsätzlich drin. Kritisch wird es bei Lazy-Loading, AJAX-Nachladen, Display Conditions und Loop-Grid-Pagination. Prüfen statt annehmen: Roh-HTML ansehen, JavaScript abschalten, gerendertes HTML vergleichen. Kein Test beweist dir eine Indexierung oder eine Zitierung in KI-Antworten. Kurz gesagt: Semly hilft dir, deine KI-Sichtbarkeit laufend zu überwachen, statt einmal zu raten.
Elementor-Inhalte auf KI-Sichtbarkeit prüfen – darum geht es
Stell dir vor, du baust eine schöne Seite mit Elementor. Alles sitzt, die Tabs klappen auf, das Akkordeon öffnet sich sauber. Im Browser sieht alles perfekt aus. Nur: Was dein Browser zeigt, ist nicht automatisch das, was ein Crawler zu sehen bekommt.
Hier kommt der wichtigste Unterschied ins Spiel. Google rendert JavaScript. Der Googlebot lädt also deine Seite, führt das JavaScript aus und sieht danach das fertige Ergebnis. Die meisten KI-Crawler machen das nicht. Sie holen sich das initiale HTML, also das, was der Server direkt ausliefert, und lesen darin. Kein Nachrendern, kein Klick auf deinen Tab.
Für dich heißt das: Wenn ein Inhalt erst durch JavaScript entsteht, ist er für viele KI-Systeme schlicht nicht da. Das betrifft genau die Bereiche, die du in Elementor gern nutzt: Tabs, Akkordeons, Toggles und dynamische Bereiche.
Zwei Begriffe solltest du dabei im Kopf behalten. Das Roh-HTML ist das, was der Server ausliefert, bevor irgendein Skript läuft. Das gerenderte HTML ist das, was nach dem Ausführen von JavaScript im Browser steht. Beide können sich stark unterscheiden.
Und noch etwas Wichtiges: Sichtbarkeit ist nicht gleich Ranking und schon gar nicht gleich Zitierung. Wenn ein Text im Roh-HTML steht, heißt das nur, dass ein Crawler ihn lesen kann. Ob er ihn bewertet, einordnet oder in einer Antwort nennt, ist eine andere Frage. Genau hier setzt Semly an und macht KI-Sichtbarkeit messbar.
Nach diesem Guide kannst du selbst prüfen, ob deine Elementor-Inhalte im Roh-HTML stehen, du erkennst die typischen Fallen und du weißt, was du konkret ändern kannst.
Was Google sieht – und was KI-Crawler sehen
Der Unterschied lässt sich am besten mit zwei Klassen erklären. Google arbeitet in drei Phasen: Crawling, Rendering, Indexing. Der Bot holt die Seite, rendert sie mit einer headless Chromium Umgebung und indexiert dann das Ergebnis. Deshalb sieht Google auch Inhalte, die erst per JavaScript entstehen.
Die großen KI-Crawler arbeiten anders. GPTBot, OAI-SearchBot, ClaudeBot und PerplexityBot lesen primär das initiale HTML. Sie laden JavaScript-Dateien teilweise, führen sie aber in der Regel nicht aus. Eine Analyse von 23 KI-Crawlern kam zum Ergebnis, dass rund 69 Prozent kein JavaScript ausführen können. Andere Untersuchungen zeigen, dass selbst bei Bots, die JS-Dateien anfordern, die Ausführung praktisch bei null liegt.
Kurz gesagt: Google sieht dein gerendertes DOM, KI-Crawler sehen meist nur das Roh-HTML. Alles, was per JavaScript nachgeladen wird, ist für sie unsichtbar.
| Googlebot | KI-Crawler (GPTBot, ClaudeBot, PerplexityBot) | |
|---|---|---|
| JavaScript-Rendering | Ja, über die Rendering-Queue | In der Regel nein |
| Was gelesen wird | Gerendertes HTML | Initiales HTML |
| Versteckte Inhalte im DOM | Werden gesehen | Werden gesehen, wenn sie im Roh-HTML stehen |
| Per JS nachgeladene Inhalte | Werden gesehen | Bleiben unsichtbar |
Was heißt das für versteckte Inhalte? Solange der Text im Roh-HTML steht und nur per CSS versteckt ist, kann ihn ein nicht-rendernder Crawler lesen. Wird der Text aber erst durch JavaScript erzeugt, fehlt er komplett.
So verhält sich Elementor bei Tabs, Akkordeons und dynamischen Bereichen
Elementor ist ein mächtiges Werkzeug, und genau deshalb lohnt sich ein Blick darauf, wie die einzelnen Widgets mit Inhalten umgehen. Wichtig: Es geht hier nicht um gut oder schlecht, sondern um das technische Verhalten.
Tabs, Akkordeons und Toggles
Bei Tabs, Akkordeons und Toggles ist die Lage meist entspannt. Die Inhalte liegen serverseitig im DOM. Sie werden nur per CSS oder JavaScript versteckt, damit du sie im Browser auf- und zuklappen kannst. Im Roh-HTML sind sie also grundsätzlich vorhanden.
Ein Punkt, den viele übersehen: ARIA-Attribute wie aria-expanded oder aria-controls beschreiben nur den Zustand eines Elements. Sie liefern keinen Text. Ein Crawler liest also nicht "dieser Tab ist geschlossen", sondern den eigentlichen Inhalt, wenn er im HTML steht.
Ein praktischer Tipp: Halte das erste Element eines Akkordeons oder Tabs standardmäßig geöffnet. So ist der wichtigste Inhalt sofort sichtbar, auch ohne Interaktion.
Loop Grid, Popups und Display Conditions
Hier wird es spannender. Ein Loop Grid kann Inhalte per "Load on Click", "Infinite Scroll" oder AJAX nachladen. Diese nachgeladenen Elemente entstehen erst im Browser, also clientseitig. Für Crawler, die kein JavaScript ausführen, sind sie damit unsichtbar.
Popups und Display Conditions sind ein neutraler Prüfpunkt. Wenn ein Bereich nur unter bestimmten Bedingungen erscheint, lohnt es sich zu schauen, ob er im Roh-HTML steht oder erst später eingefügt wird.
Was steht typischerweise im Roh-HTML?
- Texte in Tabs, Akkordeons und Toggles
- Überschriften und Fließtext in statischen Bereichen
- Bilder mit Alt-Text
- Strukturierte Daten, wenn sie serverseitig ausgegeben werden
Was fehlt oft im Roh-HTML?
- Per AJAX nachgeladene Loop-Grid-Einträge
- Inhalte, die per Lazy-Loading erst beim Scrollen geladen werden
- Bereiche, die per Display Condition eingeblendet werden
Vorbereitung – das brauchst du, bevor du prüfst
Bevor du loslegst, sorg dafür, dass du alles zur Hand hast. Sonst verlierst du dich schnell in halben Tests.
Bereit zum Prüfen?
- Zugriff auf deine Website und den Elementor-Editor
- Ein Browser mit Entwicklertools (Chrome, Firefox oder Edge reichen)
- Die Möglichkeit, JavaScript im Browser zu deaktivieren
- Optional: ein Crawl-Tool wie Screaming Frog
- Eine Beispielseite mit mindestens einem Tab oder Akkordeon
Wähle für den Start eine Seite, die dir wichtig ist. Eine Produktseite, eine Leistungsseite oder eine Landingpage mit Akkordeon. Diese Seite nutzt du als roten Faden durch alle Schritte.
Schritt für Schritt: Elementor-Inhalte auf KI-Sichtbarkeit prüfen
Jetzt wird es praktisch. Arbeite die Schritte der Reihe nach ab. Jeder Schritt hat einen Zweck, und du solltest wissen, was er dir zeigt und was nicht.
Schritt 1 – Roh-HTML ansehen
Zweck: Prüfen, ob deine Inhalte im Quelltext stehen.
Öffne deine Beispielseite und schau dir den Quelltext an (Rechtsklick, "Seitenquelltext anzeigen"). Suche mit Strg+F nach einem Satz aus deinem Tab oder Akkordeon.
Worauf achten: Findest du den Text, ist er im Roh-HTML vorhanden. Findest du ihn nicht, wird er wahrscheinlich per JavaScript erzeugt.
Typisches Fehlerbild: Der Text taucht nur in einer JSON-Datei oder gar nicht auf.
Schritt 2 – JavaScript deaktivieren und Seite neu laden
Zweck: Sehen, was ohne Skripte übrig bleibt.
Deaktiviere JavaScript in den Entwicklertools oder über die Browsereinstellungen und lade die Seite neu.
Worauf achten: Bleiben deine Texte sichtbar? Dann sind sie serverseitig vorhanden. Verschwindet der ganze Bereich, kommt er aus JavaScript.
Typisches Fehlerbild: Die Seite sieht kaputt aus, aber der Text ist noch da. Das ist ein gutes Zeichen für die Lesbarkeit.
Schritt 3 – Gerendertes HTML mit Roh-HTML vergleichen
Zweck: Den Unterschied zwischen beiden Versionen sehen.
Nutze die Entwicklertools oder eine Erweiterung, die dir den gerenderten Quelltext zeigt. Vergleiche ihn mit dem Roh-HTML aus Schritt 1.
Worauf achten: Inhalte, die nur im gerenderten HTML stehen, sind für KI-Crawler unsichtbar.
Typisches Fehlerbild: Der Tab-Text erscheint erst nach dem Rendern.
Schritt 4 – Google-Sicht prüfen
Zweck: Sehen, was Google sieht.
Nutze die URL-Prüfung in der Search Console oder den Rich Results Test. Beide zeigen dir das gerenderte HTML aus Google-Sicht.
Worauf achten: Wenn Google den Inhalt sieht, heißt das noch nicht, dass KI-Crawler ihn auch sehen.
Typisches Fehlerbild: Alles grün, und du denkst, du bist fertig. Bist du nicht.
Schritt 5 – Crawl-Simulation mit Text-only vs. JS-Rendering
Zweck: Beide Welten direkt vergleichen.
Ein Crawl-Tool wie Screaming Frog kann eine Seite einmal ohne JavaScript und einmal mit JavaScript rendern. Die Funktion "Show Differences" zeigt dir, was nur im gerenderten Zustand existiert.
Worauf achten: Alles, was nur im JS-Rendering auftaucht, ist ein Risiko für KI-Sichtbarkeit.
Typisches Fehlerbild: Du siehst große Unterschiede und weißt nicht, wo du anfangen sollst. Fang mit den wichtigsten Seiten an.
Schritt 6 – Reale Bot-Zugriffe in Logfiles prüfen
Zweck: Sehen, ob KI-Bots wirklich kommen.
Schau in deine Server-Logs und filtere nach den User-Agents der KI-Bots, etwa GPTBot, OAI-SearchBot, ClaudeBot oder PerplexityBot.
Worauf achten: Kommen die Bots überhaupt? Und welche Seiten rufen sie ab?
Typisches Fehlerbild: Die Bots kommen, aber nur auf wenige Seiten. Dann fehlt es an interner Verlinkung.
| Test | Was er beweist | Was er nicht beweist |
|---|---|---|
| Roh-HTML ansehen | Text ist im Quelltext vorhanden | Ob Google oder KI ihn bewertet |
| JavaScript aus | Inhalt ist serverseitig da | Ob er indexiert wird |
| Gerendertes HTML vergleichen | Was JS zusätzlich erzeugt | Ob KI-Crawler das auch sehen |
| URL-Prüfung / Rich Results Test | Was Google sieht | Was KI-Crawler sehen |
| Crawl-Simulation | Unterschied Text-only vs. JS | Echte Bot-Zugriffe |
| Logfiles | Reale Bot-Aufrufe | Ob Inhalte zitiert werden |
Warum widersprechen sich Ergebnisse manchmal? Weil jeder Test eine andere Perspektive zeigt. Google sieht mehr als ein KI-Crawler. Deshalb ist die Kombination entscheidend, nicht ein einzelner grüner Haken.
Typische Fehler und wie du sie behebst
Diese Stolperfallen begegnen dir immer wieder. Hier sind sie mit Symptom und Fix.
- Inhalte nur per JS nachgeladen → Symptom: Text fehlt im Quelltext. → Fix: Inhalte serverseitig ausgeben lassen oder statisch einbauen.
- Lazy-Loading blockiert Text → Symptom: Text erscheint erst beim Scrollen. → Fix: Wichtige Texte direkt laden, Lazy-Loading nur für Bilder nutzen.
- Display Conditions verstecken Bereiche → Symptom: Bereich fehlt im Roh-HTML. → Fix: Kritische Inhalte ohne Bedingung ausliefern.
- Erstes Tab-Element geschlossen → Symptom: Wichtigster Inhalt ist versteckt. → Fix: Erstes Element standardmäßig öffnen.
- Verlass auf einen einzigen Test → Symptom: Du fühlst dich sicher, obwohl eine Lücke bleibt. → Fix: Mehrere Tests kombinieren und regelmäßig wiederholen.
Warum siehst du Text im Browser, aber nicht im Quelltext? Weil dein Browser JavaScript ausführt und der Crawler nicht. Genau das ist der Kern des Problems.
Was du danach tun kannst
Ein Check ist ein guter Anfang, aber kein Dauerzustand. Deine Website ändert sich, deine Inhalte wachsen, und die KI-Crawler entwickeln sich weiter. Deshalb lohnt sich ein Plan.
So bringst du deine Inhalte nach vorn:
- Bringe wichtige Inhalte ins Roh-HTML, statisch oder per Server-Side-Rendering.
- Ergänze strukturierte Daten als JSON-LD, damit Maschinen deine Inhalte besser einordnen.
- Baue Inhalte als klare Fragen und Antworten auf, das hilft sowohl Menschen als auch KI-Systemen.
- Prüfe regelmäßig statt einmal. KI-Sichtbarkeit ist ein laufender Prozess.
Kleine Seite oder viele Seiten?
- Wenige wichtige Seiten: Du kannst manuell prüfen und die Schritte oben regelmäßig wiederholen.
- Viele Seiten oder ein Shop: Ein Monitoring-Tool spart dir Zeit und zeigt dir Veränderungen früh.
Genau hier kommt Semly ins Spiel. Semly ist eine Plattform für Generative Engine Optimization und KI-Sichtbarkeit. Sie analysiert Prompts, Wettbewerber und Quellen und zeigt dir, wie deine Marke in Antworten von KI-Systemen wie ChatGPT, Gemini und Google AI vorkommt. Statt eines einmaligen Checks bekommst du einen laufenden Überblick und einen konkreten Aktionsplan.
Mini-Glossar
- Roh-HTML: Das, was der Server ausliefert, bevor JavaScript läuft.
- Gerendertes HTML: Das, was nach dem Ausführen von JavaScript im Browser steht.
- SSR: Server-Side-Rendering, Inhalte werden schon auf dem Server erzeugt.
- ARIA: Attribute, die den Zustand von Elementen beschreiben, aber keinen Text liefern.
Wenn du deine Elementor-Inhalte auf KI-Sichtbarkeit prüfen willst, fang mit einer Seite an. Schau in den Quelltext, teste ohne JavaScript und vergleiche. Danach weißt du genau, wo du nachbessern musst. Und mit Semly behältst du im Blick, ob deine Marke in den KI-Antworten wirklich ankommt.
