Website-Baukasten: Wann er passt und wo seine Grenzen liegen.

Für eine kleine Zahl statischer Seiten, ein übliches Kontaktformular und einen klar begrenzten Zeitraum kann ein Baukasten schnell zu einem brauchbaren Ergebnis führen. Hosting, Sicherheitsupdates des Systems und eine visuelle Bearbeitung sind häufig gebündelt. Wer keine besondere Geschäftslogik benötigt und dauerhaft innerhalb dieses Rahmens bleiben möchte, profitiert von einem einfachen Start.

Das Problem beginnt nicht mit dem Baukasten, sondern mit einer falschen Erwartung. Eine Vorlage entscheidet nicht, welche Inhalte wirtschaftlich wichtig sind. Ein vorhandenes Formular kennt den tatsächlichen Anfrageprozess nicht. Ein SEO-Feld ersetzt keine Seitenarchitektur. Je stärker sich ein Unternehmen unterscheiden, integrieren oder weiterentwickeln muss, desto genauer sollte es die Grenzen des gewählten Systems kennen.

03.1SEO braucht mehr als Titel und Sitemap

Google beschreibt SEO als Arbeit, die Suchmaschinen beim Verstehen und Menschen bei der Entscheidung für einen Besuch hilft. Dafür müssen Suchintention, eigenständige Seiten, sichtbarer Inhalt, interne Links und technische Indexierbarkeit zusammenspielen. Ein Baukasten kann Felder für Titel und Beschreibungen anbieten. Er kann nicht entscheiden, welche Seite welche Frage beantwortet oder ob sechs nahezu gleiche Leistungsseiten einander Konkurrenz machen.

Bei stark JavaScript-basierten Seiten kommen Crawling, Rendering und Indexierung als getrennte Schritte hinzu. Google kann JavaScript verarbeiten, weist aber auf zusätzliche Komplexität hin. Entscheidend ist das tatsächliche Ergebnis, nicht das Werbeversprechen einer Plattform. Mehr Grundlagen stehen im Beitrag zu SEO und GEO.

03.2Barrierefreiheit braucht menschliche Prüfung

WCAG 2.2 ordnet Anforderungen unter anderem nach Wahrnehmbarkeit, Bedienbarkeit, Verständlichkeit und Robustheit. Ein System kann semantische Komponenten und Kontrastprüfungen anbieten. Falsche Überschriften, unverständliche Linktexte oder eine ungeeignete Fokusreihenfolge können trotzdem im konkreten Inhalt entstehen. Das W3C betont, dass automatisierte Werkzeuge nicht alle Barrieren feststellen können.

Prüfen Sie die fertige Website mit ihren Inhalten, Einstellungen und Erweiterungen. Erst an den tatsächlichen Nutzerwegen lässt sich beurteilen, welche Barrieren bestehen und ob das vereinbarte Qualitätsziel erreicht wird.

Die Unterschiede sind plattformspezifisch. Wix erklärt in seiner eigenen Hilfe, dass eine Wix-Website auf der Wix-Infrastruktur betrieben werden muss und nicht extern gehostet werden kann. Squarespace dokumentiert einen WordPress-orientierten XML-Export für ausgewählte Inhalte. Stile, Custom CSS, Shopseiten und mehrere Blocktypen werden dabei nicht vollständig exportiert. Webflow ermöglicht einen Codeexport, schließt dabei laut Hersteller jedoch verschiedene dynamische Funktionen und Inhalte aus.

Diese drei Beispiele beweisen keine allgemeine Regel über jeden Website-Baukasten. Sie zeigen, warum eine konkrete Exportprüfung vor Vertragsabschluss wichtig ist. Zu klären sind Domain, Texte, Originalbilder, Medien, URL-Struktur, Metadaten, Blogbeiträge, Formulardaten, Shopdaten, Weiterleitungen, eigener Code und die Funktionen, die nach dem Export fehlen würden.

Ein späterer Umzug ist fast immer möglich, kann aber faktisch ein Neubau sein. Das ist nicht zwingend ein Ausschlusskriterium. Wer bewusst eine kurzfristige Kampagnenseite erstellt, kann diese Grenze akzeptieren. Wer einen langfristigen Wissensbestand aufbaut, bewertet sie anders.

Ist ein Website-Baukasten schlecht für SEO?

Nicht grundsätzlich. Viele Systeme bieten saubere Grundlagen. Entscheidend sind die konkrete technische Ausgabe, sinnvolle Seitenarchitektur, hilfreiche Inhalte, interne Links und Indexierbarkeit. Grenzen entstehen, wenn notwendige Anpassungen im System nicht möglich sind.

Kann eine Baukasten-Website barrierefrei sein?

Sie kann barrierearm und je nach Umsetzung auch konform gestaltet werden. Eine Vorlage oder Herstellerangabe belegt das Ergebnis aber nicht. Inhalte, Einstellungen und Nutzerwege müssen automatisch und manuell geprüft werden.

Wann sollte man wechseln?

Wenn eine geschäftlich wichtige Anforderung dauerhaft nur mit Umwegen lösbar ist, die Plattformabhängigkeit nicht mehr zum Vorhaben passt oder Pflege und Erweiterung unverhältnismäßig aufwendig werden. Vorher sollte geprüft werden, was exportierbar ist.

Ist eine individuelle Website immer teurer?

Nicht zwingend. Der Startaufwand ist häufig höher. Über die Laufzeit zählen aber auch Tarife, Erweiterungen, Änderungsaufwand, Betreuung und Migration. Ohne konkreten Umfang ist kein fairer Preisvergleich möglich.

Wem gehören die Inhalte im Baukasten?

Das hängt von Anbieter und Vertrag ab. Selbst wenn Texte und Bilder dem Kunden gehören, können Layout und Funktionen technisch an die Plattform gebunden sein. Eigentum und praktische Portabilität müssen getrennt geprüft werden.