KI-Landingpages
Aus einer Datenbank mit tausenden Einträgen lassen sich Seiten bauen, die in der Google-Suche und in KI-Antworten vorkommen — aber nur, wenn jede einzelne Seite eine echte Frage vollständig beantwortet. Die Grenze zur Massenware zieht Google in seiner Spam-Richtlinie selbst, und zwar über Absicht und Nutzen, nicht über die Frage, ob eine KI beteiligt war. Die Sharpness Solutions GmbH aus Oldenburg (Niedersachsen) baut solche Seitenstrecken aus Produktdaten, Fahrzeugbeständen, Objektlisten und Ersatzteilkatalogen: KI beim Anreichern, ein Abschaltkriterium für Seiten, die nichts beantworten. Diese Website ist selbst aus strukturierten Daten abgeleitet und lässt sich deshalb nachsehen statt glauben. Stand dieser Seite: 17. August 2026. Telefon 0441 21 21 63 0, Mo–Fr 9:00–16:00 Uhr.
Anfragen zu diesem Thema kommen aus zwei entgegengesetzten Richtungen. Entweder liegt ein Angebot auf dem Tisch, das mehrere tausend Seiten zum Pauschalpreis verspricht, und jemand im Haus hat ein ungutes Gefühl dabei. Oder es gibt einen gepflegten Bestand — ein paar tausend Fahrzeuge, einige zehntausend Ersatzteilpositionen, einige hundert Objekte — und die Erkenntnis, dass davon in der Suche nichts ankommt, weil alles hinter einer Filtermaske liegt. Beide Fälle enden bei derselben Frage: Wo genau verläuft die Grenze zwischen einer nützlichen Seitenstrecke und dem, was Google als Massenware behandelt.
Der Katalog ist vollständig, die Suche funktioniert, und trotzdem hat jede Kombination dieselbe Adresse. Was nicht als eigene URL existiert, kann weder ranken noch zitiert werden. In unseren Fahrzeugprojekten stehen die Filterzustände deshalb in der Adresse — search[make][], search[model][], search[garage][] —, und damit sind Trefferlisten verlinkbar, teilbar und kampagnenfähig. Das ist die Rohform. Eine Seite ist es noch nicht.
Das Angebot rechnet die Kombinatorik hoch: Marke mal Modell mal Ort mal Baujahr, und schon steht eine große Zahl im Angebot. Was fehlt, ist die Angabe, wie viele dieser Kombinationen im Bestand überhaupt Treffer haben und wie viele Attribute je Treffer gepflegt sind. Ohne diese Zahl ist die Seitenzahl eine Rechenaufgabe, kein Plan. Wir fangen deshalb mit dem Datenaudit an, nicht mit dem Seitenzähler.
Es gibt schon eine Seitenstrecke, sie ist ausgerollt, und Google hat den größeren Teil davon nie aufgenommen — Status „gecrawlt, zurzeit nicht indexiert“ oder gar nicht abgeholt. Das ist kein Zufall und keine Strafe, sondern eine Einschätzung: Der Aufwand für diese Seiten lohnt sich aus Googles Sicht nicht. Woran das liegt, sieht man an den Seiten selbst, nicht an der robots.txt.
In der Runde sitzt jemand, der gelesen hat, dass Google KI-Inhalte abstraft, und jemand, der gelesen hat, dass es keine Rolle spielt. Beide haben halb recht. Die Richtlinie ist methodenneutral formuliert: Sie fragt nach Absicht und Nutzen, nennt generative KI aber ausdrücklich als Beispiel für den Missbrauchsfall. Der Unterschied liegt nicht im Werkzeug, sondern darin, ob am Ende jemand etwas erfährt.
Der Unterschied zwischen einer tragfähigen Seitenstrecke und Massenware steht in einem Satz: eine Seite je echter Frage, nicht eine Seite je Suchbegriff. Eine Keyword-Seite entsteht aus einer Wortliste — Ort, Marke und Adjektiv werden getauscht, der Rest bleibt gleich. Eine Fragenseite entsteht aus einem Bestand und beantwortet, was jemand wissen will, bevor er anruft: welche Sattelzugmaschinen mit Euro-6-Motor gerade verfügbar sind, was sie kosten, an welchem Standort sie stehen, was dokumentiert ist und was nicht. Diese Antwort steht in keiner Wortliste. Sie steht in Ihrer Datenbank, oder sie steht nirgends.
Im Fahrzeughandel liegt die Rohform bereits vor, und deshalb reden wir zuerst über diese Projekte. Beim Autohaus Brüggemann stehen über 2.000 Fahrzeuge in einer gemeinsamen Suche — am 17. August 2026 waren es 2.151 —, verteilt auf sechs Standorte, filterbar über 24 Marken. Nord Automobile in Rastede führt einen vierstelligen Bestand, am selben Tag 1.058 Angebote, und filtert über einen eigenen AJAX-Endpunkt ohne Seitenneuladen. Eschen Nutzfahrzeuge liefert den eigenen Bestand in fünf Sprachfassungen aus — Deutsch, Englisch, Russisch, Polnisch, Spanisch —, weil der Handel mit schweren Nutzfahrzeugen Exportgeschäft ist. Alle drei fahren dieselbe eigene TYPO3-Extension für die Fahrzeugsuche; jede Weiterentwicklung kommt allen Installationen zugute. Ein Bestand, dessen Filterzustände in der Adresse stehen, ist die halbe Strecke — die andere Hälfte ist die Seite selbst, und die ist Arbeit, nicht Konfiguration.
Die eigentliche Arbeit ist der Schnitt. Aus fünf Attributen lassen sich rechnerisch zehntausende Kombinationen bilden, von denen die meisten null oder zwei Treffer haben und keine Frage abbilden, die jemand stellt. Wir wählen die Achsen aus, für die beides zutrifft: Es gibt Suchnachfrage, und es gibt genug gepflegte Datensätze, um eine vollständige Antwort zu geben. Für jede Achse wird eine Untergrenze festgelegt — Mindestzahl an Treffern, Mindestabdeckung der Pflichtfelder. Was darunter liegt, wird nicht veröffentlicht. Diese Untergrenze ist nicht Kosmetik, sondern der Punkt, an dem sich das Verfahren von seiner missbräuchlichen Variante unterscheidet.
Beim Anreichern ist ein Sprachmodell nützlich, und zwar an vier Stellen. Es macht aus einer Attributliste einen lesbaren Absatz, der die Werte in Sätzen nennt statt in einer Tabelle. Es übersetzt Ausstattungscodes und Herstellerkürzel in Klartext, den ein Käufer versteht. Es findet Synonyme und Fragevarianten, unter denen dieselbe Sache gesucht wird. Und es bringt den Textanteil in weitere Sprachen. Wie klein dieser Anteil ist, zeigt der Aufbau bei Eschen Nutzfahrzeuge: Erstzulassung, Laufleistung, Motorisierung und Bildmaterial sind sprachneutral und stehen ohne zweite Erfassung in allen fünf Sprachfassungen; übersetzt wird nur, was wirklich Text ist. Genau dieser Rest ist die Stelle, an der ein Modell Arbeit abnimmt. In allen vier Fällen arbeitet es mit vorhandenen Werten. Es erzeugt keine.
Substanz erfinden kann es nicht, und der Versuch endet nicht bei schwachem Text, sondern bei Falschangaben. Wo im Datensatz kein Verbrauchswert steht, ergänzt ein Modell einen plausiblen — und für neue Personenkraftwagen verlangt die Pkw-EnVKV in der Werbung Angaben zu Verbrauch, CO2-Emission und CO2-Klasse. Plausibel ist hier das Gegenteil von richtig. Ob ein Datensatz unter diese Pflicht fällt, entscheidet die Quelle und nicht die Vorlage, weshalb die Werte durchgereicht und nicht erzeugt werden. Dasselbe gilt außerhalb des Pflichtbereichs für Unfallfreiheit, Wartungshistorie, Vorbesitzerzahl und Zusicherungen aller Art. Wo keine Daten sind, entsteht durch KI keine Seite, sondern Füllmaterial mit Haftungsrisiko. Das ist die harte Grenze, und sie deckt sich mit der Grenze der Google-Richtlinie: Beide fragen, ob am Ende etwas gesagt wird, das vorher nicht dastand.
Technisch heißt das eine klare Trennung. Pflichtangaben und Preise gehen unverändert aus der Quelle in die Ausgabe, ohne Modell dazwischen — bei Eigenentwicklungen aus dem führenden System, bei Immobilienbeständen über OpenImmo, das XML-Austauschformat der Branche, samt der Pflichtangaben aus dem Energieausweis, bei mobile.de über die Search-API des eigenen Händlerkontos, sonst aus dem ERP-Export. Die KI-Anreicherung läuft in der Aufbereitung, nicht zur Laufzeit, damit jede Passage reproduzierbar bleibt und geprüft werden kann. Jede generierte Passage ist an die Feldwerte gebunden, aus denen sie entstanden ist; fehlt das Feld, entsteht kein Satz, sondern eine Lücke in der Prüfliste. Und die Anreicherung entscheidet nie darüber, ob eine Seite veröffentlicht wird. Das entscheidet die Datenlage.
Google nennt den Missbrauchsfall „scaled content abuse“ und beschreibt ihn als das Erzeugen vieler Seiten, die vor allem dem Zweck dienen, Suchrankings zu manipulieren, statt Nutzern zu helfen — im Original: „generated for the primary purpose of manipulating search rankings“. Die Beispiele, die Google selbst aufführt, sind konkret: generative KI oder vergleichbare Werkzeuge einsetzen, um viele Seiten ohne Mehrwert für Nutzer zu erzeugen; fremde Inhalte abgreifen und mit minimaler Änderung neu verpacken; Material aus mehreren Quellen zusammensetzen, ohne dass echter Nutzen entsteht; mehrere Websites anlegen, um die Masse zu verschleiern; Seiten mit Suchbegriffen füllen, deren Text keinen Sinn ergibt. Formal definiert wurde das im Spam-Update vom März 2024.
Der zweite einschlägige Punkt heißt „doorway abuse“ und trifft Seitenstrecken besonders leicht. Gemeint sind Seiten, die auf sehr ähnliche Suchanfragen zielen und Nutzer über Zwischenstationen führen, die weniger nützlich sind als das eigentliche Ziel. Eine Seite, die nur eine Überschrift, drei getauschte Wörter und einen Link zur Kategorieseite trägt, ist genau das — unabhängig davon, wie sie entstanden ist. Der Prüfstein ist einfach und unbequem: Wenn eine Seite nichts enthält, was die Zielseite nicht besser hätte, ist sie eine Zwischenstation. Deshalb bekommt jede Seite in einer Strecke, die wir bauen, einen eigenen Bestand, eigene Werte und eine eigene Antwort — oder sie geht nicht online.
Und der Satz, der auf dieser Seite am meisten wert ist: Die Richtlinie enthält keine Zahl, an der sich das messen ließe. Keine Prozentwerte, keine Mindestanteile, keine Schwellen. In SEO-Blogs kursieren Angaben wie „mindestens 60 Prozent abweichender Inhalt“, „mindestens drei Quellen je Seite“ oder „ab 30 Prozent betroffener URLs folgt eine sitewide-Abstrafung“. Diese Zahlen stehen nirgends bei Google. Wer damit argumentiert, zitiert nicht Google, sondern sich selbst — und verkauft eine Schwelle, die man rechnerisch mit einem Prozentpunkt mehr überspringen könnte. Es gibt keine Schwelle. Es gibt die Frage, ob eine Seite jemandem etwas beantwortet, und diese Frage lässt sich nicht in Prozent beantworten, sondern nur an der Seite selbst.
Eine Seitenstrecke, die nur für Google gebaut ist, verschenkt die andere Hälfte. Immer mehr Fragen laufen über ChatGPT, Perplexity, Microsoft Copilot und die KI-Übersichten der Google-Suche, und dort wird nicht eine Seite ausgeliefert, sondern ein Absatz zitiert. Daraus folgen vier Anforderungen an den Text: die Antwort im ersten Satz statt nach drei Absätzen Anlauf; Abschnitte, die aus dem Zusammenhang gerissen noch stimmen; Entitäten im Klartext, also Firmenname, Standort und Fachbegriff im Absatz statt in der Kopfzeile; und Zahlen statt Adjektive, weil sich nur Konkretes wiedergeben lässt. Dieselbe Bauweise nützt auch der klassischen Suche. Es sind nicht zwei Seiten, es ist eine.
Dazu kommt die maschinenlesbare Schicht. Je Seitentyp das passende Markup — Product und Offer mit Preis und Verfügbarkeit, ItemList für Trefferlisten, FAQPage für Direktantworten, HowTo für Abläufe, Service für Leistungen, Organization und LocalBusiness für die Firmenfakten, BreadcrumbList für die Einordnung. Dazu eine llms.txt als kuratierte Einstiegsdatei und, vorher, die banalste aller Prüfungen: Kommen die Bots überhaupt durch. GPTBot, OAI-SearchBot, PerplexityBot, ClaudeBot und Bingbot lassen sich in der robots.txt einzeln steuern, und sie tun Unterschiedliches: OAI-SearchBot, PerplexityBot und Bingbot holen die Inhalte für die Antwort, GPTBot und ClaudeBot sammeln vor allem Trainingsdaten. Google-Extended steht in derselben Datei, ist aber kein Crawler — die Kennung steuert nur die Nutzung in den Gemini-Anwendungen und hat auf die KI-Übersichten der Google-Suche keinen Einfluss, weil die sich aus dem normalen Suchindex bedienen. Und oft blockt eine Firewall oder ein CDN, was die robots.txt längst erlaubt. Was das im Einzelnen bedeutet, steht auf unserer Leistungsseite zu AEO.
Ob wir das können, lässt sich an dieser Website nachsehen, ohne uns zu fragen. Aus strukturierten Daten abgeleitet sind hier 19 Regionsseiten, 19 Technologieseiten, 14 Leistungsseiten, 5 Branchenseiten, 26 Referenz-Cases und zehn Landingpages, diese eingeschlossen — jede davon zusätzlich in einer englischen Fassung, sodass die Sitemap über zweihundert Adressen führt (Stand 17. August 2026). Dazu FAQPage-, HowTo-, Service-, ItemList- und BreadcrumbList-Markup, eine llms.txt und eine eigene Leistungsseite zu AEO. Das ist genau die Technik, um die es hier geht — nur mit Substanz je Seite statt mit ausgetauschten Platzhaltern. Es beweist nicht, dass es in Ihrem Markt funktioniert. Es beweist, dass wir das Verfahren betreiben und nicht nur beschreiben, und es lässt sich mit einem Blick in den Quelltext nachprüfen.
Vorausgesetzt sind drei Dinge, und keines davon ist Technik. Erstens saubere, vollständige Daten: Müll mal tausend bleibt Müll, nur teurer. Vor dem ersten Entwurf messen wir deshalb die Feldabdeckung je Attribut und die Dublettenquote; daraus ergibt sich, wie viele Seiten der Bestand trägt. Zweitens eine Redaktion, die Stichproben liest — nicht alle Seiten, aber regelmäßig ein Dutzend, und mit dem Recht, eine Vorlage zurückzuweisen. Drittens Geduld: Indexierung passiert nicht auf Zuruf. Neue Strecken rollen wir in Wellen aus, damit sich die Aufnahme beobachten und die Vorlage nachschärfen lässt, bevor der Rest folgt.
Abraten gehört bei diesem Thema dazu, und die Gründe sind dieselben drei. Zu dünne Daten: Wenn je Datensatz ein Bild und zwei Attribute vorliegen, entsteht keine Seite, die eine Frage beantwortet, und die Anreicherung kaschiert das nur. Ein Sortiment ohne Suchnachfrage: Wenn niemand nach diesen Kombinationen sucht, ist die Strecke aufwendig und wirkungslos — dann ist eine gute Kategorieseite die richtige Antwort. Fehlende Bereitschaft zur Pflege: Ein Bestand, der nicht aktualisiert wird, produziert nach einem halben Jahr Seiten zu Dingen, die es nicht mehr gibt. In diesen Fällen sagen wir das vor der Beauftragung. Wenn ein Projekt sich nicht rechnet, ist es günstiger, das früh zu hören.
Ablauf
Ein CSV mit fünfzig Datensätzen sagt mehr als eine Anforderungsliste. Sie bekommen eine schriftliche Einschätzung: welche Fragen sich aus diesem Bestand beantworten lassen, wie viele Seiten er tragen kann, wo Felder fehlen und in welcher Größenordnung der Aufwand liegt — auch dann, wenn die Antwort lautet, dass eine gute Kategorieseite reicht und wir davon abraten. Eine belastbare Zahl steht danach, aus dem Datenaudit. Sharpness Solutions GmbH, Edewechter Landstraße 161, 26131 Oldenburg. Telefon 0441 21 21 63 0, Mo–Fr 9:00–16:00 Uhr, info@sharpness.de.
Zuerst sehen wir in die Daten, nicht in die Suchvolumina. Wie viele Datensätze gibt es, welche Attribute sind zu welchem Anteil gefüllt, wie hoch ist die Dublettenquote, welche Pflichtangaben fehlen. Ergebnis ist ein Zahlenblatt, aus dem hervorgeht, wie viele Seiten dieser Bestand überhaupt tragen kann. Manchmal endet das Projekt hier, und das ist der günstigste Zeitpunkt dafür.
Wir sammeln die Fragen, die im Markt tatsächlich gestellt werden — aus Suchanfragen, aus Ihrer eigenen Shop- oder Website-Suche, aus dem Vertriebspostfach und aus den Formulierungen, mit denen Kunden anrufen. Daraus entsteht eine Liste von Fragen, nicht von Keywords, und danach die Prüfung, welche davon Ihr Bestand vollständig beantworten kann.
Jetzt wird entschieden, welche Achsen eine eigene Seite bekommen und welche in einer Filteransicht bleiben. Zu jeder Achse gehört eine Untergrenze: Mindestzahl an Treffern und Mindestabdeckung der Pflichtfelder. Diese Grenze steht schriftlich, bevor die erste Vorlage entsteht, weil sie später über jede einzelne Veröffentlichung entscheidet.
Die Seitenvorlage entsteht im vorhandenen System — TYPO3, Shopware 6 oder WordPress —, mit Direktantwort im ersten Absatz, Pflichtangaben an fester Stelle, Markup je Seitentyp und der KI-Anreicherung in der Aufbereitung. Abgenommen wird an rund zwanzig echten Datensätzen, darunter absichtlich die schlecht gepflegten. Wer nur die Vorzeigefälle testet, testet nichts.
Veröffentlicht wird in Etappen, nicht auf einmal: eine erste Welle, dann die Beobachtung, ob und wie schnell sie aufgenommen wird. Seiten unterhalb der Untergrenze bleiben auf der Prüfliste in der Redaktion. Parallel prüfen wir den Bot-Zugriff in robots.txt, Firewall und CDN, weil dort mehr Strecken scheitern als an der Textqualität.
Danach ist es eine Pflegeaufgabe. Wir sehen an, welche Seiten indexiert sind, welche nur gecrawlt wurden und welche gar nichts bringen — und schalten letztere ab oder fassen sie zusammen. Dazu der Lebenszyklus der Bestände: ausgelistete Objekte brauchen Weiterleitung, 410 oder Sammelseite. Wer die Pflege abgibt, tut das über die Service-Level-Staffel: BASIC 24, STANDARD 8, ADVANCED 4, PREMIUM 2 Stunden Reaktionszeit, Monatspauschale netto je Projekt.
Gemeint sind Seiten, die aus strukturierten Daten erzeugt werden — Produktdaten, Fahrzeugbestand, Objektlisten, Ersatzteilkataloge — und jeweils eine konkrete Suchfrage vollständig beantworten. Die Struktur, die Werte und die Pflichtangaben kommen aus der Datenbank; ein Sprachmodell übernimmt nur das Anreichern: Attributlisten in lesbare Absätze überführen, Fachkürzel übersetzen, Fragevarianten finden, den Textanteil in weitere Sprachen bringen. Der Unterschied zur Massenware liegt im Schnitt: eine Seite je echter Frage, nicht eine Seite je Suchbegriff.
Nein, nicht wegen des Werkzeugs. Googles Spam-Richtlinie ist methodenneutral formuliert: Sie fragt nach Absicht und Nutzen einer Seite, nicht nach dem Entstehungsweg. Allerdings nennt Google generative KI ausdrücklich als Beispiel für „scaled content abuse“ — nämlich dann, wenn damit viele Seiten ohne Mehrwert für Nutzer erzeugt werden. Entscheidend ist also, ob auf der Seite etwas steht, das jemandem weiterhilft. Ein mit KI angereicherter Absatz über einen real vorhandenen Bestand ist unproblematisch. Ein erfundener Absatz über nichts ist es nicht.
Google beschreibt damit das Erzeugen vieler Seiten, die vor allem dem Zweck dienen, Suchrankings zu manipulieren, statt Nutzern zu helfen. Die aufgeführten Beispiele: generative KI oder ähnliche Werkzeuge nutzen, um viele Seiten ohne Mehrwert zu erzeugen; fremde Inhalte abgreifen und minimal verändert neu verpacken; Material aus mehreren Quellen ohne echten Nutzen zusammensetzen; mehrere Websites anlegen, um die Masse zu verschleiern; Seiten mit Suchbegriffen füllen, deren Text keinen Sinn ergibt. Formal definiert wurde der Begriff im Spam-Update vom März 2024.
Nein. Googles Spam-Richtlinie enthält keine Zahl, an der sich das messen ließe — keine Prozentwerte, keine Mindestanteile, keine Schwellen. Angaben wie „mindestens 60 Prozent abweichender Inhalt“, „mindestens drei Quellen je Seite“ oder „ab 30 Prozent betroffener URLs folgt eine sitewide-Abstrafung“ kursieren in SEO-Blogs, stehen aber nirgends bei Google. Wer damit argumentiert, zitiert sich selbst. Prüfbar ist nur die Frage, ob eine Seite eine Frage beantwortet, die eine andere Seite nicht schon besser beantwortet — und das entscheidet sich am Einzelfall, nicht an einer Quote.
Google beschreibt „doorway abuse“ als Seiten, die auf sehr ähnliche Suchanfragen zielen und Nutzer über Zwischenstationen führen, die weniger nützlich sind als das eigentliche Ziel. Eine Seite mit getauschter Überschrift, drei ausgewechselten Wörtern und einem Link zur Kategorieseite ist genau das. Der Prüfstein: Enthält die Seite etwas, das die Zielseite nicht besser hätte? Wenn nein, ist sie eine Zwischenstation und gehört nicht online. Deshalb bekommt in den Strecken, die wir bauen, jede Seite eigene Datensätze, eigene Werte und eine eigene Antwort.
Diese Zahl fällt aus dem Datenaudit, nicht aus der Kombinatorik. Rechnerisch ergeben fünf Attribute zehntausende Kombinationen, von denen die meisten null oder zwei Treffer haben. Tragfähig sind nur die Achsen, für die zwei Bedingungen gleichzeitig gelten: Es gibt Suchnachfrage, und es gibt genug gepflegte Datensätze für eine vollständige Antwort. Zu jeder Achse legen wir vorher eine Untergrenze fest — Mindestzahl an Treffern, Mindestabdeckung der Pflichtfelder. Wer Ihnen ohne Blick in die Daten eine Seitenzahl nennt, hat multipliziert, nicht geprüft.
Das lässt sich nicht zusagen, und wer es zusagt, weiß es auch nicht. Indexierung passiert nicht auf Zuruf: Google entscheidet je URL, ob der Aufwand sich lohnt, und bei neuen Seitenstrecken heißt das häufig zunächst „gecrawlt, zurzeit nicht indexiert“. Deshalb rollen wir in Wellen aus statt alles auf einmal — die erste Welle zeigt, wie die Vorlage aufgenommen wird, und lässt sich nachschärfen, bevor der Rest folgt. Beobachtet wird über die Google Search Console, Seitentyp für Seitentyp.
Der Aufwand hängt an vier Größen: Zustand und Vollständigkeit der Daten, Zahl der Seitentypen, Aufwand für die Anbindung der Quelle und Sprachumfang. Eine Strecke über einen gepflegten Fahrzeugbestand mit einem Seitentyp ist ein anderer Posten als ein Ersatzteilkatalog in fünf Sprachen mit ERP-Anbindung. Eine belastbare Zahl steht nach dem Datenaudit, nicht im ersten Telefonat — das Audit beauftragen Sie deshalb als eigenen, abgegrenzten Schritt und entscheiden danach über den Rest. Pauschalpakete nach Seitenzahl verkaufen wir nicht, weil die Seitenzahl das falsche Maß ist.
In drei Fällen, und wir sagen es vor der Beauftragung. Bei zu dünnen Daten: Liegen je Datensatz ein Bild und zwei Attribute vor, entsteht keine Seite, die eine Frage beantwortet — die Anreicherung kaschiert das nur. Bei einem Sortiment ohne Suchnachfrage: Sucht niemand nach diesen Kombinationen, ist die Strecke aufwendig und wirkungslos, und eine gute Kategorieseite ist die richtige Antwort. Und bei fehlender Bereitschaft zur Pflege: Ein Bestand, der nicht aktualisiert wird, produziert nach einem halben Jahr Seiten zu Dingen, die es nicht mehr gibt.
Indem jeder Abschnitt allein zitierfähig ist. KI-Assistenten übernehmen selten eine ganze Seite, sondern einen Absatz — also steht die Antwort im ersten Satz, die Begründung danach, und Firmenname, Standort und Fachbegriff stehen im Absatz statt in der Kopfzeile, weil der Kontext beim Zitieren verloren geht. Dazu gehört strukturiertes Markup je Seitentyp, eine llms.txt als kuratierter Einstieg und der geprüfte Zugriff in robots.txt, Firewall und CDN: OAI-SearchBot, PerplexityBot und Bingbot holen die Inhalte für die Antwort, GPTBot und ClaudeBot sammeln vor allem Trainingsdaten, und Google-Extended steuert nur die Nutzung in den Gemini-Anwendungen, nicht die KI-Übersichten der Google-Suche. Garantien auf Nennung gibt die Sharpness Solutions GmbH nicht.
Das ist die Frage, an der Strecken in flüchtigen Beständen scheitern, und sie gehört vor den Bau geklärt. Für Einzelobjekte gilt: verkauft ist nicht gelöscht — je nach Fall Weiterleitung auf die passende Trefferliste, ein sauberes 410 für endgültig entfallene Objekte, oder eine Übersichtsseite, die vergleichbare Angebote zeigt. Seiten über Bestandsschnitte bleiben bestehen, solange ihre Untergrenze erfüllt ist, und verschwinden geordnet, wenn nicht. Was nicht passieren darf: hunderte Sackgassen im Index und Seiten, die Angebote bewerben, die es nicht mehr gibt.
In der Regel nicht. Wir bauen solche Strecken im vorhandenen System — TYPO3, Shopware 6 oder WordPress —, weil die Daten dort ohnehin liegen oder von dort angebunden sind. Bei unseren Fahrzeugprojekten läuft die Suche über eine eigene TYPO3-Extension, die in mehreren Installationen dieselbe ist, vom dreistelligen Nutzfahrzeugbestand bis zu über zweitausend Pkw. Die Frage ist nicht das CMS, sondern ob der Bestand als Datenquelle erreichbar ist und ob sich die Filterzustände in eigene, verlinkbare Adressen überführen lassen. Beides prüfen wir im Audit.
Ja, und die Richtung entscheidet, welche Schnittstelle greift. Den eigenen Bestand auslesen läuft über die Search-API beziehungsweise Ad-Integration: Dafür schalten Sie im Händlerkonto die Listing Integration frei und erzeugen API-Benutzername und -Passwort; für angemeldete Händler ist der Zugriff auf den eigenen Bestand üblicherweise in der Monatsgebühr enthalten. Anzeigen anlegen, ändern und löschen, Bilder hochladen, zuordnen und umsortieren oder kostenpflichtige Zusatzfeatures buchen — das ist die Seller-API, und sie setzt einen API-Account voraus, der über den Kundenservice freigeschaltet wird. Daneben gibt es die Insights-API für Auswertungen, die Lead-API für Anfragen und den Ad-Stream, der Ereignisse serverseitig per WebSocket liefert. Alle sind XML-basiert. Aus der Dokumentation kommen auch die Grenzen: keine parallelen Anfragen zur selben Anzeige, die maximale Bildanzahl je Anzeige hängt am Konto, veröffentlichte Rate-Limits gibt es nicht — die klärt man mit dem Support. Für eine Seitenstrecke ist mobile.de meist nicht die Quelle, sondern ein weiterer Ausgabekanal: Geführt wird der Bestand im eigenen System.
Das entscheiden Sie, und wir halten es schriftlich fest. Vorlagen, Anreicherungsregeln und Abschaltkriterien gehören zur Lieferung, ebenso die Dokumentation — eine Übernahme durch Ihr eigenes Team ist damit jederzeit möglich. Wenn wir die Pflege übernehmen, läuft sie über die Service-Level-Staffel: BASIC 24 Stunden, STANDARD 8 Stunden, ADVANCED 4 Stunden, PREMIUM 2 Stunden Reaktionszeit, als Monatspauschale netto je Projekt. Ohne solche Vereinbarung bearbeiten wir Anfragen in Eingangsreihenfolge innerhalb von 48 Stunden zu den Geschäftszeiten Mo–Fr 9:00–16:00 Uhr.
Anfrage
Beschreiben Sie kurz, was in Ihrer Datenbank steht und wie viele Einträge es sind. Wenn Sie unsicher sind, ob der Bestand dafür ausreicht: Genau das prüfen wir zuerst, und wenn er es nicht tut, sagen wir es vor dem Angebot.