Antworten zu Performance, Barrierefreiheit, KI-Lesbarkeit, CMS-Auswahl, Bildoptimierung und CRM-Anbindung.
Eine moderne Website hat klar definierte Aufgaben gegenüber Menschen, Suchmaschinen, KI-Crawlern und internen Systemen. Sie ist statisch generiert, schnell ausgeliefert, ohne Tracking, mit semantischem HTML und Schnittstellen zu den Systemen, die im Unternehmen schon laufen. Klassische CMS-Sites sind dynamisch, voll mit Plugins und oft schwerer zu pflegen, ohne dass das einen sichtbaren Mehrwert bringt.
Nicht in jedem Fall. Wenn ein bis drei Personen Inhalte pflegen und davon mindestens eine technisch arbeitet, reicht oft Markdown im Git als Inhaltsquelle. Bei zehn Redakteuren parallel oder strukturierten Daten wie Veranstaltungen oder Produkten lohnt sich ein Headless-CMS. Die Frage ist nicht, ob ein CMS schöner ist, sondern ob ihr es täglich nutzt oder nur theoretisch wollt.
Wenn Inhalte sich häufig ändern, viele Personen parallel pflegen, personalisierte Sichten nötig sind oder Inhalte aus mehreren Quellen kombiniert werden. Für eine klassische Marketing-Site mit Hero, Service-Seiten, Team und Blog ist eine Datenbank nicht erforderlich. Statische Sites laden in Millisekunden, brauchen weniger Wartung und haben kleinere Sicherheits-Angriffsflächen.
Beim Build wird aus Markdown, Komponenten und Templates fertiges HTML erzeugt. Beim Aufruf liefert der Server nur diese HTML-Datei aus, ohne Datenbank-Abfrage oder Server-Side-Rendering. Vorteil: extrem schnell, weniger Angriffsfläche, einfach zu hosten. Nachteil: Bei jeder Inhaltsänderung muss neu gebaut werden, was aber heute ein Sekunden-Vorgang ist.
Cookie-Banner sind nur nötig, wenn die Website Cookies oder vergleichbare Tracking-Mechanismen einsetzt, die einer Einwilligung bedürfen. Eine Website ohne Tracking, Analytics oder Drittanbieter-Skripte braucht keinen Banner. Diese Site läuft genau so. Ob das für eure Site funktioniert, hängt davon ab, welche Marketing- und Analyse-Anforderungen ihr habt.
Über strukturierte Daten in JSON-LD nach Schema.org, sauberes semantisches HTML und klare Antworten auf typische Fragen direkt im Inhalt. KI-Crawler fassen Webseiten als Quelle zusammen. Wer Information versteckt zwischen Bildern oder generischem Text liefert, wird in den Antworten nicht zitiert. Wer Strukturen explizit auszeichnet, hat deutlich bessere Chancen.
Bildoptimierung ist eine technische Aufgabe, kein Redaktions-Job. Marketing lädt das Original hoch, der Build erzeugt daraus optimierte WebP-Varianten in passenden Auflösungen. Lazy-Loading, responsive Größen und korrekte Alt-Texte gehören dazu. Performance steigt automatisch, ohne dass jemand bewusst optimieren muss.
Drei Punkte greifen zuerst: jedes Feld bekommt ein echtes Label mit for-Verknüpfung, Fehlerhinweise sind nicht nur Farbe sondern Text mit ARIA, und Captchas haben eine Alternative oder werden durch unsichtbare Anti-Bot-Mechanismen ersetzt. Diese drei Korrekturen sind in jedem Projekt mit überschaubarem Aufwand umsetzbar und beheben die häufigsten Barrieren.
Lighthouse misst Performance, Accessibility, Best Practices und SEO. Hohe Werte sind kein Marketing-Versprechen, sondern Folge von Architekturentscheidungen: kein Tracking, lokale Schriften mit Preload, Bilder im Build optimiert, statisches HTML statt Single-Page-App. Wer das früh berücksichtigt, hat dauerhaft hohe Werte ohne Optimierungs-Plugins.
Nein. Komplett-Relaunches sind eine Gewohnheit, kein Naturgesetz. Auf einem modernen Stack mit Komponenten und sauberer Inhaltsstruktur lassen sich Verbesserungen kontinuierlich einspielen. Pro Quartal sichtbar etwas verbessern ist der ruhigere und meist günstigere Weg als alle drei Jahre einen großen Schnitt.
Anfragen aus dem Kontaktformular fließen direkt in das CRM, statt in ein Postfach. Über die API des CRM-Systems, mit korrekter Kategorisierung und Quellen-Information. Damit verschwindet keine Anfrage im Posteingang, niemand pflegt Daten doppelt, und Marketing kann Quellen messen. Die einmalige Investition ist meistens innerhalb weniger Stunden gemacht und lohnt sich schnell.
Erst Audit: jedes Plugin bewerten, was aktiv genutzt wird, was ersetzbar ist, was deinstalliert werden kann. Bei stark verbauten Sites ist ein Wechsel des Stacks oft günstiger als das Aufräumen. Sicherheits-Pflege, Performance-Probleme und schlechte Wartbarkeit sind die häufigsten Auslöser. Pro Plugin gibt es meist eine ruhigere Alternative.
