Wir haben eine Jimdo-Seite mit ein paar Claude-Prompts auf Neleto migriert, und die Lighthouse-Scores erzählen die ganze Geschichte
Wir haben eine Live-Jimdo-Seite mit Claude und unserem MCP-Connector auf Neleto neu gebaut. Der erste Durchlauf verschlechterte die Accessibility. Zwei Prompts später standen 99 / 100 / 100 / 100 bei Lighthouse. Hier ist das ehrliche Vorher-Nachher, kaputte Audits inklusive.
Die meisten "Wir haben eine Website migriert"-Artikel lassen den Teil weg, in dem etwas kaputtgeht. Dieser nicht, denn der spannende Teil ist genau der, der kaputtging, und wie ein paar Folge-Prompts ihn wieder repariert haben.
Die Kurzfassung: Wir haben eine Live-Jimdo-Seite genommen und sie mit Claude und unserem MCP-Connector 1:1 auf Neleto neu gebaut. Der erste Durchlauf war schnell und sah gut aus, aber Lighthouse fand eine Accessibility-Regression, mit der wir nicht gerechnet hatten. Zwei Prompts später stand die Seite bei nahezu perfekten 99 / 100 / 100 / 100. Wir haben nichts von Hand codiert und den Page Builder nicht geöffnet. Nur Prompts.
Der Ausgangspunkt: eine solide Jimdo-Seite
Die Seite war ein typischer Jimdo-Build, ein sauberer Onepager, der seinen Job macht. Bevor wir irgendetwas angefasst haben, haben wir Lighthouse auf der Live-Version laufen lassen, damit wir eine echte Baseline haben statt eines Bauchgefühls. Desktop, 10. Juni:
| Metrik | Jimdo (live) |
|---|---|
| Performance | 88 |
| Accessibility | 88 |
| Best Practices | 100 |
| SEO | unvollständig |
| Largest Contentful Paint | 1,9 s |
| First Contentful Paint | 1,3 s |
| Gesamtgröße der Seite | ~1,18 MB |
Nicht schlecht. Eine 88 bei Performance ist ein Wert, über den sich viele Mittelstands-Websites freuen würden. Aber es ist überall Luft nach oben: LCP nahe zwei Sekunden, ein Accessibility-Score, hinter dem sich vier defekte Audits verstecken, und eine SEO-Kategorie, die nicht einmal vollständig zurückkam. Das ist die Realität der meisten gehosteten Baukästen. An der Oberfläche okay, aber du kontrollierst den Stack nicht, also kannst du nicht reparieren, was darunter liegt.
Genau dafür gibt es Neleto, also haben wir die Seite migriert.
Die Migration: ein Prompt, die ganze Seite
Wir haben keinen Builder geöffnet und angefangen, Kästchen zu schieben. Wir haben einen einzigen, vorbereiteten Prompt in Claude eingefügt, denselben wiederverwendbaren, den wir für jeden "Kopiere eine Seite auf Neleto"-Job nutzen. Im Klartext:
Repliziere diese Jimdo-Seite 1:1 auf unserem Neleto-CMS als vollständig komponentenbasierte Seite. Jeder Text, jedes Bild, jeder Link und jede Farbe über das CMS editierbar, nichts fest in Templates verdrahtet. Baue alle Seiten und verifiziere alles selbst, bevor du berichtest.
Ein paar Dinge sorgen dafür, dass dieser Prompt echte Arbeit leistet, statt nur eine grobe Annäherung zu liefern. Er holt sich das echte Design statt eines geratenen: Claude steuert ein Headless-Chrome, macht von jeder Seite einen Screenshot und extrahiert die berechneten Styles (Schriftfamilie, -gewicht, -größe, Zeilenhöhe, Farben, Padding, Border-Radius, Sektionshöhen, Button-Stile) und trifft diese exakten Werte, statt sie über den Daumen zu schätzen. Er baut so, wie Neleto gebaut werden will, mit einem Layout, einer Komponente pro Sektion und einer Page pro Route, damit der Betreiber später jedes Wort, jedes Bild, jede Farbe ändern kann, ohne Code anzufassen. Und er prüft seine eigene Arbeit: Der Prompt weist Claude an, axe-core auf jeder Seite laufen zu lassen und Probleme zu beheben, bevor zurückgemeldet wird, sodass Accessibility eine Bau-Anforderung ist statt eines nachträglichen Gedankens.
Claude spricht über unseren MCP-Connector mit Neleto, einen zustandslosen JSON-RPC-Endpunkt, sodass der gesamte Build (Layout, Komponenten, Seiten, Inhalt) über dieselbe Schnittstelle läuft, die auch ein Entwickler nutzen würde, nur per natürlicher Sprache gesteuert. Die Seite ging auf einer Neleto-Staging-Domain online.
Dann haben wir Lighthouse erneut laufen lassen.
Der ehrliche Teil: Der erste Durchlauf verschlechterte die Accessibility
Hier das Ergebnis der ersten Migration, 11. Juni, 9:00 Uhr:
| Metrik | Jimdo | Neleto (erster Durchlauf) |
|---|---|---|
| Performance | 88 | 97 |
| Accessibility | 88 | 81 |
| Best Practices | 100 | 100 |
| SEO | unvollständig | 100 |
| LCP | 1,9 s | 1,1 s |
| FCP | 1,3 s | 0,7 s |
Performance sprang um neun Punkte. LCP nahezu halbiert. SEO ging von "kam nicht vollständig zurück" auf saubere 100. So weit stark.
Aber die Accessibility fiel, von 88 auf 81. Das ist der Teil, den die meisten Case Studies still aus dem Screenshot schneiden würden. Wir lassen ihn drin, denn es ist der nützlichste Teil der Geschichte.
Lighthouse markierte exakt vier Dinge, und axe-core benannte sie:
html-has-lang: Das<html>-Element hatte kein[lang]-Attribut, also wussten Screenreader nicht, dass die Seite auf Deutsch ist.label: Ein Formularelement hatte kein zugeordnetes Label.heading-order: Überschriften waren nicht in absteigender Reihenfolge (ein Sprung von zum Beispielh2direkt aufh4).color-contrast: Vorder- und Hintergrundfarben erreichten das WCAG-AA-Kontrastverhältnis nicht.
Nichts davon ist exotisch. Das sind vier der häufigsten Accessibility-Fehler im Web, und ein 1:1-Klon reproduziert oder erzeugt sie bereitwillig, denn Pixel zu treffen ist nicht dasselbe wie Semantik zu treffen. Genau deshalb lässt der Build-Prompt axe-core laufen, und genau deshalb prüfen wir mit Lighthouse nach, statt dem ersten grünlichen Dashboard zu vertrauen.
Die Behebung: ein paar Prompts, keine paar Tage
Hier zahlt sich aus, den Stack zu besitzen. Auf Jimdo sind drei dieser vier Probleme schlicht nicht erreichbar. Auf Neleto ist jede Sektion eine Komponente und jeder Wert editierbar, also sind die Fixes kleine, gezielte Prompts. Im Klartext:
- Füge dem Layout das
lang-Attribut hinzu. Eine Änderung im Layout, seitenweit angewendet. - Gib dem Formularfeld ein korrekt zugeordnetes Label. Eine Komponenten-Änderung.
- Korrigiere die Überschriften-Hierarchie, sodass sie absteigend verläuft. Ein paar Heading-Level in den Komponenten angepasst.
- Erhöhe die Textfarbe, bis sie AA-Kontrast erreicht, und frag mich, bevor du eine Markenfarbe änderst.
Diese letzte Klausel ist wichtig. Kontrast-Fixes können eine Marke still ruinieren, also ist der Prompt so gebaut, dass er einen Konflikt meldet, statt die Palette stillschweigend abzudunkeln.
Zwanzig Minuten später, 11. Juni, 9:20 Uhr, lief der finale Lighthouse:
| Metrik | Jimdo | Neleto (erster Durchlauf) | Neleto (optimiert) |
|---|---|---|---|
| Performance | 88 | 97 | 99 |
| Accessibility | 88 | 81 | 100 |
| Best Practices | 100 | 100 | 100 |
| SEO | unvollständig | 100 | 100 |
| LCP | 1,9 s | 1,1 s | 0,9 s |
| FCP | 1,3 s | 0,7 s | 0,5 s |
| Total Blocking Time | 30 ms | 0 ms | 0 ms |
| Cumulative Layout Shift | 0,006 | 0 | 0 |
Drei von vier Kategorien bei perfekten 100, Performance bei 99, und ein Accessibility-Score, der von "still kaputt auf der ursprünglichen Jimdo-Seite" auf echte 100 ging. First Contentful Paint fiel von 1,3 s auf 0,5 s, die Seite rendert jetzt in rund einem Drittel der früheren Zeit.
Die ursprüngliche Jimdo-Seite hatte eine 88 bei Accessibility, aber diese 88 verbarg die gleiche Art von Problemen. Die Migration hat die Accessibility-Schulden nicht aus dem Nichts erzeugt. Sie hat sie sichtbar gemacht, benannt und uns dann erlaubt, sie tatsächlich zu beheben. Das kannst du über einen geschlossenen Baukasten nicht sagen.
Warum das der ganze Pitch ist
Lässt man die Details weg, wurde aus einem gehosteten Baukasten, okay, aber gedeckelt, eine vollständig editierbare, komponentenbasierte Neleto-Seite mit 99 / 100 / 100 / 100, komplett per Prompt gesteuert, mit einem Menschen nur für die Ermessensentscheidungen (etwa "zerstör mir nicht die Markenfarbe für den Kontrast").
Das ist das Argument für Neleto in einem einzigen Beispiel:
- Du besitzt den Stack. Die drei Accessibility-Probleme, die auf Jimdo unerreichbar waren, brauchten auf Neleto je einen Prompt, weil nichts in einem Template fest verdrahtet ist, das du nicht anfassen kannst.
- Die KI macht die Arbeit, du triffst die Entscheidungen. Claude holte das echte Design, baute jede Komponente, ließ axe-core laufen und wendete die Fixes an. Wir gaben die Markenfarben-Entscheidung frei.
- Tempo ohne den üblichen Kompromiss. Die meisten "schnelle Migration"-Geschichten tauschen Qualität gegen Tempo. Hier war die ganze Schleife, migrieren, messen, Regression, beheben, neu messen, ein einziger Nachmittag, und der Endzustand ist auf jeder relevanten Metrik besser als das Original.
Eine kurze Einordnung, damit die Zahlen ehrlich bleiben: Das sind Desktop-Lighthouse-Läufe, und Lighthouse ist ein Labor-Tool, echte Felddaten variieren also je nach Gerät und Netz. Uns ist lieber, dir die tatsächlichen Reports zu zeigen, Regression und alles, als einen einzelnen herausgepickten Screenshot.
Wenn du auf einer Jimdo-, Wix- oder Squarespace-Seite sitzt und dich fragst, wie sie auf einem Stack aussähe, den du wirklich kontrollierst: So sieht es aus. Ein paar Prompts, ein ehrliches Vorher-Nachher, und ein Accessibility-Score, hinter dem du stehen kannst.
Sollen wir die gleiche Migration auf deiner Seite machen? Antworte mit deiner URL und wir zeigen dir das Vorher-Nachher in Lighthouse, vier kaputte Audits inklusive.
Starte kostenlos auf neleto.io, das einzige CMS mit nativem MCP-Server, gehostet in der EU.
Weiterlesen
Derselbe KI-Build ging von 30 Minuten auf 4 — das haben wir an unserem MCP-Server geändert
Bilder hochzuladen war der langsamste und fragilste Teil beim Bauen einer Website mit einem KI-Agenten. Wir haben es auf Protokollebene gelöst. Hier steht, was sich an Neletos MCP-Server geändert hat — mit den Vorher-Nachher-Zahlen.
Komplettes CMS vs. Headless: Warum All-in-One für den Großteil des Webs gewinnt
Headless hat sich seinen Ruf aus echten Gründen verdient. Hier ist der ehrliche Trade-off — und warum ein komplettes CMS für die meisten Websites die bessere Wahl ist.
Die KI, die ihre eigene Arbeit prüft
Die meisten KI-plus-CMS-Setups schreiben Inhalte über eine API und hoffen, dass sie gerendert wurden. Neleto schließt die Schleife auf drei Wegen — typisierter Structured Output, LSP-Template-Checks vor dem Veröffentlichen und der Agent, der deine Live-Seite öffnet, um zu sehen, was er wirklich gebaut hat. Hier steht, wie jede Ebene funktioniert — und wo trotzdem ein Mensch hinschauen muss.