# websitedevelopment.biz — Volltext

> Der vollständige Text jedes Leitfadens in dieser Sprache, damit eine Antwortmaschine den Katalog in einer Anfrage lesen kann. Nichts hiervon fehlt auf den sichtbaren Seiten.

## Wann ein Website-Relaunch sinnvoll ist (und wann nicht)
https://websitedevelopment.biz/de/guides/wann-website-relaunch
Aktualisiert am 2026-08-07 · Wartung

Relaunches werden häufig aus dem falschen Grund gestartet — die Website wirkt auf die Menschen, die sie täglich sehen, veraltet — und sie tragen echtes Risiko: Ein vollständiger Neubau setzt angesammelte Suchsignale zurück, verwirft Wissen über Konversion und ersetzt oft ein bekanntes Problem durch ein unbekanntes.

Dieser Leitfaden behandelt, was einen Relaunch wirklich rechtfertigt, was nicht, und den schrittweisen Weg, der auf den meisten Websites bessere Ergebnisse bringt.

### Gründe, die einen Relaunch rechtfertigen
Das sind strukturelle Probleme, die sich nicht durch Ändern von Seiten beheben lassen — und genau das macht sie zu Relaunch-Gründen statt zu Verbesserungsgründen.
- Die Plattform ist am Ende ihres Lebenszyklus oder erhält keine Sicherheitsupdates mehr.
- Die Website ist nicht responsiv und lässt sich ohne Neubau nicht dazu machen.
- Die Struktur passt nicht mehr zum Geschäft — Sie verkaufen etwas, das die Informationsarchitektur nicht ausdrücken kann.
- Bearbeiten ist ohne Entwicklung unmöglich, sodass Inhalte standardmäßig veralten.
- Die Performance ist strukturell schlecht, wegen der Bauweise, nicht wegen einiger großer Bilder.
- Barrierefreiheitsmängel stecken in den Komponenten selbst und lassen sich nicht flicken.
- Eine Fusion oder ein Rebranding ändert den Namen, nicht nur die Farben.
Beachten Sie, was nicht auf dieser Liste steht: „sieht veraltet aus". Das ist meist ein Gestaltungsprojekt, und Gestaltungsprojekte kosten einen Bruchteil und tragen fast keines der Risiken.

### Gründe, die es nicht tun
Für jeden davon gibt es eine billigere, risikoärmere Lösung, die das eigentliche Problem angeht.
| „Sieht veraltet aus" | Visueller Stil | Neu gestalten: Typografie, Farbe, Abstände |
| „Der Traffic sinkt" | Inhaltliches oder technisches Problem | Erst diagnostizieren — ein Relaunch verschlimmert es meist |
| „Die Konversion ist niedrig" | Bestimmte Seiten oder ein Formular | Änderungen an diesen Seiten testen |
| „Ein Wettbewerber hat relauncht" | Nichts Messbares | Kein Grund |
| „Neue Marketingleitung" | Zuständigkeit, nicht die Website | Erst gemeinsam die Daten durchsehen |
| „Sie ist drei Jahre alt" | Alter ist kein Mangel | Beheben, was messbar falsch ist |

### Warum vollständige Relaunches oft Traffic verlieren
Ein vollständiger Relaunch ändert Struktur, Inhalte, URLs und Templates gleichzeitig. Sinkt die Leistung, können Sie nicht sagen, welche Änderung es verursacht hat — und steigt sie, ebenfalls nicht.
- URL-Änderungen verlieren angesammelte Signale, sofern nicht jede Weiterleitung korrekt kartiert ist.
- Inhalte, die „knapper" neu geschrieben werden, entfernen häufig genau den Text, der gerankt hat.
- Neue Templates können interne Links, strukturierte Daten oder Metadaten verlieren, die die alten hatten.
- Designänderungen können die Konversion so senken, dass es erst Wochen später auffällt.
- Alles ändert sich auf einmal, also ist die Zuordnung hinterher Rätselraten.
Ist ein Relaunch wirklich nötig, behalten Sie URL-Struktur und rankende Inhalte, wo Sie können. Ändern Sie Aussehen und Code, nicht die Adressen.

### Die schrittweise Alternative
Für die meisten Websites schlägt eine Reihe gezielter Änderungen einen Neubau — sie ist billiger, sie ist messbar, und jeder Schritt lässt sich zurücknehmen.
- Zuerst messen: Analytics, Core Web Vitals, Search Console und eine Handvoll Nutzersitzungen.
- Performance und Barrierefreiheit auf den bestehenden Templates beheben. Das zahlt sich meist selbst.
- Die Seiten neu schreiben, die Traffic bekommen, aber nicht konvertieren — eine nach der anderen.
- Neu gestalten: Typografie, Farbe, Abstände. Das erledigt „sieht veraltet aus" für einen Bruchteil der Kosten.
- Einzelne Templates nacheinander ersetzen und dabei ihre URLs behalten.
- Das Bearbeiten verbessern, damit Inhalte nicht mehr veralten.
- Nach jedem Schritt neu messen, damit Sie wissen, welche Änderung was bewirkt hat.

Q: Wie oft sollte eine Website relauncht werden?
A: Es gibt kein richtiges Intervall. Eine gut gewartete Website, die schrittweise verbessert wird, kann viele Jahre ohne Neubau laufen. Der Auslöser sollte ein strukturelles Problem sein, das Sie im aktuellen Aufbau nicht beheben können, kein Datum im Kalender. Websites, die per Richtlinie alle drei Jahre relauncht werden, verlieren dabei meist Boden.

Q: Verbessert ein Relaunch mein SEO?
A: Nicht von selbst, und er kann leicht schaden. Was hilft, ist das, was ein Relaunch manchmal mitbringt: schnellere Seiten, bessere Struktur, bessere Inhalte. Diese Verbesserungen lassen sich ohne Relaunch erreichen, mit weniger Risiko. Ist die Suchleistung das Ziel, diagnostizieren Sie die tatsächliche Ursache, bevor Sie sich auf einen Neubau festlegen.

Q: Sollte ich bei einem Relaunch meine URLs behalten?
A: Wo immer Sie können. URLs zu behalten beseitigt das größte Einzelrisiko eines Relaunches. Müssen sie sich ändern — eine wirklich kaputte Struktur oder ein Domainwechsel —, kartieren Sie jede alte URL per 301 auf eine bestimmte neue und behalten Sie diese Weiterleitungen dauerhaft.

Q: Wie lange dauert ein Relaunch?
A: Ähnlich lange wie ein Neubau und oft länger wegen der Migration: zwei bis fünf Monate für eine mittelgroße Website. Er ist selten billiger als neu anzufangen, sobald Inhaltsmigration, URL-Kartierung und das Nachbilden bestehenden Verhaltens mitzählen — was die meisten überrascht, die einen Rabatt dafür erwarten, dass sie bereits eine Website haben.

## Website-Monitoring: Es vor Ihren Kunden wissen
https://websitedevelopment.biz/de/guides/website-monitoring
Aktualisiert am 2026-08-07 · Wartung

Verfügbarkeits-Monitoring beantwortet eine Frage: Antwortet die Startseite? Die meisten echten Ausfälle sind leiser. Die Website läuft, und das Kontaktformular schlägt seit drei Wochen fehl, oder die Kasse funktioniert für alle außer für Kundinnen mit einer bestimmten Zahlungsmethode.

Dieser Leitfaden behandelt, was zu überwachen ist, wie man Schwellen setzt, die etwas bedeuten, und wie man Alarme glaubwürdig hält.

### Jenseits von „läuft sie"
Die Ausfälle, die Geld kosten, sind meist partiell. Überwachen Sie die Ergebnisse, auf die es Ihnen ankommt, nicht nur den antwortenden Server.
| HTTP-Verfügbarkeit | Server aus, DNS-Fehler | Alle 1–5 Minuten |
| Transaktionsprüfung | Kaputtes Formular, kaputte Kasse | Alle 15–60 Minuten |
| Fehlerrate | Ausnahmen, die nach einem Deployment steigen | Fortlaufend |
| Zertifikatsablauf | Der klassische Sonntagmorgen-Ausfall | Täglich, Alarm 30 Tage vorher |
| Domainablauf | Der schlimmstmögliche Ausfall | Täglich, Alarm 60 Tage vorher |
| Core Web Vitals | Langsame Verschlechterung, die niemand bemerkt | Wöchentlich |
| Search-Console-Abdeckung | Seiten, die aus dem Index fallen | Wöchentlich |
| Platten- und Datenbankgröße | Stilles Wachstum in eine harte Grenze | Täglich |
| Backup-Erfolg | Backups, die vor Monaten aufgehört haben zu laufen | Täglich |
Eine synthetische Transaktion, die ein echtes Formular an eine Testadresse sendet, ist für die meisten Unternehmensseiten die wertvollste einzelne Überwachung. Kaputte Formulare sind unsichtbar und teuer.

### Schwellen setzen, die etwas bedeuten
Eine Überwachung, die bei jedem Aussetzer alarmiert, erzieht Menschen dazu, sie zu ignorieren — und dann wirkt sie nicht, wenn es darauf ankommt. Schwellen sollten widerspiegeln, was Sie tatsächlich handeln lassen würde.
- Verlangen Sie zwei oder drei aufeinanderfolgende Fehlschläge von mehr als einem Standort, bevor alarmiert wird.
- Alarmieren Sie auf die Fehlerrate statt auf einzelne Fehler — ein einzelner 500er ist Rauschen, eine Ratenänderung ist ein Signal.
- Setzen Sie Performance-Alarme auf einen Trend über Tage, nicht auf eine einzelne langsame Messung.
- Trennen Sie Schweregrade: Website aus geht aufs Telefon; eine langsame Seite in die Wochenzusammenfassung.
- Leiten Sie Alarme an eine Person, nicht an ein gemeinsames Postfach, das niemand verantwortet.
- Sehen Sie jeden ausgelösten Alarm durch: Erforderte er keine Handlung, ändern Sie die Schwelle oder löschen Sie die Überwachung.

### Was zu tun ist, wenn ein Alarm auslöst
Eine schriftliche Reihenfolge macht aus einem Vorfall statt einer Improvisation ein Verfahren — was am meisten zählt, wenn die Person in Rufbereitschaft nicht die ist, die die Website gebaut hat.
- Bestätigen Sie, dass es echt ist: Laden Sie die Website selbst aus einem anderen Netz.
- Prüfen Sie zuerst das Offensichtliche — wurde etwas ausgerollt, ist ein Zertifikat abgelaufen, meldet der Hoster einen Vorfall?
- Veröffentlichen Sie ein Status-Update, wenn Kundinnen betroffen sind. Schweigen ist schlimmer als schlechte Nachrichten.
- Stellen Sie den Dienst wieder her, bevor Sie diagnostizieren. Rollen Sie das Deployment zurück und untersuchen Sie in Ruhe.
- Halten Sie fest, was passiert ist, warum, und was es früher gefunden hätte.
- Ergänzen Sie die Überwachung, die es gefunden hätte. So wächst die obige Liste richtig.
Das nützlichste Ergebnis eines Vorfalls ist eine neue Überwachung und ein Weg weniger, auf dem er still passieren kann.

### Sinnvolle Voreinstellungen für eine kleine Website
Sie brauchen keine Observability-Plattform. Für die meisten Unternehmenswebsites reicht dieser Satz und er ist an einem Nachmittag eingerichtet.
- Verfügbarkeitsprüfung auf der Startseite und einer tiefen Seite, alle fünf Minuten, von zwei Standorten.
- Ein synthetisches Formularabsenden täglich, an eine Adresse, die ein Mensch liest.
- Alarme für Zertifikats- und Domainablauf, weit im Voraus.
- Alarmierung bei Serverfehlern aus der Anwendung, mit einer Ratenschwelle.
- Eine Wochenmail mit Core Web Vitals und Search-Console-Abdeckung.
- Eine tägliche Bestätigung, dass das Backup gelaufen ist und seine Größe normal aussieht.

Q: Wie oft sollte ich die Verfügbarkeit prüfen?
A: Alle ein bis fünf Minuten ist üblich, von mindestens zwei geografischen Standorten, damit ein Netzproblem an einem Messpunkt Sie nicht um 3 Uhr nachts weckt. Häufigere Prüfungen ändern selten das Ergebnis, denn die Zeit bis zum Bemerken ist klein im Vergleich zur Zeit bis zur Behebung.

Q: Welche Verfügbarkeit sollte ich erwarten?
A: Ordentliches Shared Hosting liefert etwa 99,9 %, also rund neun Stunden Ausfall im Jahr. Managed Plattformen und gute Cloud-Setups erreichen 99,95 % oder besser. Wichtiger als die Zahl ist, ob der Ausfall verstreute Minuten sind oder ein einzelner langer Ausfall während der Geschäftszeiten.

Q: Reichen kostenlose Monitoring-Werkzeuge?
A: Für die Verfügbarkeit einer kleinen Website in der Regel ja — die kostenlosen Stufen decken eine Handvoll Prüfungen im Fünf-Minuten-Takt ab. Was kostenlosen Stufen meist fehlt, sind synthetische Transaktionen und mehrstufige Prüfungen, und genau dort liegt die wertvolle Überwachung. Planen Sie dafür gezielt einen kleinen Betrag ein.

Q: Wie vermeide ich Alarmmüdigkeit?
A: Löschen Sie Überwachungen, die nie eine Handlung erforderten, verlangen Sie mehrere aufeinanderfolgende Fehlschläge vor dem Alarm, und trennen Sie dringende von informativen Kanälen. Sehen Sie ausgelöste Alarme dann monatlich durch. Ein Alarmkanal, den Menschen stummschalten, ist schlimmer als gar keine Alarmierung, weil er den Glauben erzeugt, jemand passe auf.

## Backup-Strategie für Websites: Was sichern und wie oft
https://websitedevelopment.biz/de/guides/website-backup-strategie
Aktualisiert am 2026-08-07 · Wartung

Die meisten Websites haben Backups. Weniger haben Backups, die schon einmal wiederhergestellt wurden. Die Lücke dazwischen entdeckt man im denkbar schlechtesten Moment, meist zusammen mit der Erkenntnis, dass im Backup die Datenbank fehlte, oder die Uploads, oder die letzten drei Wochen.

Dieser Leitfaden behandelt, was zu sichern ist, wie oft, wo es aufbewahrt wird, und wie Sie überprüfen, dass eine Wiederherstellung tatsächlich funktioniert.

### Was ein vollständiges Backup enthält
Eine Website ist nicht eine Sache. Fehlt eines davon, ist die Wiederherstellung unvollständig, und eine unvollständige Wiederherstellung ist oft schlimmer als keine, weil sie aussieht, als hätte sie geklappt.
- Datenbank — Inhalte, Nutzer, Bestellungen, Einstellungen. Der Teil, der sich ständig ändert.
- Hochgeladene Dateien — Bilder, Dokumente, alles, was Nutzer oder Redaktion ergänzt haben.
- Anwendungscode — idealerweise in der Versionskontrolle, was eine Form von Backup mit Historie ist.
- Konfiguration — Umgebungsvariablen, Serverkonfiguration, Cronjobs, Weiterleitungsregeln.
- Zertifikate und DNS-Einträge — billig zu exportieren, unter Druck schmerzhaft zu rekonstruieren.
- Einstellungen bei Dritten — Webhook-URLs für Zahlungen, E-Mail-Konfiguration, API-Schlüssel.
Die Konfiguration wird am häufigsten vergessen. Eine wiederhergestellte Datenbank samt Dateien auf einem anders konfigurierten Server ist nicht dieselbe Website.

### Wie oft und wie lange aufbewahren
Die Häufigkeit folgt aus einer Frage: Wie viel Arbeit können Sie sich leisten zu verlieren? Die Aufbewahrung folgt aus einer anderen: Wie lange dauert es, bis Sie ein Problem bemerken würden?
| Statische Broschürenseite | Wöchentlich | Wöchentlich | 30 Tage |
| Unternehmensseite mit Blog | Täglich | Täglich | 30–60 Tage |
| Stark frequentierte Inhaltsseite | Täglich oder stündlich | Täglich | 60–90 Tage |
| Onlineshop | Stündlich oder fortlaufend | Täglich | 90+ Tage, plus Monatsarchive |
| Webanwendung | Fortlaufend mit Point-in-Time-Recovery | Täglich | Nach Ihrer Datenrichtlinie |
Die Aufbewahrung zählt, weil es langsam wirkende Probleme gibt. Ein fehlerhafter Import oder eine leise Kompromittierung fällt vielleicht wochenlang nicht auf, und dann enthält eine 7-Tage-Rotation nur noch schlechte Kopien.

### Wo sie liegen sollten
Die klassische Regel gilt weiterhin: drei Kopien, auf zwei Arten von Medien, eine davon außer Haus. Auf Websites übertragen heißt das: Das Backup muss sowohl den Ausfall des Servers als auch dessen Kompromittierung überleben.
- Speichern Sie die einzige Kopie nie auf demselben Server wie die Website.
- Nutzen Sie für mindestens eine Kopie einen anderen Anbieter, damit ein Ausfall auf Anbieterebene nicht beide erwischt.
- Machen Sie mindestens eine Kopie unveränderlich oder einmal beschreibbar, damit die Zugangsdaten der Website sie nicht löschen können.
- Verschlüsseln Sie Backups im Ruhezustand — sie enthalten alles, auch personenbezogene Daten.
- Halten Sie ein Monatsarchiv außerhalb der Rotation für spät entdeckte Probleme.
- Dokumentieren Sie, wo sie liegen und wie man wiederherstellt, an einem Ort, der nicht nur auf der Website ist.

### Testen: der Schritt, der es echt macht
Ein Backup, das Sie nie wiederhergestellt haben, ist eine Annahme. Ein Test dauert eine Stunde und macht daraus eine Tatsache.
- Stellen Sie in eine getrennte Staging-Umgebung wieder her, nicht über die Live-Website.
- Prüfen Sie, ob die Datenbank vollständig wiederhergestellt wurde — zählen Sie Zeilen in den Tabellen, auf die es ankommt.
- Prüfen Sie, ob hochgeladene Dateien vorhanden sind, auch die jüngsten.
- Melden Sie sich an und erledigen Sie eine echte Aufgabe: eine Seite veröffentlichen, eine Testbestellung aufgeben.
- Stoppen Sie die Zeit. „Wie lange würde eine Wiederherstellung dauern?" ist eine Frage, die Sie vorher beantwortet haben wollen.
- Schreiben Sie das Vorgehen auf, damit es nicht nur bei der Person liegt, die es eingerichtet hat.
- Wiederholen Sie es monatlich und nach jeder Änderung am Hosting.
Stoppen Sie die Wiederherstellungszeit. Zu wissen, dass sie vier Stunden dauert, ändert, was Sie während eines Ausfalls zusagen — und es ist die Zahl, die niemand hat, wenn er sie braucht.

Q: Reicht das Backup meines Hosters?
A: Es ist eine gute Grundlage und eine schlechte alleinige Strategie. Hoster-Backups haben typischerweise kurze Aufbewahrung, liegen auf derselben Infrastruktur und gehen mit dem Konto verloren, wenn es einen Zahlungsstreit oder einen Anbieterausfall gibt. Halten Sie Ihre eigene Kopie woanders — die Kosten sind gering, und es ist die Kopie, die Sie genau in dem Szenario brauchen, in dem Hoster-Backups nicht helfen.

Q: Wie lange soll ich Backups aufbewahren?
A: Lang genug, um ein spät entdecktes Problem abzudecken. Dreißig Tage sind ein vernünftiges Minimum, neunzig sind für einen Shop sicherer, und ein Monatsarchiv, das ein Jahr bleibt, kostet fast nichts. Wägen Sie das gegen Datenschutzpflichten ab — Backups mit personenbezogenen Daten unterliegen ebenfalls Aufbewahrungsregeln.

Q: Brauche ich Backups, wenn mein Code in der Versionskontrolle liegt?
A: Ja. Versionskontrolle deckt Code und seine Historie ab und enthält weder die Datenbank noch die hochgeladenen Dateien noch die Serverkonfiguration. Dort leben Inhalte und Kundendaten, und das ist der Teil, den kein erneutes Deployment wiederherstellen kann.

Q: Was ist Point-in-Time-Recovery?
A: Die Fähigkeit, die Datenbank auf einen beliebigen Zeitpunkt zurückzusetzen statt auf den letzten geplanten Stand — erreicht durch fortlaufende Archivierung des Transaktionsprotokolls. Sie zählt, wenn schon eine Stunde verlorener Bestellungen inakzeptabel ist. Für eine Broschürenseite ist sie unnötig; für einen Shop, der nachts Bestellungen annimmt, ist sie den Mehraufwand wert.

## Website-Sicherheit: Die Praktiken, die die meisten Vorfälle verhindern
https://websitedevelopment.biz/de/guides/website-sicherheit-best-practices
Aktualisiert am 2026-08-07 · Wartung

Die meisten Website-Kompromittierungen sind nicht gezielt. Es sind automatische Scanner, die eine bekannte Schwachstelle in veralteter Software finden, oder ein wiederverwendetes Passwort auf einem Admin-Konto. Sich gegen die gewöhnlichen Angriffe zu verteidigen deckt den weit größten Teil des echten Risikos ab.

Dieser Leitfaden behandelt die Praktiken, die die meisten Vorfälle verhindern, grob nach Wirkung geordnet, und was zu tun ist, wenn eine Website bereits kompromittiert wurde.

### Die Maßnahmen, die die meisten Vorfälle verhindern
Geordnet danach, wie viel Risiko sie je Aufwandseinheit beseitigen.
- Halten Sie Software aktuell. Die überwältigende Mehrheit der Kompromittierungen nutzt eine Schwachstelle aus, für die ein Patch verfügbar ist. Dieser eine Punkt wiegt schwerer als alles darunter.
- Einzigartige starke Passwörter plus Zwei-Faktor-Authentifizierung auf jedem Admin-Konto, Hosting-Panel, Domain-Registrar und E-Mail-Konto.
- Geringste Rechte. Redakteurinnen brauchen keine Administratorkonten. Entfernen Sie Konten, wenn Menschen gehen.
- HTTPS überall, mit HSTS, sobald Sie sicher sind, dass jede Unterressource über TLS verfügbar ist.
- Getestete Backups, außerhalb des Servers gespeichert. Ein Backup auf der kompromittierten Maschine wird mit allem anderen verschlüsselt.
- Schränken Sie den Adminbereich nach IP ein, wo es praktikabel ist, und begrenzen Sie Anmeldeversuche immer.
- Entfernen Sie, was Sie nicht nutzen. Jedes inaktive Plugin, Theme und jede alte Installation ist Angriffsfläche ohne Nutzen.
Alte, vergessene Installationen — eine Staging-Kopie unter /alt, ein Testblog in einem Unterordner — sind ein häufiger Einstiegspunkt, gerade weil sie niemand aktualisiert.

### Eingabe, Ausgabe und die klassischen Schwachstellen
Das sind Verantwortlichkeiten der Entwicklung und sie machen den Großteil der Schwachstellen aus, die nicht „Sie haben nicht aktualisiert" lauten.
| SQL-Injection | Liest oder zerstört Ihre Datenbank | Immer parametrisierte Abfragen — nie String-Verkettung |
| Cross-Site-Scripting | Führt fremdes Skript in der Sitzung eines Besuchers aus | Kontextabhängig bei der Ausgabe escapen; eine strikte Content-Security-Policy |
| Cross-Site Request Forgery | Führt Aktionen als angemeldeter Nutzer aus | Sitzungsbezogene Tokens bei jeder zustandsändernden Anfrage |
| Missbrauch von Datei-Uploads | Lädt Code hoch und führt ihn aus | Typ am Inhalt prüfen, außerhalb des Web-Roots speichern, nie ausführen |
| Fehlerhafte Zugriffskontrolle | Nutzer erreichen Daten, die nicht ihre sind | Autorisierung serverseitig bei jeder Anfrage prüfen, nicht in der Oberfläche |
| Offenlegung sensibler Daten | Leakt Schlüssel und Zugangsdaten | Umgebungsvariablen, nie im Repository |
| Server-Side Request Forgery | Bringt Ihren Server dazu, interne Systeme aufzurufen | Ausgehende Ziele auf eine Erlaubnisliste setzen |

### Konfiguration und Header
Billige Maßnahmen, die ganze Problemkategorien schließen und meist Minuten brauchen.
- Liefern Sie Sicherheits-Header: Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, X-Frame-Options.
- Deaktivieren Sie Verzeichnislisten; stellen Sie sicher, dass /.git, /.env und Backup-Dateien über HTTP nicht erreichbar sind.
- Schalten Sie ausführliche Fehlerausgaben in der Produktion ab — Stacktraces sind Aufklärung für Angreifer.
- Sperren Sie den Zugriff auf Admin- und Konfigurationspfade aus dem öffentlichen Internet, wo Sie können.
- Setzen Sie Cookies mit HttpOnly, Secure und einem passenden SameSite-Wert.
- Halten Sie Abhängigkeiten auditiert; eine verwundbare Bibliothek in Ihrem Build ist Ihre Verwundbarkeit.
- Protokollieren Sie Authentifizierungsereignisse und alarmieren Sie bei ungewöhnlichen Mustern.

### Wenn die Website bereits kompromittiert ist
Hier zählt die Reihenfolge. Dateien zu säubern, bevor Zugangsdaten gewechselt sind, bedeutet, dass der Angreifer schlicht durch dieselbe Tür zurückkommt.
- Nehmen Sie die Website offline oder in den Wartungsmodus. Lassen Sie sie Besuchern keine Schadsoftware ausliefern.
- Sichern Sie Beweise: Kopieren Sie die Protokolle und einen Stand der Dateien, bevor Sie etwas ändern.
- Wechseln Sie jede Zugangsberechtigung — Hosting, Datenbank, Admin-Nutzer, API-Schlüssel, E-Mail. Nehmen Sie an, alle sind bekannt.
- Stellen Sie aus einem Backup von vor der Kompromittierung wieder her, wenn Sie eines verlässlich bestimmen können.
- Wenn nicht, bauen Sie aus dem Quellcode neu auf und importieren Sie nur Daten, nie Dateien unbekannter Herkunft.
- Beheben Sie die Schwachstelle, durch die sie hereinkamen. Ohne diesen Schritt wiederholen Sie den ganzen Vorgang.
- Suchen Sie nach Persistenz: geplante Aufgaben, zusätzliche Admin-Nutzer, veränderte Kerndateien, eingeschleuste Inhalte.
- Beantragen Sie eine Überprüfung in der Search Console, falls die Website markiert wurde, und suchen Sie nach eingeschleusten Spam-Seiten.
- Benachrichtigen Sie betroffene Nutzer, wenn personenbezogene Daten offengelegt wurden — in vielen Rechtsordnungen innerhalb einer gesetzlichen Frist.
Ein Backup wiederherzustellen, ohne den Einstiegspunkt zu schließen, ist der häufigste Grund, warum Websites binnen zweier Wochen zweimal kompromittiert werden.

Q: Reicht ein Sicherheits-Plugin?
A: Es hilft bei einigen Dingen — Begrenzung von Anmeldeversuchen, Überwachung von Dateiänderungen, eine einfache Firewall — und es ersetzt weder Updates noch starke Zugangsdaten noch geringste Rechte. Eine Website mit Sicherheits-Plugin und achtzehn Monaten versäumter Updates ist nicht sicher. Bringen Sie zuerst die Grundlagen in Ordnung, dann ergänzen Sie Werkzeuge.

Q: Werden kleine Websites wirklich angegriffen?
A: Ständig, und nicht wegen dem, wer Sie sind. Automatische Scanner testen jeden erreichbaren Host auf bekannte Schwachstellen; kleine Websites sind gerade deshalb attraktiv, weil sie seltener gepatcht sind. Kompromittierte kleine Websites werden für Spam, Phishing-Seiten und Weiterleitungen genutzt, weshalb das Traffic-Niveau Ihrer Website für das Risiko unerheblich ist.

Q: Wo sollten Backups liegen?
A: Irgendwo, wohin der Webserver nicht schreiben kann, idealerweise bei einem anderen Anbieter, mit mindestens einer Kopie, die sich nicht mit denselben Zugangsdaten löschen lässt, die die Website betreiben. Ransomware und zerstörerische Angriffe zielen gezielt auf Backups, die von der kompromittierten Maschine erreichbar sind — und das ist genau der Moment, in dem Sie sie brauchen.

Q: Was ist die wertvollste einzelne Sicherheitsmaßnahme?
A: Updates zügig einzuspielen. Es ist unglamourös und verhindert mehr echte Kompromittierungen als alles andere zusammen, denn die Angriffe, die tatsächlich stattfinden, sind automatisiertes Ausnutzen bekannter, gepatchter Schwachstellen. An zweiter Stelle steht Zwei-Faktor-Authentifizierung auf Admin- und Hosting-Konten.

## Website-Wartung: Was sie tatsächlich umfasst
https://websitedevelopment.biz/de/guides/website-wartung-leitfaden
Aktualisiert am 2026-08-07 · Wartung

Website-Wartung ist die Arbeit, die eine Website nach dem Start sicher, aktuell und funktionsfähig hält. Sie ist unsichtbar, wenn sie getan wird, und äußerst sichtbar, wenn nicht — meist als Ausfall, als Kompromittierung oder als Formular, das seit einem Monat still fehlschlägt.

Dieser Leitfaden behandelt, was Wartung tatsächlich einschließt, was sie kostet, was ein Vertrag festhalten sollte und wie Sie überprüfen, dass Sie sie erhalten.

### Worin die Arbeit besteht
Wartung teilt sich in planmäßige Routinearbeit und reaktive Arbeit, wenn etwas passiert. Ein Vertrag, der nur das Zweite abdeckt, ist keine Wartung, sondern Support.
| Sicherheitspatches | Sobald verfügbar, binnen Tagen | Bekannte Schwachstellen werden automatisiert ausgenutzt |
| Plattform- und Plugin-Updates | Monatlich, auf Staging getestet | Zurückzufallen macht das Aktualisieren jeden Monat schwerer |
| Backup-Überprüfung | Monatlicher Wiederherstellungstest | Ein ungetestetes Backup ist kein Backup |
| Verfügbarkeits-Monitoring | Fortlaufend | Sie sollten von einem Ausfall nicht durch eine Kundin erfahren |
| Durchsicht der Fehlerprotokolle | Wöchentlich | Stille Ausfälle — kaputte Formulare, fehlgeschlagene Zahlungen |
| Performance-Prüfung | Monatlich | Das Seitengewicht steigt leise, während Inhalte dazukommen |
| Prüfung auf tote Links | Vierteljährlich | Externe Links verrotten mit stetiger Rate |
| Inhaltsdurchsicht | Vierteljährlich | Veraltete Preise und tote Telefonnummern kosten mehr als Fehler |
| Abhängigkeits-Audit | Vierteljährlich | Aufgegebene Bibliotheken müssen ersetzt werden, bevor sie brechen |

### Was sie kostet
Eine brauchbare Planungsgröße sind 10–20 % der Umsetzungskosten pro Jahr für eine CMS-basierte Website, mehr für einen Shop oder eine Anwendung. Darunter kaufen Sie meist Verfügbarkeit statt tatsächlicher Arbeit.
| Kleine Broschürenseite | 50 – 200 $ | Updates, Backups, Verfügbarkeits-Monitoring, kleine Änderungen |
| Mittelgroße Unternehmensseite | 200 – 800 $ | Obiges plus Staging-Tests, Performance- und Fehlerdurchsicht |
| Onlineshop | 500 – 3.000 $ | Obiges plus Zahlungs- und Bestandsüberwachung, schnellere Reaktion |
| Webanwendung | Ab 1.500 $ | Obiges plus Release-Management und Rufbereitschaft |
Ein günstiger Vertrag ohne Bericht ist schwer von gar keinem Vertrag zu unterscheiden. Der Bericht ist das, was Sie tatsächlich kaufen.

### Was ein Wartungsvertrag festhalten sollte
Vage Verträge verursachen Streit genau im falschen Moment. Diese Punkte gehören vor der Unterschrift schriftlich fest.
- Genau welche Routineaufgaben erledigt werden und wie oft.
- Zielzeiten für die Reaktion, nach Schweregrad getrennt: Website aus, Funktion kaputt, kosmetisch.
- Abdeckungszeiten und was außerhalb davon passiert.
- Wie viele Stunden für Änderungen enthalten sind und ob ungenutzte Stunden übertragen werden.
- Was als Änderung und was als neues Projekt zählt, mit Beispielen.
- Wer worauf Zugriff hat und wie dieser bei Vertragsende entzogen wird.
- Was Sie monatlich erhalten: einen echten Bericht, keine Rechnung.
- Kündigungsfrist und was am Ende mit Ihren Daten und Zugängen geschieht.

### Es selbst machen
Für eine kleine Website ist das völlig vernünftig, sofern es geplant statt beabsichtigt ist. Tragen Sie es mit einer benannten verantwortlichen Person in einen Kalender ein, denn Wartung, die „gemacht wird, wenn wir daran denken", wird nicht gemacht.
- Wöchentlich: prüfen, ob die Website lädt, das Kontaktformular absenden, kurz in die Fehlerprotokolle sehen.
- Monatlich: Updates zuerst auf Staging einspielen, dann in der Produktion. Prüfen, ob ein Backup sich wiederherstellen lässt.
- Monatlich: in der Search Console auf neue Abdeckungsfehler und manuelle Maßnahmen sehen.
- Vierteljährlich: Linkprüfer, Performance-Test und Barrierefreiheits-Scan laufen lassen.
- Vierteljährlich: Inhalte auf Preise, Daten, Personennamen und tote Links durchsehen.
- Jährlich: Domain- und Zertifikatsverlängerungen prüfen und auditieren, wer noch Zugriff hat.
Setzen Sie Kalendererinnerungen auf eine benannte Person, nicht auf ein Team. Geteilte Verantwortung für eine wiederkehrende Pflicht wird verlässlich zu niemandes Verantwortung.

Q: Was passiert, wenn ich die Wartung auslasse?
A: Eine Zeit lang nichts Sichtbares — deshalb wird sie ausgelassen. Dann geschieht eines von drei Dingen: Eine bekannte Schwachstelle wird von einem automatischen Scanner ausgenutzt, ein Update wird unmöglich, weil Sie mehrere Hauptversionen zurückliegen, oder etwas ist seit Wochen kaputt und niemand hat es bemerkt. Alle drei kosten mehr, als die Wartung gekostet hätte.

Q: Kann ich das Wartungspaket meines Hosters nutzen?
A: Managed Hosting deckt meist den Server ab, oft auch Kern-Updates der Plattform und Backups. Es deckt selten Ihre Plugins, Ihren eigenen Code, Ihre Fehlerprotokolle oder Ihre Inhalte ab. Lesen Sie, was enthalten ist; die Lücke zwischen „Managed Hosting" und „Website-Wartung" ist genau dort, wo die meisten Vorfälle passieren.

Q: Woran erkenne ich, dass die Wartung stattfindet?
A: Fordern Sie einen monatlichen Bericht: was aktualisiert wurde, was gepatcht wurde, die Verfügbarkeit, gefundene und behobene Fehler und das Datum der letzten erfolgreichen Backup-Wiederherstellung. Erzeugt ein Vertrag keinen Bericht, können Sie gute Wartung nicht von keiner unterscheiden — und Sie erfahren es meist während eines Vorfalls.

Q: Sollten Updates automatisch eingespielt werden?
A: Sicherheitspatches für die Kernplattform in der Regel ja — das Risiko der Verzögerung übersteigt meist das Risiko eines Defekts. Plugin- und Hauptversions-Updates sollten zuerst auf Staging getestet werden, denn diese brechen Layouts und eigenen Code. Die richtige Aufteilung hängt davon ab, was die Website pro Stunde Ausfall wert ist.

## E-Commerce-SEO: Die Praktiken, auf die es wirklich ankommt
https://websitedevelopment.biz/de/guides/ecommerce-seo-best-practices
Aktualisiert am 2026-08-07 · E-Commerce

Shop-SEO unterscheidet sich von Inhalts-SEO in einem wichtigen Punkt: Die Website erzeugt URLs von selbst. Filter, Sortierung, Varianten und Blätterung können aus einem Katalog mit 500 Produkten 50.000 indexierbare Seiten machen, und genau dort beginnen die meisten Shop-SEO-Probleme.

Dieser Leitfaden behandelt, wie man einen Shop so strukturiert, dass die richtigen Seiten ranken und die maschinell erzeugten aus dem Index bleiben.

### Kategorien sind Ihre wertvollsten Seiten
Die meiste kommerzielle Suchnachfrage gilt einer Kategorie, nicht einem bestimmten Produkt: Menschen suchen weit häufiger nach „wasserdichte Wanderschuhe" als nach einem bestimmten Modell. Kategorieseiten sind daher die Seiten, in die zu investieren sich lohnt — und meist die dünnsten.
- Geben Sie jeder Kategorie echten Text — eine kurze Einleitung über dem Raster und nützliche Details darunter.
- Richten Sie die Kategorie danach aus, wie Menschen suchen, nicht danach, wie Ihr Lager organisiert ist.
- Verlinken Sie verwandte Kategorien untereinander; ein Produktraster ohne redaktionelle Links ist eine Sackgasse.
- Halten Sie Kategorie-URLs stabil, auch wenn sich das Sortiment ändert. Die URL überlebt die Produkte darin.
- Zeigen Sie oberhalb der Falz genug Produkte, damit die Seite die Anfrage sofort beantwortet.
Eine Kategorieseite ohne Text konkurriert allein über Produkttitel. Deshalb verlieren Kategorieseiten so oft gegen Inhaltsseiten, die dieselben Produkte besprechen.

### Facettennavigation: die Hauptquelle des Ärgers
Filter vervielfachen URLs kombinatorisch. Offen gelassen verbrauchen sie Crawl-Budget, verwässern Signale und füllen den Index mit Beinahe-Duplikaten, die sich nur langsam entfernen lassen.
| Basiskategorie | Indexieren, selbstkanonisch |
| Einzelner Filter mit hoher Nachfrage (z. B. Marke) | Indexieren, wenn es echte Suchnachfrage und genug Produkte gibt |
| Mehrere Filter kombiniert | noindex, follow |
| Sortierreihenfolge | noindex, oder gar keine eigene URL erzeugen |
| Blätterung | Indexieren, jede Seite selbstkanonisch, echte crawlbare Links |
| Leeres Filterergebnis | noindex, und einen 404 erwägen |
| Tracking-Parameter | Entfernen oder auf die saubere URL kanonisieren |

### Produktseiten: URLs, Varianten und Bestand
Drei Entscheidungen verursachen hier die meisten Produktseiten-Probleme, und alle drei sind vor dem Start billiger zu klären.
- Eine URL je Produkt, nicht eine je Kategoriepfad. Ein Produkt in drei Kategorien sollte nicht unter drei URLs existieren.
- Varianten: eine indexierbare Produktseite mit Variantenauswahl, außer eine Variante hat wirklich eigene Nachfrage — Farbe selten, Größe nie.
- Nicht auf Lager: Seite mit markierter Verfügbarkeit und gezeigten Alternativen live lassen. Sie zu löschen verwirft angesammelte Ranking-Signale für ein Produkt, das nächsten Monat zurückkommen kann.
- Dauerhaft eingestellt: 301 auf das nächste Äquivalent oder auf die Kategorie, nicht auf die Startseite.
- Eigene Beschreibungen. Herstellertext steht auf der Website jedes Wettbewerbers; er ist die Definition von Duplicate Content.
- Strukturierte Daten mit Preis und Verfügbarkeit, die exakt zur sichtbaren Seite passen.

### Technische Punkte, die spezifisch für Shops sind
Diese kommen auf fast jedem Shop vor und auf einer Broschürenseite selten.
| Interne Suchergebnisse | noindex — sie sind unendlich und dünn |
| Warenkorb und Kasse | noindex, und vom Crawlen ausschließen |
| Kundenkonten | noindex; Bestellseiten nie indexieren lassen |
| Mehrere Währungen | Eine kanonische URL; keine URL je Währung erzeugen |
| Mehrere Märkte | Präfix-URLs plus reziprokes hreflang |
| Bewertungen | In HTML ausgeben; Review-Markup nur für echte Bewertungen auf der Seite |
| Performance der Listenseiten | Beobachten, während der Katalog wächst — sie verschlechtert sich zuerst |
| Sitemaps | Nach Typ aufteilen und aktuell halten, wenn sich der Bestand ändert |
Produktfeeds für Shopping-Anzeigen ersetzen keine indexierbaren Produktseiten. Es sind getrennte Systeme, und eines rankt das andere nicht.

Q: Sollten nicht verfügbare Produkte entfernt werden?
A: Nicht, wenn der Artikel zurückkommt. Behalten Sie die Seite, markieren Sie die Verfügbarkeit sowohl auf der sichtbaren Seite als auch in den strukturierten Daten korrekt, und bieten Sie Alternativen an. Sie zu löschen wirft Links und Ranking-Historie weg, für die Sie bezahlt haben. Leiten Sie nur per 301 um, wenn das Produkt wirklich eingestellt ist, und dann auf das nächste Äquivalent statt auf die Startseite.

Q: Wie behandle ich Produkte in mehreren Kategorien?
A: Geben Sie jedem Produkt eine einzige kanonische URL, die den Kategoriepfad nicht enthält — /produkte/wanderschuh-x statt /schuhe/wandern/wanderschuh-x. Verlinken Sie sie aus jeder passenden Kategorie. Kategoriebasierte Produkt-URLs erzeugen Duplikate und brechen, sobald Sie den Katalog umorganisieren.

Q: Brauche ich für jedes Produkt eine eigene Beschreibung?
A: Für Produkte, die ranken sollen, ja. Herstellertext erscheint bei jedem Wettbewerber, der denselben Artikel verkauft, es gibt also nichts, was Ihre Seite unterscheidet. Ist eine vollständige Neufassung von 4.000 Produkten unrealistisch, fangen Sie mit den Produkten an, die tatsächlich Umsatz bringen, und lassen Sie den Rest sich auf Kategorieseiten stützen.

Q: Sollten Filterseiten jemals indexiert werden?
A: Eine kleine, bewusst gewählte Anzahl: einzelne Filter, die echter Suchnachfrage entsprechen und eine ordentliche Zahl Produkte liefern, etwa eine Marke innerhalb einer Kategorie. Geben Sie diesen Seiten eigene Titel und Beschreibungen. Alles andere — Kombinationen, Sortierungen, Preisschieber — sollte noindex, follow sein.

## Zahlungsanbindung: Was die Entwicklung richtig machen muss
https://websitedevelopment.biz/de/guides/zahlungsanbindung-leitfaden
Aktualisiert am 2026-08-07 · E-Commerce

Zahlungsanbindung sieht in einem Tutorial einfach aus und ist im Produktivbetrieb unerbittlich, denn jeder Fehlerfall bedeutet entweder eine Kundin, die gezahlt hat und nichts bekam, oder eine Kundin, die etwas bekam und nicht zahlte.

Dieser Leitfaden behandelt, wie der Ablauf funktioniert, die eine Entwurfsentscheidung, die die meisten Probleme verhindert, und die Fälle, die vor dem Start bewusst getestet gehören.

### Wie der Ablauf tatsächlich funktioniert
Egal welcher Anbieter, die Form ist dieselbe: Ihr Server erzeugt eine Zahlungsabsicht, die Kundin authentifiziert sich beim Zahlungsdienst, und der Dienst teilt Ihnen das Ergebnis mit — zweimal, über zwei verschiedene Wege.
- Ihr Server erzeugt eine Zahlungsabsicht mit Betrag, Währung und einem Verweis auf Ihre Bestellung.
- Die Kundin gibt Kartendaten in einem gehosteten Feld oder auf einer gehosteten Seite ein, sodass die Daten Ihren Server nie berühren.
- Es kann eine starke Authentifizierung nötig sein, die einen Schritt hinzufügt, den die Kundin abschließen muss.
- Der Dienst leitet die Kundin mit einem Ergebnis zurück auf Ihre Website.
- Unabhängig davon sendet der Dienst einen Server-zu-Server-Webhook mit dem maßgeblichen Ergebnis.
- Ihr System aktualisiert die Bestellung — aus dem Webhook, nicht aus der Weiterleitung.
- Die Abwicklung wird erst ausgelöst, nachdem die Zahlung bestätigt ist.
Die Schritte 4 und 5 sind der ganze Entwurf. Die Weiterleitung ist ein Hinweis darauf, was geschehen ist; der Webhook ist die Tatsache.

### Warum Webhooks die maßgebliche Quelle sein müssen
Der Browser der Kundin ist ein unzuverlässiger Erzähler. Er kann sich während der Weiterleitung schließen, die Verbindung verlieren oder manipuliert werden. Hängt Ihr Bestellstatus davon ab, dass die Kundin auf Ihrer Erfolgsseite ankommt, werden Sie bezahlte Bestellungen haben, die nie erfasst wurden.
- Aktualisieren Sie den Bestellzustand nur aus verifizierten Webhooks; behandeln Sie die Weiterleitung rein als Nachricht an die Nutzerin.
- Prüfen Sie Webhook-Signaturen. Ein nicht authentifizierter Endpunkt, der Bestellungen als bezahlt markiert, ist genau so schlimm, wie es klingt.
- Machen Sie die Webhook-Verarbeitung idempotent — Anbieter wiederholen, und Duplikate werden ankommen.
- Antworten Sie schnell und verarbeiten Sie asynchron; langsame Endpunkte werden wiederholt und irgendwann abgeschaltet.
- Protokollieren Sie jede Webhook-Nutzlast. Zahlungsstreitigkeiten werden mit Protokollen entschieden.
- Behandeln Sie Ereignisse in falscher Reihenfolge, denn sie können und werden so ankommen.

### Die Fehlerfälle, die zu testen sind
Jeder davon kommt im Produktivbetrieb vor. Testen Sie sie bewusst, mit den Testkarten des Anbieters, vor dem Start.
| Kundin schließt den Tab nach der Zahlung | Der Webhook schließt die Bestellung trotzdem ab; die Bestätigungsmail geht raus |
| Karte abgelehnt | Klare Meldung, Warenkorb erhalten, weiterer Versuch möglich |
| Starke Authentifizierung fehlgeschlagen | Bestellung nicht bestätigt; Kundin erfährt, was als Nächstes zu tun ist |
| Doppelter Webhook | Bestellung einmal aktualisiert, nicht zweimal; kein zweiter Versand |
| Webhook kommt vor der Weiterleitung an | Die Erfolgsseite zeigt die bereits abgeschlossene Bestellung |
| Teilerstattung | Bestellsummen und jeder Buchhaltungsexport bleiben konsistent |
| Bestand zwischen Zahlung und Versand aufgebraucht | Definierter Prozess: Erstattung, Nachlieferung oder Ersatz |
| Währungsrundung | Der belastete Betrag entspricht exakt der angezeigten Summe |

### Geltungsbereich, Compliance und Geld
Einige wenige Entscheidungen bestimmen, wie viel regulatorische Last Sie übernehmen und wie viel der Transaktion Ihnen bleibt.
- Speichern Sie nie Kartennummern. Nutzen Sie gehostete Felder oder eine gehostete Seite, damit Kartendaten Ihren Server nie erreichen; das hält den PCI-Geltungsbereich minimal.
- Verstehen Sie die Gebührenstruktur. Prozentsatz plus Fixgebühr, plus Währungsumrechnung, plus Rückbuchungsgebühren. Der genannte Prozentsatz ist nicht die Kosten.
- Prüfen Sie den Auszahlungsrhythmus. Tage bis zur Gutschrift beeinflussen die Liquidität stärker als ein kleiner Ratenunterschied.
- Bestätigen Sie, dass der Erstattungsweg vor dem Start durchgängig funktioniert, einschließlich Teilerstattungen.
- Unterstützen Sie die lokalen Zahlungsmethoden Ihres Marktes — Karten sind nicht überall der Standard, und die dominierende lokale Methode zu verpassen kostet Konversionen.
- Halten Sie einen zweiten Anbieter bereit, wenn Zahlungen kritisch sind. Ausfälle kommen vor und stoppen den Umsatz vollständig.

Q: Gehostete Kasse oder eingebettetes Formular?
A: Die gehostete Kasse ist einfacher, hält den PCI-Geltungsbereich am kleinsten und wird vom Anbieter gepflegt — für die meisten Shops ist sie der richtige Standard. Eingebettete Felder halten die Kundin auf Ihrer Domain und geben mehr Kontrolle über das Erlebnis, um den Preis von mehr Code und mehr Verantwortung. Beide halten Kartendaten von Ihrem Server fern, und das ist der Teil, auf den es ankommt.

Q: Was passiert, wenn mein Webhook-Endpunkt ausfällt?
A: Anbieter wiederholen mit Backoff, typischerweise über Stunden oder Tage, sodass ein kurzer Ausfall sich von selbst erholt. Ein langer Ausfall bedeutet unbestätigte Bestellungen, überwachen Sie den Endpunkt also und lassen Sie sich bei Fehlern alarmieren. Bauen Sie außerdem einen Abgleich, der Anbietertransaktionen täglich gegen Ihre Bestellungen prüft — er fängt alles, was die Wiederholungen verpasst haben.

Q: Muss ich starke Kundenauthentifizierung behandeln?
A: Wenn Sie an Kundinnen in Regionen verkaufen, die sie verlangen, ja, und moderne Anbieter-SDKs übernehmen den Großteil des Ablaufs. Was Sie behandeln müssen, ist das Ergebnis: Eine Bestellung, die auf Authentifizierung wartet, ist nicht bezahlt, und sie als bezahlt zu behandeln heißt, Ware zu versenden, für die Sie nie Geld bekommen haben.

Q: Wie teste ich Zahlungen sicher?
A: Jeder Anbieter hat einen Testmodus mit Karten, die bestimmte Ergebnisse auslösen — Ablehnung, Authentifizierung nötig, Betrug. Arbeiten Sie die ganze Liste ab, einschließlich der unbequemen Fälle in der Tabelle oben. Machen Sie dann vor dem Start eine kleine echte Transaktion im Produktivbetrieb und erstatten Sie sie, denn der Testmodus beansprucht weder Ihre Live-Schlüssel noch Ihre Live-Webhook-URL.

## WooCommerce vs. Shopify vs. Magento: Ein praktischer Vergleich
https://websitedevelopment.biz/de/guides/woocommerce-vs-shopify-vs-magento
Aktualisiert am 2026-08-07 · E-Commerce

Diese drei decken die meisten Shop-Projekte ab, und sie passen zu wirklich verschiedenen Situationen. Die Wahl dreht sich weniger um Funktionen — alle drei können Produkte verkaufen — als darum, wer den Shop pflegt und was passiert, wenn die Anforderungen wachsen.

Dieser Vergleich geht nach Betriebsmodell statt nach Funktionsliste, denn das entscheidet, ob eine Plattform sich bewährt.

### Für wen jede gedacht ist
Klar gesagt, vor dem Detail.
| Shopify | Gehostetes SaaS | Teams, die verkaufen wollen statt Infrastruktur zu pflegen |
| WooCommerce | WordPress-Plugin, selbst gehostet | Inhaltsgetriebene Websites mit überschaubarem Katalog und WordPress-Kenntnissen |
| Magento / Adobe Commerce | Selbst gehostetes Enterprise | Komplexe Kataloge, B2B-Regeln, Kompetenz im Haus oder bei einer Agentur |

### Praktische Unterschiede
Die Vergleiche, die die Entscheidung verändern, statt derer, die auf Marketingseiten stehen.
| Einrichtungsaufwand | Niedrig | Mittel | Hoch |
| Wer patcht die Sicherheit | Der Anbieter | Sie | Sie |
| Anpassung der Kasse | Bewusst begrenzt | Voll | Voll |
| Katalog in großem Umfang | Gut | Verschlechtert sich ohne Arbeit | Dafür gebaut |
| B2B-Preisregeln | Zusatzmodul | Plugin, wechselnde Qualität | Nativ |
| Multi-Store / Multi-Markt | Zusatzkosten | Umständlich | Nativ |
| Laufende Kosten | Abo plus Gebühren plus Apps | Hosting plus Plugins plus Entwicklungszeit | Erhebliches Hosting und Entwicklungszeit |
| Nötige Fähigkeiten | Bediener | WordPress-Entwicklung | Spezialisierte Entwicklung |

### Wo jede bricht
Jede Plattform hat ein Fehlerbild, das nach dem Start auftaucht statt während der Bewertung. Diese kommen am häufigsten vor.
- Shopify: Kassenregeln, die die Plattform nicht erlaubt, und App-Abos, die irgendwann die Plattformgebühr übersteigen. Dazu Transaktionsgebühren, wenn Sie nicht das hauseigene Zahlungsprodukt nutzen.
- WooCommerce: Performance der Listenseiten bei wachsendem Katalog, Plugin-Konflikte nach Updates und Sicherheitsrisiko, wenn niemand das Patchen verantwortet.
- Magento: die Gesamtbetriebskosten. Es ist mächtig und braucht echte Infrastruktur und echte Expertise; unterversorgte Magento-Shops sind langsam und hängen bei Updates hinterher.
- Alle drei: Facettennavigation, die tausende indexierbare URLs erzeugt, sofern sie nicht bewusst konfiguriert wird.
Der häufigste teure Fehler ist, Magento für einen Katalog zu wählen, den WooCommerce bewältigen würde, oder WooCommerce für einen, der Magento braucht. Beide Fehler zeigen sich etwa nach einem Jahr.

### Ausstiegskosten
Wissenswert vor der Festlegung, denn das entscheidet, ob die Wahl umkehrbar ist.
| Shopify | CSV-Export, unkompliziert | Export ohne Passwörter | Export, begrenzte Historie | Feste URL-Präfixe machen die Kartierung fummelig |
| WooCommerce | Voller Datenbankzugriff | Voller Zugriff | Voller Zugriff | Vollständig unter Ihrer Kontrolle |
| Magento | Voller Datenbankzugriff | Voller Zugriff | Voller Zugriff | Vollständig unter Ihrer Kontrolle |
Selbst gehostete Plattformen sind leichter zu verlassen, weil Ihnen die Datenbank gehört. Das ist ein echter Vorteil von Open Source und wird bei der Auswahl selten gewichtet.

Q: Welche ist am günstigsten?
A: Für einen kleinen Shop ist Shopify insgesamt meist am günstigsten, sobald Hosting, Patchen und Entwicklungszeit mitzählen — das Abo ist sichtbar, die Alternativkosten sind es nicht. WooCommerce ist am günstigsten, wenn Sie ohnehin WordPress betreiben und jemand Kompetentes es pflegt. Magento ist in keinem Szenario die günstige Option.

Q: Ist WooCommerce gut für große Kataloge?
A: Es kann tausende Produkte bewältigen, mit ordentlichem Hosting, Caching und Arbeit an den Abfragen — aber es braucht diese Arbeit; die Performance auf Listen- und Filterseiten verschlechtert sich, bevor die Produktanzahl beeindruckend klingt. Ist der Katalog vom ersten Tag an groß und komplex, lohnt der Vergleich mit Plattformen, die dafür gebaut sind.

Q: Brauche ich Magento für B2B?
A: Nicht zwingend, aber B2B-Anforderungen — kundenspezifische Preise, Angebote, Bestellanforderungen, Kontohierarchien — sind dort nativ und anderswo Zusatzmodule. Haben Sie mehrere davon, ist der Vergleich fair. Haben Sie eine, ist ein Zusatzmodul auf einer einfacheren Plattform meist günstiger im Unterhalt.

Q: Kann ich Inhalt und Handel auf derselben Plattform betreiben?
A: WooCommerce macht das natürlich, weil WordPress zuerst ein Inhaltssystem ist. Shopifys Werkzeuge für Inhalte sind schwächer, deshalb kombinieren inhaltslastige Shopify-Shops es oft mit einem eigenen CMS. Ist Ihre Kundengewinnung inhaltsgetrieben, gewichten Sie das ernsthaft — es ist ein größerer praktischer Unterschied, als die meisten Funktionsvergleiche nahelegen.

## E-Commerce-Plattformen im Vergleich: So wählen Sie
https://websitedevelopment.biz/de/guides/ecommerce-plattformen-im-vergleich
Aktualisiert am 2026-08-07 · E-Commerce

Plattformvergleiche veralten schnell, weil sich Funktionen jedes Quartal ändern. Was sich nicht ändert, ist der Satz Fragen, der entscheidet, welche Kategorie von Plattform passt, und die Abwägungen, die jede Kategorie eingeht.

Dieser Leitfaden vergleicht die Kategorien statt der Marken und gibt die Fragen an die Hand, die die Auswahl schnell verengen.

### Die vier Kategorien
Fast jede Option fällt in eine davon, und die Kategorie entscheidet mehr als die Marke darin.
| Gehostetes SaaS | Nur Inhalte und Betrieb | Die meisten kleinen und mittleren Shops |
| Selbst gehostetes Open Source | Alles: Hosting, Updates, Sicherheit | Ungewöhnliche Anforderungen, eigene Kompetenz im Haus |
| CMS-Plugin (z. B. ein Shop-Plugin) | Den ganzen Stack, leichtgewichtig | Inhaltsgetriebene Websites mit überschaubarem Katalog |
| Headless Commerce | Das Frontend und die Integrationsschicht | Mehrere Kanäle, eigene Erlebnisse, größere Teams |

### Die Fragen, die wirklich verengen
Beantworten Sie diese, bevor Sie irgendeine Funktionsliste ansehen. Die meisten schließen ganze Kategorien aus statt einzelner Produkte.
- Wie komplex ist ein einzelnes Produkt? Varianten, konfigurierbare Optionen und kundenindividuelle Preise schließen die einfachsten Werkzeuge aus.
- Wie viele Märkte? Mehrere Steuerregime und Währungen sind der Punkt, an dem billige Plattformen teuer werden.
- Womit muss es sich verbinden? Ein bestehendes ERP- oder Buchhaltungssystem ist meist die entscheidende Randbedingung.
- Wer betreibt es im Alltag? Eine Plattform, die für Routineänderungen eine Entwicklerin braucht, passt nicht zu einem Zwei-Personen-Betrieb.
- Wie hoch ist das realistische Bestellvolumen in zwei Jahren? Transaktionsgebühren skalieren anders als Monatsgebühren.
- Was passiert, wenn Sie gehen? Fragen Sie vor jeder Unterschrift, wie Sie Produkte, Kunden und Bestellungen exportieren.
Die Ausstiegsfrage stellt niemand und sie schmerzt später am meisten. Eine Plattform mit schlechten Exportwerkzeugen ist eine Entscheidung, die Sie nicht billig revidieren können.

### Gesamtkosten, nicht Lizenzkosten
Gehostete Plattformen wirken auf der Abo-Zeile teuer und sind insgesamt oft günstiger, sobald Hosting, Sicherheit und Wartung mitzählen. Selbst gehostet wirkt kostenlos und ist es nicht.
| Abonnement | Monatlich, nach Volumen gestaffelt | Keines |
| Transaktionsgebühr | Oft ein Prozentsatz zusätzlich zu den Zahlungsgebühren | Nur Zahlungsgebühren |
| Hosting | Enthalten | Ihres, und ein Shop braucht echte Ressourcen |
| Sicherheit und PCI | Weitgehend abgedeckt | Ihres, samt Geltungsbereich |
| Updates | Automatisch | Ihre, und sie können Anpassungen brechen |
| Apps und Erweiterungen | Monatlich je App, summiert sich schnell | Meist einmalig oder frei, plus Ihre Zeit |
| Entwicklungszeit | Niedriger bei Routinearbeit | Höher, dauerhaft |

### Wo jede Kategorie bricht
Das Fehlerbild zu kennen ist nützlicher als die Funktionsliste, denn Sie begegnen ihm im zweiten Jahr und nicht in der Demo.
- Gehostetes SaaS: eine Kassenanforderung, die die Plattform nicht zulässt, oder App-Abos, die still die Plattformgebühr übersteigen.
- Selbst gehostet: niemand spielt die Sicherheitsupdates ein, und der Shop wird kompromittiert oder fällt stark zurück.
- CMS-Plugin: Katalogwachstum verschlechtert die Performance, und die Website war nie für Commerce-Abfragen gebaut.
- Headless: das Frontend-Team wird zum Engpass für Änderungen, die das Marketing früher selbst gemacht hat.
Fast jedes davon ist ein betriebliches statt eines technischen Versagens. Wählen Sie die Plattform, die Ihre Organisation tatsächlich betreiben kann, nicht die leistungsfähigste.

Q: Ist Open Source billiger als eine gehostete Plattform?
A: Selten, sobald Hosting, Sicherheitspatches, Entwicklungszeit und die Kosten eines Vorfalls mitzählen. Es ist billiger, wenn Sie Kompetenz im Haus haben, die sonst ungenutzt bliebe, oder wenn Sie Anforderungen haben, die eine gehostete Plattform verweigert. Die Abo-Zeile mit null zu vergleichen ist der Fehler, der es offensichtlich wirken lässt.

Q: Kann ich später die Plattform wechseln?
A: Ja, und es ist ein vollständiges Projekt — typischerweise 30–50 % der Kosten eines Neubaus, sobald Katalogmigration, URL-Kartierung und Nacharbeit an Integrationen mitzählen. Genau deshalb gehört die Exportfrage in die Auswahl. Produkte lassen sich meist sauber exportieren; bei Kunden und Bestellhistorie wird es schwierig.

Q: Was ist mit Headless Commerce?
A: Es ist wirklich nützlich, wenn Sie über mehrere Kanäle verkaufen oder ein Frontend brauchen, das die Plattform nicht liefern kann, und sonst erhebliche Zusatzkomplexität: Ihnen gehören Frontend, Integrationsschicht und deren Deployment. Für einen Ein-Kanal-Shop mit normalem Katalog kauft es meist Flexibilität, die Sie nie ausgeben werden.

Q: Welche Plattform ist am besten für SEO?
A: Sie sind heute weitgehend vergleichbar — die Unterschiede liegen darin, wie viel Kontrolle Sie über URLs, Canonicals und Metadaten haben, und in der Frontend-Performance. Wichtiger ist, ob Ihre Umsetzung Facettennavigation, Blätterung und die Stabilität von Produkt-URLs richtig behandelt, und das ist auf jeder Plattform eine Entscheidung der Umsetzung.

## Onlineshop-Entwicklung: Der vollständige Leitfaden
https://websitedevelopment.biz/de/guides/onlineshop-entwicklung-leitfaden
Aktualisiert am 2026-08-07 · E-Commerce

Ein Onlineshop ist eine Website, an der Geld, Bestand und rechtliche Pflichten hängen. Genau das macht die Entwicklung eines Shops zu einem anderen Projekt als eine Broschürenseite: Die Teile, die am meisten kosten, sind meist nicht die, die Kunden sehen.

Dieser Leitfaden behandelt, was ein Shop-Projekt tatsächlich umfasst, was die Kosten treibt, welche operative Arbeit mit dem Start beginnt, und die Fehler, deren Rückabwicklung teuer ist.

### Was ein Shop jenseits der Ladenfront umfasst
Katalog und Kasse sind der sichtbare Teil. Darunter liegen die Systeme, die entscheiden, ob das Geschäft überhaupt betrieben werden kann, und dorthin fließt bei jedem Shop jenseits des kleinsten der Großteil des Budgets.
- Katalogstruktur: Kategorien, Varianten, Attribute, Bündel, Verfügbarkeitsregeln.
- Preise: brutto oder netto je Markt, Rabatte, Kundengruppen, Währung.
- Zahlungen: mindestens ein Zahlungsdienst, plus Erstattungen, Teilerstattungen und Umgang mit fehlgeschlagenen Zahlungen.
- Versand: Zonen, Gewichte, Maße, Carrier-Regeln, Schwellen für Gratisversand.
- Steuern: Umsatzsteuer je Zielland, Rechnungen mit den Feldern, die Ihre Rechtsordnung verlangt.
- Bestand: Verfügbarkeit, Nachbestellungen und Reservierung während der Kasse, damit Sie nicht überverkaufen.
- Auftragsverwaltung: wo Mitarbeitende Bestellungen bearbeiten — oft ein ganz eigenes System.
- E-Mails: Bestätigung, Versand, Erstattung, abgebrochener Warenkorb, und ihr rechtlicher Inhalt.
- Retouren: die Richtlinie und der Ablauf, der sie umsetzt.
Fragen Sie früh, wo Mitarbeitende Bestellungen tatsächlich bearbeiten werden. Ist es Ihr bestehendes ERP, ist die Anbindung ein erheblicher Teil des Projekts und gehört in die erste Schätzung.

### Was die Kosten treibt
Die Produktanzahl zählt weniger als die Produktkomplexität und die Zahl der Systeme, mit denen der Shop sprechen muss.
| Katalog | Einfache Produkte, ein Preis | Varianten, konfigurierbare Optionen, kundenindividuelle Preise |
| Märkte | Ein Land, eine Währung | Mehrere Steuerregime, Währungen, Sprachen |
| Integrationen | Keine außer Zahlung | ERP, PIM, WMS, Buchhaltung, Marktplatz-Feeds |
| Migration | Neuer Shop, keine Historie | Bestehender Katalog, Kunden, Bestellungen und URLs |
| Abwicklung | Ein Lager, Pauschalversand | Mehrere Standorte, Carrier-Regeln, Streckengeschäft |
| Compliance | Normaler Verbraucherverkauf | Altersgrenze, Lizenzen, regulierte Waren |

### Migration ist ein eigenes Projekt
Einen bestehenden Shop auf eine neue Plattform zu heben ist meist schwerer, als einen neuen zu bauen, und die Schwierigkeit liegt bei Daten und URLs, nicht beim Design.
- Exportieren und bereinigen Sie den Katalog vor allem anderen. Bestandsdaten sind immer schlechter als erinnert.
- Entscheiden Sie, was nicht mitkommt. Auslaufprodukte ohne Traffic müssen nicht migriert werden.
- Kartieren Sie jede alte Produkt- und Kategorie-URL auf eine neue; leiten Sie per 301 um und rechnen Sie mit einer langen Liste.
- Migrieren Sie Kundenkonten ohne Passwörter — erzwingen Sie ein Zurücksetzen, statt Hashes zwischen Systemen zu bewegen.
- Entscheiden Sie, wie viel Bestellhistorie mitkommt. Oft lautet die Antwort „gar keine, das alte System bleibt ein Jahr im Lesemodus".
- Betreiben Sie beide Systeme kurz parallel, wenn der Bestand es erlaubt, und gleichen Sie täglich ab.
- Beobachten Sie den Suchtraffic je Kategorie sechs Wochen lang; eine Kategorie, die einbricht, ist meist eine übersehene Weiterleitung.
Planen Sie für die Bereinigung der Katalogdaten so viel Zeit ein wie für den Bau des Shops. Bei den meisten Migrationen ist sie die größere Aufgabe und die, die niemand eingeplant hat.

### Die Arbeit, die mit dem Start beginnt
Ein Shop ist ein Betriebssystem für ein Geschäft, kein Projekt, das endet. Diese Kosten laufen weiter und fehlen häufig im ersten Budget.
| Produktinhalte | Neue Linien, neue Fotos, neue Beschreibungen |
| Bestandsgenauigkeit | Überverkauf kostet mehr als jeder Entwicklungsfehler |
| Zahlungs- und Plattform-Updates | Zahlungsdienste stellen APIs nach eigenem Zeitplan ab |
| Sicherheitspatches | Shops sind ein Ziel für Zahlungsdaten; Patches sind nicht optional |
| Betrug und Rückbuchungen | Regeln brauchen Nachjustierung, wenn sich der Bestellmix ändert |
| Änderungen im Steuerrecht | Sätze und Schwellen ändern sich je Rechtsordnung, teils jährlich |
| Performance | Katalogwachstum verschlechtert zuerst die Listenseiten |

Q: Was kostet der Aufbau eines Onlineshops?
A: Ein kleiner Shop auf einer gehosteten Plattform mit leichtem Theme kann bei etwa 5.000 $ beginnen. Ein mittelgroßer Shop mit eigenem Design und ein oder zwei Integrationen liegt typischerweise bei 20.000–60.000 $. Große Kataloge mit ERP-Anbindung und mehreren Märkten liegen deutlich darüber. Eine Migration kommt meist mit 30–50 % auf einen vergleichbaren Neubau obendrauf.

Q: Gehostete Plattform oder selbst gehostet?
A: Gehostete Plattformen übernehmen Sicherheit, PCI-Geltungsbereich und Skalierung gegen eine Monatsgebühr und oft einen Umsatzanteil, um den Preis begrenzter Anpassbarkeit. Selbst gehostet gibt volle Kontrolle, und Wartung sowie Compliance-Last gehören Ihnen. Für die meisten kleinen und mittleren Shops ist gehostet die risikoärmere Wahl; das Argument fürs Selberhosten wächst mit ungewöhnlichen Anforderungen und Umsatz.

Q: Brauche ich ein eigenes Auftragsverwaltungssystem?
A: Unter einigen Dutzend Bestellungen am Tag reicht meist die Plattform-Verwaltung. Darüber, oder bei mehreren Verkaufskanälen, zahlt sich ein eigenes System schnell aus. Die Frage, die vor der Umsetzung zu beantworten ist: Wo liegt der maßgebliche Bestandswert? Denn das entscheidet, welches System welchem sagt, wie viel da ist.

Q: Was ist der häufigste Fehler beim Shop-Aufbau?
A: Steuern und Versand als Konfiguration zu behandeln statt als Anforderungen. Es sind Geschäftsregeln mit Sonderfällen — Schwellen, Zonen, gemischte Warenkörbe, digitale Güter — und sie in Woche acht zu entdecken schreibt die Kasse neu. Halten Sie sie in der Discovery schriftlich fest, mit Beispielen für die unbequemen Fälle.

## SEO-freundliche URL-Struktur: Regeln, die weiterhin zählen
https://websitedevelopment.biz/de/guides/seo-freundliche-url-struktur
Aktualisiert am 2026-08-07 · SEO

URLs sind ein kleiner Ranking-Faktor und ein großer Faktor für Bedienbarkeit und Wartung. Ihr eigentlicher Wert ist Stabilität: Eine URL, die Sie nie ändern müssen, ist eine URL, die ihre Links, ihre Rankings und ihre Lesezeichen behält.

Dieser Leitfaden behandelt die Regeln, die weiterhin zählen, die, die es nicht mehr tun, und wie man eine URL ändert, wenn es wirklich sein muss.

### Die Regeln, denen zu folgen sich lohnt
Diese sind über Suchmaschinen hinweg konsistent und, wichtiger, über die Jahre — es geht ebenso sehr um Wartung wie um Ranking.
- Nur Kleinschreibung. Manche Server behandeln /Seite und /seite als verschiedene URLs, was versehentlich Duplikate erzeugt.
- Bindestriche zwischen Wörtern, keine Unterstriche und kein CamelCase.
- Kurz und beschreibend. Liest jemand die URL vor, sollte er die Seite erraten können.
- Füllwörter sind unnötig: /guides/website-planung schlägt /guides/wie-plane-ich-eine-website-fuer-mein-unternehmen.
- Keine Dateiendungen auf Inhaltsseiten. /ueber-uns, nicht /ueber-uns.php — das verbirgt die Umsetzung und überlebt eine Migration.
- Eine kanonische Entscheidung zum abschließenden Schrägstrich, per Weiterleitung erzwungen.
- ASCII, wo praktikabel; Nicht-ASCII-URLs funktionieren, werden aber beim Kopieren prozentkodiert, was hässlich und fehleranfällig ist.
Die wertvollste Eigenschaft ist Stabilität. Eine leicht unvollkommene URL, die sich nie ändert, ist mehr wert als eine optimierte, die sich zweimal ändert.

### Was kaum noch zählt
Mehrere langlebige Überzeugungen über URLs haben heute begrenzte Wirkung, und ihnen zu folgen kann sogar schaden.
| URLs mit exakter Keyword-Übereinstimmung ranken besser | Bestenfalls marginal; Häufung wirkt spammig |
| Tiefe Ordnerstruktur signalisiert Hierarchie | Klicktiefe zählt, Pfadtiefe kaum |
| Daten in URLs helfen der Aktualität | Sie lassen zeitlose Inhalte veraltet wirken |
| Kürzer ist immer besser | Beschreibend schlägt knapp; /p/4821 hilft niemandem |
| Subdomain versus Unterordner ist entscheidend | Unterordner sind einfacher zu verwalten; beides kann funktionieren |
| Query-Strings können nicht indexiert werden | Können sie, aber sie vervielfachen Duplikate — bevorzugen Sie saubere Pfade |

### Mehrsprachige URL-Muster
Für eine Website in mehreren Sprachen ist das URL-Muster eines der am schwersten nachträglich änderbaren Dinge, weil es mit hreflang, Canonicals und jeder Weiterleitung zusammenspielt, die Sie je schreiben werden.
| Unterverzeichnis | site.com/de/guides | Am einfachsten; eine Domain sammelt alle Autorität |
| Subdomain | de.site.com/guides | Sauberere Trennung; mehr Einrichtung, geteilte Signale |
| Länderdomain | site.de/guides | Stärkstes lokales Signal; eine eigene Website zu betreiben |
| Parameter | site.com/guides?lang=de | Vermeiden — schwache Signale und Duplikatrisiko |
Was Sie auch wählen, entscheiden Sie getrennt, ob der Slug selbst übersetzt wird. Übersetzte Slugs helfen der lokalen Relevanz; identische sind einfacher zu pflegen. Beides ist vertretbar — es sich nachträglich anders zu überlegen nicht.

### Eine URL ändern, ohne Traffic zu verlieren
Manchmal ist eine Änderung wirklich notwendig. Das Vorgehen ist mechanisch, und jeder übersprungene Schritt ist die Stelle, an der der Traffic verschwindet.
- Bestätigen Sie, dass es sich lohnt. Eine URL-Änderung kostet immer etwas; eine kleine Formulierungsverbesserung zahlt das selten zurück.
- Kartieren Sie alt auf neu, eins zu eins. Jede alte URL bekommt ein konkretes Ziel, keine Kategorieseite.
- Setzen Sie 301 um, nicht 302, und prüfen Sie, dass jede Weiterleitung einen einzigen Sprung macht.
- Aktualisieren Sie interne Links, damit sie direkt auf die neue URL zeigen. Verlassen Sie sich nicht auf Ihre eigenen Weiterleitungen.
- Aktualisieren Sie die Sitemap und lassen Sie die Weiterleitungen dauerhaft bestehen — externe Links werden nie aktualisiert.
- Beobachten Sie die Search-Console-Abdeckung und Ihren Top-Seiten-Bericht vier bis sechs Wochen lang.
- Rechnen Sie mit einem Einbruch und untersuchen Sie nur, wenn er nach einem Monat weiter zunimmt.

Q: Sollte ich Keywords in URLs aufnehmen?
A: Nehmen Sie die Wörter auf, die die Seite beschreiben — das sind meist die Keywords. Was Sie nicht tun sollten, ist Varianten zu häufen: /webentwicklung-leistungen-guenstige-webentwicklung ist in jeder Hinsicht schlechter als /webentwicklung-leistungen, auch für die Menschen, die es in den Suchergebnissen sehen.

Q: Subdomain oder Unterordner für einen Blog?
A: In den meisten Fällen Unterordner. site.com/blog ist einfacher zu verwalten, teilt die angesammelten Signale der Domain und braucht keine eigene technische Einrichtung. Subdomains ergeben Sinn, wenn der Bereich wirklich eine eigene Anwendung ist, ein eigenes Team hat oder auf anderer Infrastruktur laufen muss.

Q: Wie lange soll ich alte Weiterleitungen behalten?
A: Dauerhaft. Sie kosten fast nichts, und externe Links auf Ihre alten URLs werden nie aktualisiert. Was Sie tun sollten, ist regelmäßig die Ketten zusammenzufassen, die durch aufeinanderfolgende Migrationen entstanden sind, sodass jede alte URL in einem einzigen Sprung direkt auf das aktuelle Ziel zeigt.

Q: Schaden URL-Parameter dem SEO?
A: Sie sind an sich nicht schädlich, aber sie vervielfachen beinahe doppelte URLs schnell — Sortier-, Filter- und Tracking-Parameter können tausende Varianten einer Seite erzeugen. Nutzen Sie saubere Pfade für alles, was indexiert werden soll, und kanonisieren oder noindexen Sie die Parametervarianten.

## Mehrsprachige Website-Entwicklung: Struktur, URLs und Ablauf
https://websitedevelopment.biz/de/guides/mehrsprachige-website-entwicklung
Aktualisiert am 2026-08-07 · CMS

Einer Website Sprachen hinzuzufügen ist selten nur Übersetzung. Es ändert die URL-Struktur, fügt einen Satz reziproker Tags hinzu, die still brechen, und führt einen Inhaltsablauf ein, in dem aus einer Seite zwölf Seiten werden, die auseinanderdriften können.

Dieser Leitfaden behandelt die strukturellen Entscheidungen, die technischen Anforderungen und den Ablauf, der Übersetzungen davor bewahrt, zu veralten.

### Entscheiden Sie zuerst das URL-Muster
Das ist die Entscheidung, deren Umkehr teuer ist, denn sie berührt jede URL, jede Weiterleitung und jedes hreflang-Tag der Website.
| Unterverzeichnis | site.com/de/guides | Die meisten Websites — am einfachsten, eine Domain sammelt Autorität |
| Subdomain | de.site.com/guides | Getrennte Infrastruktur oder getrennte Teams |
| Länderdomain | site.de/guides | Starke lokale Festlegung, und eine eigene Website zu betreiben |
| Parameter | site.com/guides?lang=de | Vermeiden — schwache Signale, Duplikatrisiko |
Entscheiden Sie getrennt, ob der Slug übersetzt wird. Übersetzte Slugs helfen der lokalen Relevanz; identische sind einfacher zu pflegen. Beides ist vertretbar — es sich später anders zu überlegen nicht.

### Die technischen Anforderungen
Jede davon versagt still, weshalb mehrsprachige Websites so oft kein funktionierendes hreflang haben, obwohl die Tags da sind.
- Reziprokes hreflang. Jede Seite einer Sprachgruppe listet jede andere auf, sich selbst eingeschlossen. Eine fehlende Rückreferenz verwirft die Gruppe.
- Einheitliche Codes. Derselbe Code im HTML und in der Sitemap. Zwei Codes für eine Seite zerstören die Gruppe.
- x-default, das auf die Sprachauswahl oder die Standardversion zeigt.
- Korrekte lang- und dir-Attribute am html-Element jeder Version.
- Selbstreferenzierender Canonical je Sprache — kanonisieren Sie Übersetzungen nie auf das Original.
- Keine automatische Weiterleitung nach IP oder Browsersprache. Sie stört das Crawlen und überschreibt eine bewusste Wahl; bieten Sie stattdessen einen Vorschlag an.
- Übersetzte Metadaten. Titel und Beschreibungen in der Zielsprache, nicht in der Ausgangssprache.

### Ein Übersetzungsablauf, der hält
Das Fehlerbild ist nicht die erste Übersetzung, sondern die fünfte Änderung an der englischen Seite, die die anderen elf nie erreicht.
- Modellieren Sie Übersetzungen als verknüpfte Versionen eines Inhaltselements, damit das System weiß, dass sie zusammengehören.
- Verfolgen Sie, welche Übersetzungen gegenüber der Quelle veraltet sind, und zeigen Sie es in der Bearbeitungsoberfläche.
- Entscheiden Sie, was bei fehlender Übersetzung passiert: auf die Standardsprache zurückfallen oder diese URL gar nicht veröffentlichen.
- Veröffentlichen Sie nie eine URL ohne Übersetzung — eine Seite, die halb in einer anderen Sprache erscheint, ist schlimmer als gar keine.
- Führen Sie ein Prüfdatum je Sprache, nicht je Inhaltselement.
- Geben Sie Übersetzenden Kontext: Ein Screenshot oder eine Vorschau schlägt eine Tabelle mit Textbausteinen.
- Entscheiden Sie, wer jede Sprache verantwortet. Unverantwortete Sprachen veralten zuerst.
Maschinelle Übersetzung als Ausgangspunkt ist in Ordnung; sie ungeprüft zu veröffentlichen nicht. Ungeprüfte Ausgabe liest sich als ungeprüft, und es ist genau die Art von geringwertigem Inhalt, zu der sich Suchmaschinen zunehmend deutlich äußern.

### Jenseits des Textes
Die Übersetzung ist der Teil, den alle einplanen. Das sind die Teile, die übersehen werden und sichtbare Fehler verursachen.
| Daten und Zahlen | Format und Trennzeichen unterscheiden sich je Sprachraum |
| Währung | Symbol, Position und Rundungsregeln |
| Adressen und Telefonnummern | Feldreihenfolge und Prüfregeln |
| Namen | Die Reihenfolge von Vor- und Nachname ist nicht universell |
| Textlänge | Deutsch und Finnisch werden lang; Layouts müssen nachgeben |
| Leserichtung | Arabisch und Hebräisch brauchen logische CSS-Eigenschaften |
| Bilder mit Text | Brauchen eine Version je Sprache, oder keinen Text im Bild |
| Rechtsseiten | Anforderungen unterscheiden sich nach Rechtsordnung, nicht nur nach Sprache |

Q: Sollte ich Besucher automatisch in ihre Sprache leiten?
A: Nein. Automatische Weiterleitung nach IP oder Browsersprache stört das Crawlen — ein Crawler aus einem Land sieht die anderen Versionen vielleicht nie — und sie überschreibt bewusste Entscheidungen, was für alle, die in einer Zweitsprache lesen, ärgerlich ist. Zeigen Sie einen schließbaren Vorschlag und lassen Sie die Besucherin entscheiden.

Q: Ist maschinelle Übersetzung akzeptabel?
A: Als erster Entwurf ja, und sie spart echtes Geld. Ohne menschliche Prüfung veröffentlicht erzeugt sie Inhalte, die sich maschinell erzeugt lesen, was sowohl Nutzer als auch die Qualitätsbewertung der Suche betrifft. Der pragmatische Ansatz ist maschinelle Übersetzung plus muttersprachliche Prüfung, besonders bei Seiten, die etwas verkaufen oder etwas Wichtiges erklären.

Q: Was zerstört hreflang am häufigsten?
A: Nicht reziproke Tags: Seite A listet B, B listet A nicht, und die ganze Gruppe wird ignoriert. An zweiter Stelle stehen abweichende Codes zwischen HTML und Sitemap. Beides vermeidet man, indem man hreflang aus einer einzigen maßgeblichen Quelle erzeugt, statt zwei Listen zu pflegen.

Q: Muss ich die ganze Website übersetzen?
A: Nein, und teilweise Übersetzung ist normal. Übersetzen Sie, wofür es in diesem Markt Nachfrage gibt, und lassen Sie den Rest nur in der Ausgangssprache existieren. Was Sie nicht tun dürfen: eine leere oder halb übersetzte URL veröffentlichen — entweder existiert die Seite in dieser Sprache richtig oder gar nicht.

## Website-Geschwindigkeit optimieren: eine praktische Reihenfolge
https://websitedevelopment.biz/de/guides/website-geschwindigkeit-optimieren
Aktualisiert am 2026-08-07 · SEO

Arbeit an der Website-Geschwindigkeit hat eine ausgeprägte Pareto-Form: Eine Handvoll Korrekturen macht auf den meisten Websites den Großteil der Verbesserung aus, und es sind fast immer Bilder, Serverantwort und Drittanbieterskripte.

Dieser Leitfaden behandelt die Reihenfolge, in der zu arbeiten ist, wie man misst, ob eine Änderung geholfen hat, und die Optimierungen, die den Aufwand meist nicht wert sind.

### Messen Sie, bevor Sie irgendetwas ändern
Ohne Messung optimiert man, was am einfachsten ist, statt was langsam ist. Zwei Messungen, dann Arbeit.
- Holen Sie Felddaten echter Besucher — den Core-Web-Vitals-Bericht in der Search Console oder Ihr eigenes Monitoring.
- Führen Sie einen Labortest auf den drei wichtigsten Templates durch, gedrosselt auf ein Mittelklasse-Handy im 4G-Netz.
- Notieren Sie die Zahlen, bevor Sie anfangen. Ohne Ausgangswert können Sie nicht sagen, ob eine Änderung geholfen hat.
- Bestimmen Sie je Template das größte einzelne Asset und die größte einzelne blockierende Anfrage.
- Notieren Sie die Time to First Byte gesondert: Liegt sie über 800 ms, rettet Sie keine Frontend-Arbeit.

### Die Reihenfolge, die sich lohnt
Grob nach Verbesserung je Arbeitsstunde, für eine typische Inhalts- oder Broschürenseite.
| Bilder optimieren und richtig dimensionieren | Groß | Niedrig |
| Ungenutzte Drittanbieterskripte entfernen | Groß | Niedrig — überwiegend eine politische Aufgabe |
| Caching und ein CDN aktivieren | Groß | Niedrig |
| Renderblockierendes CSS und JS beheben | Mittel bis groß | Mittel |
| JavaScript-Bundle verkleinern | Mittel bis groß | Mittel bis hoch |
| Langsame Datenbankabfragen beheben | Groß, wo zutreffend | Mittel |
| Schriftladen optimieren | Mittel | Niedrig |
| Textassets minimieren und komprimieren | Klein | Niedrig — meist schon aktiv |
| CSS-Selektoren mikro-optimieren | Vernachlässigbar | Nicht der Mühe wert |

### Bilder: meist der größte Gewinn
Auf den meisten Websites machen Bilder den Großteil des Seitengewichts aus, und die meisten werden um ein Vielfaches größer ausgeliefert, als sie angezeigt werden. Das ist die billigste große Verbesserung, die es gibt.
- Liefern Sie WebP oder AVIF; beide werden breit unterstützt und sind bei gleicher Qualität typischerweise 25–50 % kleiner als JPEG.
- Erzeugen Sie mehrere Größen und nutzen Sie srcset mit sizes, damit Handys handygroße Dateien laden.
- Liefern Sie nie ein 2000-px-Bild in einen 400-px-Platz — dieser eine Fehler ist außerordentlich verbreitet.
- Laden Sie alles unterhalb der Falz verzögert und nichts darüber.
- Automatisieren Sie es im Build oder im CMS. Von Hand optimierte Bilder hören auf, optimiert zu sein, sobald jemand anderes eines hochlädt.
- Entfernen Sie Metadaten; Kamera-EXIF kann zehner Kilobyte je Datei ausmachen.
Die Automatisierung ist der Punkt. Ein einmaliger Optimierungsdurchlauf verfällt binnen Monaten, wenn neue Inhalte dazukommen, und niemand merkt es, bis sich das Seitengewicht verdoppelt hat.

### Drittanbieterskripte und der Server
Das sind die zwei Bereiche, in denen das Problem meist organisatorisch statt technisch ist: Niemand verantwortet den Tag-Manager, und niemand verantwortet die Hosting-Entscheidung.
| Tag-Manager mit unbekannten Tags | Jedes Tag prüfen; alles löschen, was niemand begründen kann |
| Chat-Widget lädt auf jeder Seite | Bei Interaktion laden, oder nur dort, wo Support gebraucht wird |
| Mehrere Analytics-Werkzeuge | Eines behalten; jedes ist ein vollständiges Skript und eine Verbindung |
| A/B-Test-Skript blockiert das Rendern | Serverseitig verlagern, oder ein Aufblitzen akzeptieren und async laden |
| Langsame TTFB auf Shared Hosting | Vollseiten-Caching ergänzen; Tarif anheben, wenn es bleibt |
| Ungecachte Datenbankabfragen | Die teuren cachen; für die häufigen Indizes anlegen |
| Kein CDN | Eines ergänzen — die billigste globale Latenzkorrektur, die es gibt |
Drittanbieterskripte sind die verlässlichste Quelle unerklärter Verlangsamungen, weil sie sich ändern, ohne es Ihnen zu sagen, und außerhalb Ihres Deployment-Prozesses stehen.

Q: Was ist eine gute Ladezeit?
A: Die nützlichen Ziele sind die Core-Web-Vitals-Schwellen statt einer einzelnen Ladezahl: LCP unter 2,5 Sekunden und Time to First Byte unter 800 ms. Die Gesamtladezeit ist ein schlechtes Maß, weil eine Seite lange nutzbar sein kann, bevor jedes Asset fertig ist — und auf einem langsamen Gerät weit davor unbenutzbar.

Q: Erhöht eine schnellere Website die Konversion?
A: In der Regel ja, und der Effekt ist dort am größten, wo Seiten derzeit langsam sind und Besucher in Mobilfunknetzen unterwegs. Der Gewinn von drei auf zwei Sekunden ist weit größer als von anderthalb auf eine. Ist Ihre Website schon schnell, investieren Sie den Aufwand lieber in Inhalt und Klarheit — der Ertrag ist besser.

Q: Lösen Caching-Plugins alles?
A: Sie lösen eine echte Sache gut — wiederholte Serverarbeit für dieselbe Seite — und können neue Probleme schaffen, besonders bei angemeldeten Nutzern, Warenkörben und Formularen. Gegen überdimensionierte Bilder und Drittanbieterskripte, meist die größeren Probleme, tun sie nichts. Nützlich, aber nicht ausreichend.

Q: Lohnt sich serverseitiges Rendering fürs Tempo?
A: Wenn Ihre Seiten derzeit nur im Browser gerendert werden, ja: Server-Rendering oder statische Generierung beseitigt einen kompletten Umlauf, bevor Inhalt erscheint, und hilft zugleich der Indexierung. Sind Ihre Seiten bereits serverseitig geliefertes HTML, stellt sich die Frage nicht — Sie haben den Vorteil schon.

## Core Web Vitals für Entwickler: Was die Zahlen wirklich bewegt
https://websitedevelopment.biz/de/guides/core-web-vitals-fuer-entwickler
Aktualisiert am 2026-08-07 · SEO

Core Web Vitals sind drei Feldmessungen dafür, wie sich eine Seite anfühlt: wie lange es dauert, bis der Hauptinhalt erscheint, wie stark er sich beim Laden bewegt, und wie schnell er auf Eingaben reagiert. Sie sind ein Ranking-Signal und, wichtiger noch, sie hängen damit zusammen, ob Menschen bleiben.

Dieser Leitfaden behandelt, was jede Kennzahl misst, die konkreten Ursachen hinter schlechten Werten, und die Korrekturen, die Felddaten bewegen statt nur Laborwerte.

### Was die drei Kennzahlen messen
Jede hat einen Schwellenwert für „gut" und jede hat wenige übliche Ursachen. Beachten Sie: Für das Ranking zählen Felddaten echter Besucher, nicht ein Laborwert von Ihrem Laptop.
| LCP | Unter 2,5 s | Zeit, bis das größte sichtbare Element gerendert ist | Unoptimiertes Hero-Bild, langsamer Server, renderblockierendes CSS |
| CLS | Unter 0,1 | Wie stark sich das Layout beim Laden bewegt | Bilder ohne Maße, eingefügte Banner, spät geladene Webfonts |
| INP | Unter 200 ms | Reaktionsfähigkeit auf Nutzerinteraktion | Lange JavaScript-Aufgaben blockieren den Haupt-Thread |
Laborwerkzeuge messen einen Ladevorgang auf einer Maschine. Felddaten sind das 75. Perzentil echter Besuche, was alte Handys in schlechten Netzen einschließt — genau die Besucher, die am ehesten gehen.

### LCP beheben
LCP ist fast immer ein Bild oder eine Überschrift, die hinter etwas anderem blockiert. Arbeiten Sie die Punkte der Reihe nach ab; die ersten beiden beheben die meisten Websites.
- Identifizieren Sie das tatsächliche LCP-Element in den Felddaten. Das falsche Bild zu optimieren ist die häufigste vergeudete Mühe.
- Laden Sie das LCP-Bild nie verzögert. Geben Sie ihm stattdessen fetchpriority="high".
- Liefern Sie es in einem modernen Format in der Größe aus, in der es angezeigt wird, mit srcset für kleinere Bildschirme.
- Laden Sie die Schrift des LCP-Textes vor und nutzen Sie font-display: swap, damit Text während des Wartens nicht unsichtbar ist.
- Entfernen Sie renderblockierendes CSS und JavaScript aus dem head; inlinen Sie das kritische CSS, wenn die Seite klein genug ist.
- Senken Sie die Time to First Byte mit Caching und einem CDN — keine Frontend-Arbeit kann einen langsamen Server ausgleichen.
- Kürzen Sie Drittanbieterskripte im kritischen Pfad. Jedes ist eine DNS-Auflösung, eine Verbindung und eine unvorhersehbare Datei.

### CLS beheben
Layoutverschiebung ist fast vollständig vermeidbar und die Korrekturen sind billig. Es ist außerdem die Kennzahl, die Besucher am unmittelbarsten spüren — sie ist der Grund, warum Menschen daneben tippen.
- Setzen Sie width- und height-Attribute an jedem Bild und Video, damit der Browser Platz reserviert.
- Reservieren Sie Platz für Werbung, Einbettungen und iframes mit einem Container fester Seitenverhältnisse.
- Fügen Sie nach dem Laden nie Inhalt oberhalb bestehenden Inhalts ein — Cookie-Banner gehören nach unten oder als Overlay.
- Passen Sie die Metriken der Ersatzschrift an den Webfont an, oder nutzen Sie size-adjust, damit der Wechsel die Seite nicht umbricht.
- Vermeiden Sie es, Layout-Eigenschaften zu animieren. Animieren Sie transform und opacity, die keinen Reflow auslösen.
- Geben Sie dynamisch geladenen Bereichen eine min-height, damit sie sich nicht von null aufblähen.

### INP beheben
INP hat First Input Delay abgelöst und ist schwieriger, weil es jede Interaktion über den ganzen Besuch misst statt nur die erste. Schlechtes INP ist fast immer zu viel JavaScript auf dem Haupt-Thread.
| Großes Bundle beim Laden geparst | Code-Splitting; nur laden, was die Seite braucht |
| Lange Aufgaben über 50 ms | Arbeit in Stücke teilen und dem Haupt-Thread abgeben |
| Teure Event-Handler | Entprellen und schwere Arbeit vom Interaktionspfad nehmen |
| Schwere Drittanbieter-Tags | Nach der Interaktion laden oder entfernen — prüfen Sie, was jedes einbringt |
| Großes DOM (10.000+ Knoten) | Lange Listen virtualisieren; tief verschachteltes Markup vereinfachen |
| Layout-Thrashing in Handlern | Lese- und Schreibzugriffe bündeln statt zu verschränken |
Auf Inhaltsseiten ist die wertvollste INP-Maßnahme meist, JavaScript zu löschen statt es zu optimieren. Fragen Sie, was jedes Skript einbringt; Tag-Manager sammeln Skripte an, an deren Einbau sich niemand erinnert.

Q: Wie stark beeinflussen Core Web Vitals das Ranking?
A: Sie sind ein echtes, aber moderates Signal und wirken eher als Gleichstandsentscheider denn als Ersatz für Relevanz. Eine schnelle Seite zum falschen Thema überholt keine langsamere Seite, die die Anfrage beantwortet. Das stärkere Argument fürs Beheben ist Verhalten: Langsame, springende Seiten verlieren Besucher, bevor Ranking überhaupt ins Spiel kommt.

Q: Warum ist mein Lighthouse-Wert gut, aber meine Felddaten schlecht?
A: Weil Lighthouse einen Ladevorgang auf Ihrer Maschine mit Ihrer Verbindung simuliert, und Felddaten das 75. Perzentil echter Besuche sind — inklusive drei Jahre alter Handys in überlasteten Mobilfunknetzen. Wenn beide sich widersprechen, zählen die Felddaten. Nutzen Sie Laborwerkzeuge zur Diagnose, nicht zur Benotung.

Q: Muss ich alle drei Kennzahlen beheben?
A: Beheben Sie die, die durchfallen, in der Reihenfolge dessen, was Ihre Besucher erleben. CLS ist meist am billigsten zu beheben und für Nutzer am störendsten, also ein guter Anfang. LCP hat den größten Einfluss darauf, ob Menschen warten. INP zählt am meisten auf interaktiven Websites und am wenigsten bei statischen Artikeln.

Q: Wie lange dauert es, bis Verbesserungen sichtbar werden?
A: Felddaten sind ein rollierendes 28-Tage-Fenster, also braucht spürbare Bewegung etwa vier Wochen, nachdem eine Korrektur alle Besucher erreicht hat. Beurteilen Sie eine Änderung nicht nach drei Tagen. Prüfen Sie aber sofort die Laborwerte, um zu bestätigen, dass die Korrektur tatsächlich das getan hat, was Sie erwartet haben.

## CMS-Migration: Umziehen, ohne Traffic zu verlieren
https://websitedevelopment.biz/de/guides/cms-migration-leitfaden
Aktualisiert am 2026-08-07 · CMS

Eine CMS-Migration bewegt Inhalte von einem System in ein anderes. Das Risiko ist nicht technisch — Export und Import sind gelöste Probleme —, sondern dass sich unterwegs Struktur, URLs und Metadaten ändern, und Suchmaschinen bemerken alle drei.

Dieser Leitfaden behandelt die Abfolge, die den Traffic erhält, das Audit, das zuerst kommen sollte, und worauf danach zu achten ist.

### Auditieren, bevor Sie irgendetwas bewegen
Alles zu migrieren ist der Standard und meist die falsche Wahl. Die meisten Websites tragen einen erheblichen Schwanz von Seiten ohne Traffic, ohne Links und ohne Zweck, und sie mitzunehmen importiert das Problem ins neue System.
- Crawlen Sie die bestehende Website, um jede tatsächlich existierende URL zu erfassen.
- Ziehen Sie zwölf Monate Traffic je URL, plus eingehende Links.
- Klassifizieren Sie jede Seite: unverändert migrieren, neu schreiben, mit einer anderen zusammenführen oder streichen.
- Alles mit Traffic oder Links braucht ein Ziel. Alles andere kann gehen.
- Notieren Sie, welche Seiten strukturierte Daten, eigene Felder oder ungewöhnliche Templates tragen.
- Exportieren Sie die Metadaten — Titel und Beschreibungen — gesondert. Sie sind das bei Migrationen am häufigsten verlorene Gut.
Dünne Seiten während einer Migration in stärkere zusammenzuführen ist eines der wenigen verlässlich positiven SEO-Ergebnisse der ganzen Übung. Leiten Sie die zusammengeführten auf die verbleibende weiter.

### Inhalte modellieren, bevor Sie sie importieren
Die Versuchung ist, die alte Struktur exakt nachzubauen. Das importiert alte Kompromisse. Modellieren Sie die Inhalte so, wie sie sein sollten, und bilden Sie dann die alten Daten darauf ab.
| Inhaltstypen | Was sich wirklich unterscheidet — Seite, Artikel, Produkt, Person, Veranstaltung |
| Felder | Strukturierte Felder statt eines HTML-Klumpens, wo immer machbar |
| Taxonomien | Welche Kategorien und Schlagworte überleben; die meisten Websites haben zu viele |
| Medien | Wo Dateien liegen und ob sich Pfade ändern |
| Autoren und Daten | Echte Veröffentlichungsdaten erhalten; nicht alle auf heute zurücksetzen |
| Metadaten | Titel, Beschreibungen und Canonicals ausdrücklich kartiert |
| Weiterleitungskarte | Alte URL auf neue URL, eins zu eins, laufend aufgebaut |
Veröffentlichungsdaten beim Import zurückzusetzen ist ein verbreitetes Missgeschick und zerstört das Aktualitätssignal Ihres gesamten Archivs auf einen Schlag.

### URLs erhalten und weiterleiten, was nicht bleiben kann
Der mit Abstand größte Faktor dafür, ob eine Migration Traffic kostet.
- Behalten Sie die bestehende URL-Struktur, sofern sie nicht wirklich kaputt ist. „Das neue CMS bevorzugt ein anderes Muster" ist kein hinreichender Grund.
- Wo URLs sich ändern müssen, kartieren Sie eins zu eins — nie auf eine Kategorieseite oder die Startseite.
- Nutzen Sie 301-Weiterleitungen und prüfen Sie, dass jede ein einziger Sprung ist.
- Leiten Sie auch Mediendateien weiter. Bilder sammeln Links und erscheinen in der Bildersuche.
- Behalten Sie Weiterleitungen dauerhaft; externe Links werden nie aktualisiert.
- Testen Sie die Weiterleitungskarte auf Staging mit der vollständigen Liste vor dem Start, nicht mit einer Stichprobe.

### Der Start und die sechs Wochen danach
Die Migration ist mit der Umstellung nicht abgeschlossen. Die meisten Probleme werden im folgenden Monat sichtbar.
- Starten Sie, wenn Sie es beobachten können. Nicht freitags, nicht vor einem Feiertag.
- Prüfen Sie robots.txt, Meta-Robots, Canonicals und die Sitemap sofort in der Produktion.
- Lassen Sie die vollständige Weiterleitungsliste gegen die Produktion laufen und suchen Sie nach 404ern und Ketten.
- Reichen Sie die neue Sitemap in der Search Console ein und beobachten Sie die Abdeckung eine Woche lang täglich.
- Vergleichen Sie die Top-Seiten mit dem Vorzeitraum; eine Seite, die stark einbricht, hat meist eine konkrete Ursache.
- Beobachten Sie die Serverprotokolle auf Crawler-404er — sie finden übersehene URLs schneller als Analytics.
- Rechnen Sie mit Schwankung über zwei bis sechs Wochen; untersuchen Sie einen Rückgang, der nach einem Monat weiter zunimmt.
- Behalten Sie das alte System eine Weile im Lesemodus, damit Sie nachsehen können, was eine Seite früher enthielt.

Q: Verliere ich beim Migrieren Suchtraffic?
A: Rechnen Sie auch bei korrekter Ausführung mit einem Einbruch von einigen Wochen — Suchmaschinen müssen neu crawlen und neu bewerten. Mit sauberen Weiterleitungen und erhaltenen Inhalten kehrt der Traffic normalerweise binnen zwei bis sechs Wochen auf das vorherige Niveau zurück. Ein dauerhafter Verlust lässt sich fast immer auf übersehene Weiterleitungen, veränderte Inhalte oder still gestrichene Seiten zurückführen.

Q: Sollte ich gleichzeitig neu gestalten?
A: Es ist verlockend und erschwert die Diagnose erheblich: Bewegt sich der Traffic, können Sie nicht sagen, ob es die Migration oder das Design war. Können Sie beides trennen, migrieren Sie zuerst mit den bestehenden Templates, bestätigen Sie die Stabilität und gestalten Sie dann neu. Muss es zusammen passieren, seien Sie beim Erhalt von URLs und Inhalten umso strenger.

Q: Wie migriere ich Inhalte, die sich nicht sauber abbilden lassen?
A: Manche Inhalte widersetzen sich der Automatisierung immer — eigene Layouts, eingebettete Widgets, handgebaute Tabellen. Erkennen Sie sie im Audit und planen Sie Handarbeit dafür ein. Die letzten 5 % automatisieren zu wollen kostet meist mehr, als sie von Hand zu machen, und liefert schlechtere Ergebnisse.

Q: Sollte ich das alte CMS weiterlaufen lassen?
A: Halten Sie es einige Monate erreichbar, aber nicht öffentlich: im Lesemodus, für Suchmaschinen gesperrt, unter einer internen Adresse. Es ist unschätzbar, um nachzusehen, was eine Seite früher sagte, wenn etwas falsch aussieht. Nehmen Sie es danach ordentlich außer Betrieb — eine verwaiste öffentliche Installation ist ein Sicherheitsrisiko.

## Checkliste für technisches SEO für Webentwickler
https://websitedevelopment.biz/de/guides/technisches-seo-checkliste
Aktualisiert am 2026-08-07 · SEO

Technisches SEO ist der Teil der Suchmaschinenarbeit, der in der Codebasis lebt statt im Redaktionsplan. Es ist weitgehend eine Checkliste, und das meiste davon ist überprüfbar statt Ansichtssache.

Dieser Leitfaden ist diese Checkliste, gruppiert nach dem Problem, das jeder Punkt verhindert, mit den Fehlern, die häufig genug sind, um sie zu benennen.

### Indexierungssteuerung
Ziel ist, dass genau die Seiten indexiert sind, die Sie indexiert haben wollen, und sonst nichts — keine Staging-Kopien, keine Filterpermutationen, keine druckfreundlichen Duplikate.
- Ein kanonischer Hostname; jede andere Variante leitet per 301 dorthin — einschließlich HTTP und dem www-/nicht-www-Zwilling.
- Selbstreferenzierender Canonical auf jeder indexierbaren Seite.
- noindex, follow auf dünnen oder doppelten Seiten: interne Suchergebnisse, Filterkombinationen, Dankeseiten.
- Sperren Sie in der robots.txt nie eine Seite, die ein noindex trägt — das Tag kann dann nie gelesen werden, und die URL bleibt im Index hängen.
- Staging per HTTP-Authentifizierung gesperrt, nicht nur per robots.txt.
- Parameterbehandlung entschieden: welche Query-Strings eine eigene Seite erzeugen und welche nicht.
noindex und eine robots.txt-Sperre tun Gegenteiliges und heben sich auf. Wollen Sie eine Seite loswerden, erlauben Sie das Crawlen, damit das noindex gesehen werden kann.

### Weiterleitungen und Statuscodes
Weiterleitungen sind die Stelle, an der Relaunches still Traffic verlieren. Die Fehler sind mechanisch und vor dem Start leicht zu testen.
| Seite dauerhaft verschoben | 301 auf die entsprechende Seite | 302, oder Weiterleitung auf die Startseite |
| Seite gelöscht, kein Äquivalent | 410 oder 404 | Soft 404: eine Nicht-gefunden-Seite mit Status 200 |
| Vorübergehend nicht verfügbar | 503 mit Retry-After | Status 200 mit einer Fehlermeldung |
| Varianten mit und ohne Schrägstrich | Eine kanonische Form, andere per 301 | Beide liefern denselben Inhalt mit 200 |
| Alte Domain | 301 Seite für Seite kartiert | Alles auf die neue Startseite |
| Weiterleitungsketten | Auf einen einzigen Sprung zusammenfassen | A → B → C → D, bei jedem Schritt Signalverlust |

### Blätterung, Facetten und Duplikate
Listenseiten erzeugen die größten Indexprobleme, denn eine Handvoll Filter kann tausende URL-Kombinationen hervorbringen, die alle wie Beinahe-Duplikate aussehen.
- Paginierte Seiten: echte crawlbare Links, jede Seite selbstkanonisch — kanonisieren Sie Seite 2 nicht auf Seite 1.
- Filterkombinationen: standardmäßig noindex, follow; indexieren Sie nur die wenigen, die echter Suchnachfrage entsprechen.
- Sortierreihenfolgen: erzeugen Sie nie eine neue indexierbare URL. Gleicher Inhalt, andere Abfolge.
- Sitzungskennungen und Tracking-Parameter: entfernen oder auf die saubere URL kanonisieren.
- Druckfreundliche und AMP-artige Duplikate: Canonical auf die Hauptversion.
- Produkte in mehreren Kategorien: eine kanonische URL, von allen verlinkt.
Offen gelassene Facettennavigation ist die häufigste Ursache für Index-Aufblähung, und sie baut sich langsam ab. Sie zur Bauzeit zu verhindern ist viel billiger, als sie danach zurückzudrehen.

### Strukturierte Daten und internationale Einrichtung
Zwei Bereiche, in denen ein mechanischer Fehler still die gesamte Funktion abschaltet.
| Article-Markup | Nur auf echten Artikeln, mit echten Daten | Erfundene Aktualisierungsdaten führen dazu, dass die Funktion ignoriert wird |
| Product-Markup | Preis und Verfügbarkeit müssen zur Seite passen | Abweichung löst eine manuelle Maßnahme aus |
| FAQ-Markup | Nur für Fragen, die auf der Seite sichtbar sind | Versteckter Inhalt ist ein Richtlinienverstoß |
| Brotkrumen | Müssen der sichtbaren Spur entsprechen | Abweichende Pfade werden schlicht ignoriert |
| hreflang | Reziprok auf jeder Seite der Gruppe | Einseitige Tags führen dazu, dass die ganze Gruppe verworfen wird |
| hreflang-Codes | Gleicher Code in HTML und Sitemap | Zwei verschiedene Codes für dieselbe Seite zerstören die Gruppe |
| x-default | Zeigt auf die Sprachauswahl oder die Standardversion | Fehlt es, verlieren Sie das Rückfallverhalten |

Q: Wie finde ich technische SEO-Probleme auf einer bestehenden Website?
A: Crawlen Sie sie mit einem Desktop-Crawler und vergleichen Sie das Ergebnis mit Ihrer Sitemap und mit der Abdeckung in der Search Console. Wo die drei Listen sich widersprechen, liegen die Probleme: URLs im Crawl, aber nicht in der Sitemap; URLs indexiert, aber nicht im Crawl; und Seiten, die aus Gründen ausgeschlossen sind, die Sie nicht beabsichtigt hatten.

Q: Sind Weiterleitungsketten wirklich wichtig?
A: Ja, aus zwei Gründen. Jeder Sprung erhöht die Latenz für echte Nutzer, und Crawler folgen nach einigen Sprüngen nicht mehr. Nach ein paar Migrationen findet man häufig vier oder fünf Ebenen tiefe Ketten, die niemand geplant hat. Fassen Sie sie zusammen, sodass jede alte URL in einem Sprung direkt auf das endgültige Ziel zeigt.

Q: Sollte ich Tag- und Kategorieseiten auf noindex setzen?
A: Nur wenn sie wirklich dünn sind. Eine Kategorieseite mit echter Beschreibung, einer kuratierten Liste und internen Links ist eine legitime Landingpage und oft eine starke. Eine Tag-Seite mit zwei Beiträgen und ohne Text ist Index-Aufblähung. Beurteilen Sie jedes Template danach, ob es eine Frage beantwortet, die jemand tatsächlich hat.

Q: Was zerstört hreflang am häufigsten?
A: Nicht reziproke Tags. Wenn die englische Seite die deutsche Alternative listet, die deutsche Seite aber nicht die englische, wird die Gruppe verworfen. Der zweithäufigste Fehler ist, im HTML einen Code und in der Sitemap einen anderen für dieselbe Seite anzugeben. Erzeugen Sie beides aus derselben Quelle, damit sie nicht auseinanderlaufen können.

## WordPress vs. Webflow vs. Individualentwicklung
https://websitedevelopment.biz/de/guides/wordpress-vs-webflow-vs-individuell
Aktualisiert am 2026-08-07 · CMS

Für eine Unternehmenswebsite laufen die meisten Entscheidungen auf diese drei hinaus. Sie sind nicht im geraden Sinn Konkurrenten — sie passen zu verschiedenen Teams, Budgets und zur unterschiedlichen Bereitschaft, Wartung zu tragen.

Dieser Leitfaden vergleicht sie nach Betriebsmodell, Dreijahreskosten und Ausstiegsschwierigkeit, denn das sind die Faktoren, die tatsächlich entscheiden, ob die Wahl aufgeht.

### Die drei in einer Tabelle
Die Zusammenfassung, vor dem Detail.
| Modell | Selbst gehostetes Open Source | Gehosteter visueller Baukasten | Ihr Code, Ihr Hosting |
| Bearbeiten | Gut, vielen vertraut | Hervorragende visuelle Kontrolle | So gut, wie Sie es bauen |
| Wer pflegt es | Sie | Der Anbieter | Sie |
| Erweiterbarkeit | Sehr großes Plugin-Ökosystem | Begrenzt, wird besser | Unbegrenzt |
| Performance | Hängt stark von der Umsetzung ab | Generell gut | So gut, wie Sie bezahlen |
| Laufende Kosten | Hosting plus Plugins plus Entwicklungszeit | Abo je Website | Hosting plus Entwicklungszeit |
| Ausstieg | Voller Datenbankzugriff | Export ist begrenzt und verlustbehaftet | Es ist Ihr Code |

### Wo jede wirklich stark ist
Nach der Stärke zu wählen, die zu Ihrer Situation passt, ist verlässlicher, als nach der Schwäche zu wählen, die Sie fürchten.
- WordPress: inhaltsgetriebene Websites, Blogs, Websites, die ein bestimmtes Plugin brauchen, Teams mit WordPress-Kenntnissen, und alles, wo ein großes Ökosystem Eigenentwicklung spart.
- Webflow: designgetriebene Marketing-Websites, bei denen visuelle Kontrolle zählt und niemand da ist, um Infrastruktur zu pflegen. Auch gut für Teams, die schnell Landingpages ausliefern müssen.
- Individuell: Anwendungen, ungewöhnliche Integrationen, strenge Performance- oder Barrierefreiheitsziele, oder eine Website, die selbst das Produkt ist.
Die häufigste Fehlpaarung ist ein kleines Team, das für eine Broschürenseite eine Individualentwicklung wählt. Technisch ist das nicht falsch; es ist schlicht Geld, das in Inhalte investiert mehr Ertrag brächte.

### Dreijahreskosten, ehrlich
Grobe Form statt präziser Zahlen, für eine mittelgroße Unternehmenswebsite.
| Umsetzung | Niedrig bis mittel | Niedrig bis mittel | Hoch |
| Hosting | Niedrig bis mittel | Im Abo enthalten | Niedrig bis mittel |
| Lizenzen und Plugins | Laufend, steigt mit der Zeit | Enthalten, nach Nutzung gestaffelt | Minimal |
| Wartung | Mittel, fortlaufend | Niedrig | Mittel |
| Entwicklungszeit für Änderungen | Niedrig für Inhalte, mittel für Funktionen | Niedrig | Mittel |
| Risikokosten | Kompromittierung, wenn ungepatcht | Preis- und Richtlinienänderungen des Anbieters | Abhängigkeit von einer Schlüsselperson |

### Ausstiegsschwierigkeit
Wie schwer der Ausstieg ist, gehört in die Entscheidung, denn er bestimmt, ob die Wahl umkehrbar ist.
- Individuell: im Prinzip am einfachsten — Sie haben Code, Datenbank und Hosting. Das Risiko sind die Dokumentation und die Frage, ob jemand anderes damit arbeiten kann.
- WordPress: unkompliziert. Inhalte exportieren sauber; die Arbeit besteht darin, nachzubauen, was Plugins getan haben.
- Webflow: am schwersten. Sie können statisches HTML und CSS exportieren, aber CMS-Inhalte, Formulare und Interaktionen kommen nicht mit, also ist der Ausstieg ein Neubau.
Stellen Sie die Ausstiegsfrage bei der Auswahl, nicht im Streitfall. Sie ist die billigste Frage und die teuerste, wenn man sie übersprungen hat.

Q: Welche ist am besten für SEO?
A: Alle drei können hervorragend sein, und alle drei können schlecht sein. Es kommt auf serverseitig gerendertes HTML an, auf Kontrolle über Titel und Canonicals, saubere URLs, Sitemaps, strukturierte Daten und Tempo. WordPress gibt Ihnen Plugins dafür, Webflow hat es mit einigen Grenzen eingebaut, individuell gibt volle Kontrolle und volle Verantwortung. Die Umsetzungsqualität dominiert die Plattformwahl.

Q: Ist WordPress unsicher?
A: Der WordPress-Kern wird aktiv gepflegt und ist einigermaßen sicher. Die meisten Kompromittierungen kommen von veralteten Plugins, aufgegebenen Themes und schwachen Admin-Zugangsdaten. Ein gepatchtes WordPress mit wenigen Plugins und Zwei-Faktor-Authentifizierung ist in Ordnung; eine Website mit vierzig Plugins, die niemand aktualisiert, nicht — und das ist eine Wartungsentscheidung, keine Eigenschaft der Plattform.

Q: Bewältigt Webflow eine große Website?
A: Es bewältigt mittelgroße Inhaltsseiten gut und hat Grenzen bei der Zahl der CMS-Einträge und der Struktur von Sammlungen, die sich vor der Festlegung mit Ihrem tatsächlichen Inhaltsmodell abgleichen lassen. Für einen großen, komplexen Katalog oder viel eigene Logik ist es meist das falsche Werkzeug — nicht weil es schwach wäre, sondern weil es darauf nicht zielt.

Q: Wann lohnt sich eine Individualentwicklung?
A: Wenn die Website etwas tut, das für Ihr Geschäft spezifisch ist und wogegen sich Standardwerkzeuge sperren: ein Konfigurator, ein ungewöhnlicher Buchungsablauf, tiefe Anbindung an Ihre operativen Systeme, oder strenge Anforderungen an Performance und Barrierefreiheit. Eigenständiges Design allein ist selten Grund genug, weil ein eigenes Theme auf einem CMS das für viel weniger erreicht.

## SEO-Grundlagen der Webentwicklung: Was in die Umsetzung gehört
https://websitedevelopment.biz/de/guides/webentwicklung-seo-grundlagen
Aktualisiert am 2026-08-07 · SEO

Ein großer Teil von SEO ist überhaupt kein Marketing — es sind Entscheidungen während der Webentwicklung, die zur Bauzeit billig und später teuer sind. URL-Struktur, Rendering-Strategie, interne Verlinkung und editierbare Metadaten fallen alle in diese Kategorie.

Dieser Leitfaden behandelt, was von Anfang an eingebaut gehört, grob in der Reihenfolge, wie schmerzhaft das Nachrüsten ist.

### Stellen Sie sicher, dass die Website gecrawlt und indexiert werden kann
Alles andere ist bedeutungslos, wenn Suchmaschinen Ihre Seiten nicht erreichen oder lesen können. Hier häufen sich auch die Fehler am Launch-Tag.
- Die robots.txt in der Produktion erlaubt das Crawlen. Die Staging-Kopie darf nicht mit ausgerollt werden.
- Keine versprengten noindex-Meta-Tags aus dem Staging übernommen.
- Jede Seite hat einen selbstreferenzierenden Canonical, und es gibt einen kanonischen Hostnamen.
- Der Inhalt steht im HTML oder wird serverseitig gerendert. Erscheint er erst, nachdem JavaScript gelaufen ist, wird die Indexierung langsamer und unzuverlässiger.
- Eine XML-Sitemap, die nur indexierbare, kanonische URLs listet — keine gefilterten oder paginierten Varianten.
- Jede indexierbare Seite hat mindestens einen internen Link. Verwaiste Seiten werden kaum gecrawlt.
- Einheitliche Statuscodes: 200 für echte Seiten, 404 für fehlende, 301 für verschobene.
Der mit Abstand häufigste Launch-Fehler in dieser Liste ist die Staging-robots.txt, die in die Produktion gelangt. Prüfen Sie sie am Launch-Tag von außerhalb Ihres Netzes.

### Struktur, die Suchmaschinen lesen können
Strukturelle Entscheidungen sind die, deren spätere Änderung schmerzt, denn ändern heißt Weiterleitungen und den Verlust angesammelter Signale.
| URL-Muster | Kurz, Kleinschreibung, Bindestriche, stabil | Hoch — Weiterleitungen und verlorene Signale |
| Überschriftenhierarchie | Eine H1, keine übersprungenen Ebenen | Niedrig |
| Interne Verlinkung | Hubs verlinken Detailseiten und zurück | Mittel |
| Blätterung | Crawlbare Links, nicht nur JavaScript | Mittel |
| Facettennavigation | noindex auf Filterkombinationen | Hoch — Index-Aufblähung baut sich langsam ab |
| Sprachversionen | Präfix-URLs plus reziprokes hreflang | Sehr hoch |

### Metadaten, die Ihr Team tatsächlich bearbeiten kann
Ein verbreiteter Umsetzungsfehler ist, Titel und Beschreibungen aus einer Vorlage zu erzeugen, ohne die Möglichkeit sie zu überschreiben. Sechs Monate später muss das Marketing den Titel einer Seite ändern, und die Antwort ist ein Entwicklungsticket.
- Editierbarer Title-Tag je Seite, mit sinnvollem erzeugtem Standard.
- Editierbare Meta-Beschreibung, mit sichtbarem Zeichenzähler im CMS.
- Editierbarer Open-Graph-Titel, -Beschreibung und -Bild für geteilte Links.
- Strukturierte Daten auf den Templates, die sie unterstützen: Article, Product, FAQ, Breadcrumb, Organization.
- Ein noindex-Schalter je Seite für Seiten, die existieren, aber nicht ranken sollen.
- Automatischer Canonical, mit manueller Überschreibung für den seltenen Fall, der eine braucht.
Zeichnen Sie nur aus, was auf der Seite tatsächlich sichtbar ist. Strukturierte Daten, die Inhalte beschreiben, die ein Besucher nicht sehen kann, sind ein Richtlinienverstoß, keine Abkürzung.

### Tempo und Stabilität als Anforderungen an die Umsetzung
Page Experience ist Teil der Umsetzung, kein späteres Optimierungsprojekt. Tempo auf eine fertige Website nachzurüsten bedeutet meist, Entscheidungen rückgängig zu machen statt Code hinzuzufügen.
| Largest Contentful Paint | Unter 2,5 s | Hero-Bild priorisieren, renderblockierende Assets vermeiden |
| Cumulative Layout Shift | Unter 0,1 | width und height an Bildern, reservierter Platz für Einbettungen |
| Interaction to Next Paint | Unter 200 ms | Weniger JavaScript und den Haupt-Thread nicht blockieren |
| Seitengewicht | So niedrig, wie das Design es erlaubt | Moderne Bildformate, keine ungenutzten Bibliotheken |
| Time to First Byte | Unter 800 ms | Caching, ein CDN und vernünftige Datenbankabfragen |

Q: Gehört SEO ins Entwicklungsbriefing?
A: Die technischen Teile ja — Crawlbarkeit, URL-Struktur, editierbare Metadaten, strukturierte Daten, Performance-Ziele und die Weiterleitungskarte. Content-Strategie und Linkaufbau sind getrennte Arbeit mit anderem Kompetenzprofil. Die technischen Anforderungen ins Briefing zu schreiben heißt, dass sie bepreist werden, statt nach dem Start entdeckt zu werden — dann kosten sie ein Vielfaches.

Q: Schadet ein JavaScript-Framework dem SEO?
A: Es kann, wenn Seiten nur im Browser gerendert werden. Suchmaschinen führen JavaScript aus, tun es aber verzögert und nicht immer vollständig, sodass reines Client-Rendering die Indexierung langsamer und unzuverlässiger macht. Serverseitiges Rendering oder statische Generierung beseitigt das Problem. Für eine Inhaltsseite lautet die einfachste Antwort meist: Inhalt ins HTML.

Q: Wie lange nach dem Start sehe ich Suchtraffic?
A: Bei einer brandneuen Domain typischerweise Wochen bis zur Indexierung und Monate bis zu nennenswerten Rankings — neue Websites ranken unabhängig von technischer Qualität nicht schnell. Bei einem Relaunch einer bestehenden Website mit sauberen Weiterleitungen rechnen Sie mit zwei bis sechs Wochen Schwankung, bis sich alles wieder um das vorherige Niveau einpendelt.

Q: Brauche ich ein SEO-Plugin?
A: Auf einem CMS ist ein Plugin ein bequemer Weg, Redakteuren Kontrolle über Titel, Beschreibungen, Canonicals und Sitemaps zu geben. Es ist keine Strategie, und seine Standardausgabe ersetzt nicht jemanden, der entscheidet, worum jede Seite gehen soll. Bei einer Individualentwicklung wird dieselbe Funktionalität meist direkt geschrieben und ist dadurch leichter.

## Headless CMS vs. traditionelles CMS: Was passt zu Ihrer Website?
https://websitedevelopment.biz/de/guides/headless-cms-vs-traditionelles-cms
Aktualisiert am 2026-08-07 · CMS

Ein traditionelles CMS speichert Inhalte und rendert die Seiten. Ein Headless CMS speichert Inhalte und gibt sie über eine API weiter, das Rendern überlässt es vollständig Ihnen. Dieser eine Unterschied wirkt sich auf alles aus: Vorschau, Kosten, Teamstruktur und wie schnell jemand aus dem Marketing eine Seite ändern kann.

Dieser Leitfaden behandelt, was Sie gewinnen, was Sie verlieren, und wo der Mittelweg liegt.

### Der eigentliche Unterschied
Alles andere folgt daraus, wo gerendert wird.
| Rendern | Das CMS erzeugt das HTML | Ihr Frontend |
| Templates | Im CMS | In Ihrer Codebasis |
| Vorschau | Eingebaut und genau | Müssen Sie bauen |
| Kanäle | Eine Website | Website, App, Kiosk, alles, was eine API aufrufen kann |
| Frontend-Freiheit | Vom CMS begrenzt | Vollständig |
| Zeit bis zur ersten Seite | Schnell | Langsam — nichts rendert, bevor Sie es bauen |
| Wer für eine Layoutänderung gebraucht wird | Oft die Redaktion | Die Entwicklung |

### Was Sie mit headless aufgeben
Die Funktionen, die ein traditionelles CMS gratis mitbringt, sind die, die man vermisst — und man entdeckt sie meist nach der Entscheidung.
- Vorschau. Redaktionen erwarten, die Seite vor dem Veröffentlichen zu sehen. Bei headless ist das eine Funktion, die Sie bauen und pflegen.
- Seitenkomposition. Blöcke auf einer Seite anzuordnen ist in traditionellen Systemen gelöst und in headless ein Bauvorhaben.
- Menüs und Navigation. Ebenfalls etwas, das Sie nun selbst modellieren und bauen.
- Formulare. Mit der API kommt kein Formularbaukasten.
- Weiterleitungen und URL-Verwaltung. Ihre Aufgabe.
- Plugin-Ökosystem. SEO-Felder, Sitemaps, Weiterleitungen — alles wird Eigenentwicklung.
- Tempo kleiner Änderungen. „Diesen Abschnitt nach oben" ist keine Redaktionsaufgabe mehr.
Das wiederkehrende Muster enttäuschender Headless-Projekte ist ein Marketingteam, das früher selbst eine Seite ändern konnte und jetzt Tickets schreibt.

### Wann headless die richtige Wahl ist
Es passt zu einer bestimmten Problemform, und außerhalb davon ist es teure Flexibilität.
| Inhalte in Website und mobiler App | Stark — das ist der Kernfall |
| Mehrere Websites mit einer Inhaltsquelle | Stark |
| Frontend-Anforderungen, die das CMS nicht erfüllen kann | Stark |
| Ein eigenes Frontend-Team existiert bereits | Gut |
| Marketing-Website mit kleinem Team | Schlecht — Sie verlieren Tempo und gewinnen Tickets |
| Inhaltsgetriebene Website mit häufigen Layoutänderungen | Schlecht |
| „Es ist der moderne Ansatz" | Kein Grund |

### Der Mittelweg
Den meisten Websites ist mit etwas zwischen den Extremen besser gedient.
- Traditionelles CMS mit eigenem Theme. Volle Frontend-Kontrolle, und Vorschau und Komposition funktionieren weiter.
- Traditionelles CMS, headless genutzt für eine Oberfläche. Die Website bleibt vom CMS gerendert; die App nutzt eine API.
- Headless CMS mit statischem Generator. Die Redaktion bekommt eine gute Oberfläche, die Website ist statisch und schnell; die Vorschau braucht Arbeit.
- Hybrides CMS. Systeme, die gerenderte Seiten und eine API bieten — oft die pragmatische Antwort.
- Statischer Generator mit git-basiertem Editor. Sehr niedrige Kosten und sehr niedriges Risiko für Inhalte, die überwiegend Dokumente sind.
Ein eigenes Theme auf einem traditionellen CMS gibt Ihnen den größten Teil der Frontend-Freiheit, wegen der Menschen headless gehen — ohne Vorschau, Komposition und Ökosystem aufzugeben.

Q: Ist headless besser für die Performance?
A: Es kann sein, weil Sie genau kontrollieren, was gesendet wird — aber der Gewinn kommt von statischer Generierung und einem schlanken Frontend, nicht von der API. Ein gut gebautes traditionelles CMS mit ordentlichem Caching und eigenem Theme ist ebenfalls schnell. Performance ist eine Folge der Bauweise, nicht des Speicherorts der Inhalte.

Q: Ist headless besser für SEO?
A: Bestenfalls neutral und schlechter, wenn Seiten nur im Browser rendern. Alles, was technisches SEO braucht — serverseitig gerendertes HTML, Canonicals, Sitemaps, strukturierte Daten, Weiterleitungen —, müssen Sie bei headless selbst umsetzen, während traditionelle Systeme reife Plugins dafür haben. Headless ist mit Disziplin in Ordnung und ohne sie enttäuschend.

Q: Können Redaktionen bei headless eine Vorschau sehen?
A: Ja, aber Sie bauen sie: einen Vorschaumodus im Frontend, der Entwurfsinhalte holt und rendert. Planen Sie das ausdrücklich ein. Projekte, die die Vorschau auslassen, enden damit, dass Redaktionen in die Produktion veröffentlichen, um zu sehen, wie etwas aussieht — genau das, was ein CMS verhindern soll.

Q: Was kostet headless im Vergleich zu traditionell?
A: Die Erstumsetzung ist typischerweise höher, weil Sie das Frontend plus die Funktionen bauen, die ein traditionelles CMS enthielt. Die laufenden Kosten können niedriger sein, besonders mit statischer Generierung. Der größere langfristige Unterschied ist, dass mehr Routineänderungen Entwicklungszeit brauchen — ein fortlaufender Posten, der im Angebot nicht auftaucht.

## Brauchen Sie ein Designsystem für Ihre Website?
https://websitedevelopment.biz/de/guides/designsystem-fuer-websites
Aktualisiert am 2026-08-07 · Webdesign

Ein Designsystem ist ein Satz wiederverwendbarer Komponenten und die Regeln für ihren Einsatz. Auf einer großen Website, an der mehrere Personen Änderungen vornehmen, erspart es sehr viel doppelte Entscheidungsarbeit. Auf einer fünfseitigen Broschürenseite ist es ein Kostenpunkt ohne Gegenwert.

Dieser Leitfaden behandelt, wo die Grenze verläuft, was ein minimal nützliches System tatsächlich enthält, und was man stattdessen tut, wenn ein vollständiges System nicht gerechtfertigt ist.

### Wann es sich rechnet und wann nicht
Der Wert entsteht aus Wiederholung: dieselbe Entscheidung einmal statt vierzigmal, und konsistent. Fehlt die Wiederholung, fehlt auch der Wert.
| Fünfseitige Broschürenseite, eine Designerin, seltene Änderungen | Nein — eine Styleguide-Seite genügt |
| Eine Website, mehrere Templates, gelegentliche Inhaltsänderungen | Leicht: Tokens und ein Komponentenblatt |
| Website plus App mit gemeinsamer Marke | Ja — die gemeinsame Fläche ist, wo Drift entsteht |
| Mehrere Websites in einer Organisation | Ja — das ist der stärkste Fall |
| Häufige A/B-Tests und Kampagnenseiten | Ja — die Geschwindigkeit beim Zusammenbau ist der Gewinn |
| Neubau innerhalb eines Jahres geplant | Noch nicht — bauen Sie das System mit dem Neubau |

### Das minimal nützliche System
Der Großteil des Nutzens kommt aus einem kleinen Kern. Sie bauen das in Tagen statt Monaten, und es genügt für die meisten Websites, die überhaupt eines brauchen.
- Tokens: Farbe, Typo-Skala, Abstandsskala, Radien, Schatten, Breakpoints — benannt, keine fest verdrahteten Zahlen.
- Typografie: Überschriftenebenen und Fließtextstile mit ihrem responsiven Verhalten.
- Buttons und Links: jeder Zustand — Standard, Hover, Fokus, Aktiv, Deaktiviert, Ladend.
- Formularelemente: input, select, textarea, Checkbox, Radio, plus Fehler- und Hinweisstile.
- Karten und Listen: die zwei oder drei wiederkehrenden Inhaltscontainer, die Ihre Website tatsächlich nutzt.
- Navigation: Kopfbereich, Fußbereich, Brotkrumen, Blätterung.
- Rückmeldung: Leerzustand, Fehlerzustand, Ladezustand, Erfolgsmeldung.
Zustände sind der Teil, der übersprungen wird, und der Teil, auf den es am meisten ankommt. Eine Komponente, die nur im Standardzustand definiert ist, gibt jeden Sonderfall an denjenigen zurück, der sie umsetzt.

### Die Pflegekosten, die niemand einplant
Ein Designsystem ist ein Produkt mit Nutzern und braucht einen Eigentümer. Ohne einen driftet es: Die Website bekommt Komponenten, die das System nicht hat, das System behält Komponenten, die niemand nutzt, und nach einem Jahr arbeiten die Leute daran vorbei statt damit.
- Jemand verantwortet es und entscheidet, was hineinkommt. Ein von einem Gremium verantwortetes System hört auf, sich zu verändern.
- Ein dokumentierter Weg, eine neue Komponente vorzuschlagen, damit Leute es erweitern statt umgehen.
- Versionierung, damit eine Änderung nicht still jede Seite auf einmal verändert.
- Ein regelmäßiges Audit dessen, was in der Live-Website steckt, aber nicht im System — diese Lücke ist das Gesundheitsmaß.
- Löschen. Ungenutzte Komponenten sind Kosten, kein Wert.

### Leichtere Alternativen
Fehlt der Grund für ein vollständiges System, gibt es günstigere Schritte, die viel vom Konsistenznutzen einfangen.
| CSS-Custom-Properties für Farbe, Typo und Abstände | Stunden | Jede Website überhaupt — das ist die Untergrenze |
| Eine einzelne Live-Styleguide-Seite in der Website selbst | Ein Tag | Kleine Websites mit gelegentlichen Mitwirkenden |
| Komponentenbibliothek im CMS oder in der Template-Schicht | Tage | Redaktionsteams, die Seiten zusammenstellen |
| Etabliertes CSS-Framework, leicht angepasst | Tage | Interne Werkzeuge und Admin-Oberflächen |
| Vollständig dokumentiertes Designsystem | Wochen bis Monate | Mehrere Produkte oder mehrere Teams |
Eine Live-Styleguide-Seite in der echten Website schlägt ein Dokument: Sie nutzt dasselbe CSS, kann also nicht von der Realität abweichen, ohne sichtbar kaputtzugehen.

Q: Kann ich ein fertiges Designsystem verwenden?
A: Ja, und für interne Werkzeuge ist es meist die richtige Wahl — das Branding zählt wenig und Sie bekommen sofort barrierefreie, getestete Komponenten. Für eine öffentliche Marketing-Website ist der Handel, dass Ihre Website aussieht wie jede andere mit demselben System, weshalb die meisten Organisationen stark umgestalten — und damit ein Teil der Pflegeersparnis verschwindet.

Q: Wer sollte das Designsystem verantworten?
A: Eine benannte Person, mit Input von Design und Entwicklung. Geteilte Verantwortung zwischen Design und Technik klingt kollaborativ und bedeutet in der Praxis, dass niemand entscheidet, sodass das System aufhört sich zu entwickeln und die Leute daran vorbei arbeiten. Der Eigentümer muss nicht alles bauen; er muss Ja und Nein sagen.

Q: Was ist der Unterschied zwischen Styleguide und Designsystem?
A: Ein Styleguide dokumentiert Erscheinung: Farben, Schriften, Logo-Verwendung. Ein Designsystem enthält das plus funktionierende Komponenten, ihre Zustände, die Regeln für ihre Kombination und meist den Code. Ein Styleguide sagt Ihnen, wie Dinge aussehen; ein Designsystem gibt Ihnen die Teile und sagt, wann welches zu benutzen ist.

Q: Wie verhindere ich, dass es veraltet?
A: Machen Sie es zum Weg des geringsten Widerstands und auditieren Sie die Lücke. Ist das System langsamer als eigenes CSS zu schreiben, schreiben die Leute eigenes CSS. Listen Sie regelmäßig die Komponenten in der Live-Website auf, die nicht im System sind: Eine wachsende Liste bedeutet, dass das System denen nicht dient, die Seiten bauen, und das ist ein Designproblem des Systems selbst.

## Webentwickler werden: Ein realistischer Weg
https://websitedevelopment.biz/de/guides/webentwickler-werden
Aktualisiert am 2026-08-07 · Entwickler finden

Webentwicklerin zu werden bedeutet, eine bestimmte, endliche Menge Dinge zu lernen und dann zu beweisen, dass man Arbeit zu Ende bringt. Das Lernen ist gut dokumentiert und kostenlos; der schwerere Teil ist, Belege dafür aufzubauen, dass jemand Sie bezahlen sollte.

Dieser Leitfaden behandelt eine realistische Lernreihenfolge, ehrliche Zeiträume, was ein Portfolio wirklich braucht, und wie erste Kunden gefunden werden.

### Was zu lernen ist, der Reihe nach
Die Reihenfolge zählt mehr als das Tempo. Jede Schicht macht die nächste verständlich, und vorzugreifen erzeugt Entwicklerinnen, die Lösungen kopieren, aber Probleme nicht diagnostizieren können.
- HTML, richtig. Semantik, Formulare, Barrierefreiheit. Die meisten professionellen Entwicklerinnen haben hier Lücken, und man sieht es an ihrer Arbeit.
- CSS, richtig. Boxmodell, Flexbox, Grid, Custom Properties, responsives Layout. Hier wird man als Anfängerin am schnellsten wirklich nützlich.
- JavaScript-Grundlagen. Die Sprache selbst und das DOM, vor jedem Framework.
- Versionskontrolle. Git, Branches, Pull Requests. Nicht verhandelbar, wenn man mit anderen arbeitet.
- Wie das Web funktioniert. HTTP, Statuscodes, Caching, DNS, TLS. Das trennt Diagnose vom Raten.
- Eine Backend-Sprache und SQL. Irgendeine der verbreiteten; die Konzepte übertragen sich.
- Ein CMS oder ein Framework, gewählt danach, welche Arbeit es in Ihrer Nähe gibt.
- Deployment. Eine Website auf echtes Hosting bringen, mit Domain und Zertifikat.
Tiefe in HTML und CSS ist unterschätzt und sofort marktfähig. Wer schnelle, barrierefreie, responsive Oberflächen bauen kann, ist gefragter als jemand, der drei Frameworks oberflächlich kennt.

### Wie lange es tatsächlich dauert
Bei beständigem Lernen von 15–20 Stunden pro Woche. Vollzeit staucht das zusammen, und nichts staucht die letzte Zeile.
| Grundlagen von HTML und CSS | 1–2 Monate | Eine statische Seite aus einem Design bauen |
| Responsives Layout und JavaScript-Grundlagen | 3–5 Monate | Eine kleine Website mit Interaktion bauen |
| Erstes echtes Projekt | 5–8 Monate | Etwas für jemand anderen ausliefern |
| Einstellbare Junior-Kraft | 8–14 Monate | Unter Anleitung zu einer Codebasis beitragen |
| Selbstständig arbeiten | 2–3 Jahre | Ein kleines Projekt von Anfang bis Ende führen |
| Senior | 5+ Jahre | Architekturentscheidungen treffen und oft richtig liegen |
Den Schritt, den Menschen unterschätzen, ist „etwas für jemand anderen ausliefern". Für sich selbst zu bauen lehrt Syntax; für eine Kundin zu bauen lehrt Umfang, Feedback, Termine und die Tatsache, dass sich Anforderungen ändern.

### Was ein Portfolio zeigen muss
Drei oder vier fertige, live erreichbare, gut erklärte Projekte schlagen zwanzig Tutorial-Nachbauten. Beurteilt wird, ob Sie Dinge zu Ende bringen und ob Sie verstehen, was Sie gebaut haben.
- Live-URLs, keine Screenshots. Es muss funktionieren, wenn jemand klickt.
- Ein kurzer Text je Projekt: das Problem, Ihre Entscheidungen, was Sie anders machen würden.
- Mindestens ein echtes Projekt mit einer echten Nutzerin, auch unbezahlt — ein lokaler Betrieb, ein Verein, eine gemeinnützige Organisation.
- Belege für Qualität: schnell, barrierefrei, funktioniert am Handy. Die Leute prüfen das.
- Ihre eigene Website, gut gemacht. Sie ist das Erste, was jemand ansieht, und das Einfachste, das man richtig machen kann.
- Code in einem öffentlichen Repository mit lesbaren Commits und einer README, die erklärt, wie man es startet.

### Die ersten Kunden finden
Die ersten zwei oder drei sind die schwierigen. Danach kommt die meiste Arbeit über Empfehlung, was bedeutet: gut abzuschließen zählt mehr als Marketing.
- Fangen Sie bei Menschen an, die Sie kennen. Fast jede erste bezahlte Arbeit kam so zustande.
- Wählen Sie eine Nische statt allgemein zu bleiben. „Websites für Zahnarztpraxen" verkauft sich weit leichter als „Websites".
- Lösen Sie ein konkretes teures Problem — Website-Tempo, ein Barrierefreiheits-Audit, eine Migration — statt alles anzubieten.
- Nehmen Sie ab dem ersten Projekt Geld, auch wenig. Kostenlose Arbeit wird entsprechend geschätzt und zieht unbegrenzten Umfang an.
- Halten Sie Umfang und Zahlungsbedingungen vor Beginn schriftlich fest, so klein der Auftrag auch ist.
- Schließen Sie ordentlich ab: Übergabe, Dokumentation, ein Wartungsangebot. Das bringt die zweite Kundin.
- Bitten Sie um eine Empfehlung, wenn die Kundin am zufriedensten ist — direkt nach dem Start.

Q: Brauche ich ein Informatikstudium?
A: Nein, und ein großer Teil der arbeitenden Webentwicklerinnen hat keines. Ein Abschluss hilft in manchen großen Organisationen und bei Rollen, die näher an Informatik als an Webentwicklung liegen. Für die meiste Website-Arbeit zählen Belege fertiger Projekte mehr als Abschlüsse — aber Sie brauchen die Grundlagen, die ein Studium gegeben hätte, auf anderem Weg gelernt.

Q: Frontend oder Backend zuerst?
A: Frontend, in nahezu jedem Fall. Sie sehen sofort Ergebnisse, was die Motivation trägt, und es ist der kürzeste Weg, für jemanden nützlich zu sein. Wenn Sie Oberflächen richtig bauen können, sind Backend-Konzepte leichter zu lernen, weil Sie bereits verstehen, wofür die Daten da sind.

Q: Ist es zu spät anzufangen?
A: Nein, und Quereinsteigerinnen sind häufig erfolgreich, weil sie Fachwissen mitbringen, das anderen fehlt — Buchhalterinnen, die für Buchhalter bauen, Lehrkräfte, die für Schulen bauen. Der Markt für Junior-Generalistinnen ist umkämpft; der Markt für jemanden, der eine bestimmte Branche versteht und bauen kann, weit weniger.

Q: Sollte ich früh ein Framework lernen?
A: Lernen Sie zuerst die Grundlagen. Frameworks wechseln alle paar Jahre und sind viel leichter aufzunehmen, wenn Sie verstehen, was sie abstrahieren. Wer ein Framework ohne die zugrundeliegende Sprache gelernt hat, ist innerhalb seiner Muster wirksam und außerhalb festgefahren — und diese Grenze kommt schnell.

## Was ist ein CMS und brauchen Sie wirklich eines?
https://websitedevelopment.biz/de/guides/was-ist-ein-cms
Aktualisiert am 2026-08-07 · CMS

Ein Content-Management-System lässt Menschen, die keinen Code schreiben, Seiten anlegen und ändern. Das ist das ganze Wertversprechen, und es ist ein echtes — aber es ist nicht kostenlos, denn ein CMS ist Software, die gehostet, aktualisiert und abgesichert werden muss, solange die Website existiert.

Dieser Leitfaden behandelt, was ein CMS Ihnen tatsächlich gibt, wann es den Aufwand wert ist, und was man sonst nutzt.

### Was ein CMS bietet
Über „Seiten bearbeiten" hinaus sind das die Fähigkeiten, die Sie kaufen — und es lohnt sich, sie aufzulisten, denn die meisten CMS-Entscheidungen fallen, ohne zu prüfen, welche davon Sie brauchen.
- Bearbeiten ohne Deployment. Text ändern und sofort veröffentlichen.
- Strukturierte Inhalte. Felder statt eines HTML-Klumpens, sodass Inhalte wiederverwendet und einheitlich ausgegeben werden können.
- Medienverwaltung. Einmal hochladen, überall nutzen, mit automatischer Größenanpassung.
- Nutzer und Rechte. Autorinnen, Redakteure, Freigebende mit unterschiedlichen Rechten.
- Arbeitsabläufe. Entwürfe, Vorschauen, Terminierung, Versionsverlauf.
- Suche und Navigation, automatisch aus den Inhalten erzeugt.
- Erweiterbarkeit. Formulare, Handel, Übersetzungen über ein Ökosystem.
Wenn Sie nur den ersten Punkt dieser Liste brauchen und eine Person zweimal im Jahr etwas ändert, ist ein CMS sehr viel Maschinerie für eine kleine Aufgabe.

### Der Aufwand, den anfangs niemand erwähnt
Ein CMS ist eine laufende Anwendung, hat also ein fortlaufendes Kostenprofil, ob jemand die Website bearbeitet oder nicht.
| Sicherheitspatches | Verbreitete Systeme werden ständig abgetastet; Updates sind nicht optional |
| Plugin-Pflege | Jede Erweiterung ist ein weiteres Update und eine weitere mögliche Lücke |
| Hosting | Eine datenbankgestützte Anwendung braucht mehr als statische Dateien |
| Performance-Arbeit | Dynamische Seiten brauchen Caching, um schnell zu sein |
| Versions-Upgrades | Hauptversionen können Themes und Anpassungen brechen |
| Schulung | Redaktionen müssen wissen, wie sie es nutzen, ohne Layouts zu zerstören |

### Wann Sie eines brauchen und wann nicht
Ausschlaggebend ist die Änderungshäufigkeit multipliziert mit der Zahl der Menschen, die Änderungen vornehmen müssen.
| Marketingteam veröffentlicht wöchentlich | Ja — genau dafür ist ein CMS da |
| Fünfseitige Website, zweimal im Jahr geändert | Nein — eine statische Website ist billiger und sicherer |
| Dokumentation, von der Entwicklung gepflegt | Nein — Dateien in der Versionskontrolle funktionieren besser |
| Onlineshop | Ja, und eher eine Commerce-Plattform als ein allgemeines CMS |
| Landingpages für Kampagnen | Ja — Veröffentlichungstempo ist der ganze Zweck |
| Website mit mehreren Inhaltstypen und Übersetzungen | Ja — Struktur ist das, was ein CMS gut kann |

### Die Alternativen
Für Websites, die sich selten ändern, gibt es Optionen mit weit niedrigeren laufenden Kosten und nahezu keiner Angriffsfläche.
- Statischer Website-Generator. Inhalte in Dateien, zu HTML gebaut, auf ein CDN ausgeliefert. Schnell, billig und fast nichts zum Angreifen — aber das Bearbeiten braucht einen technischen Ablauf, sofern Sie keine Bearbeitungsschicht ergänzen.
- Statischer Generator plus git-basierter Editor. Nicht-technisches Bearbeiten auf Dateien, bei erhaltener statischer Ausgabe.
- Headless CMS plus statische Generierung. Die Redaktion bekommt eine freundliche Oberfläche; die öffentliche Website bleibt statisch.
- Handgeschriebenes HTML. Völlig vernünftig für eine kleine Broschürenseite, die sich wirklich nie ändert.
- Website-Baukasten. Das Bearbeiten ist das Produkt; der Handel ist Portierbarkeit und Performance.
Der statische Weg beseitigt eine ganze Risikokategorie: Es gibt keine Datenbank, in die man injizieren, und kein Admin-Login, das man durchprobieren könnte. Für eine Website, die sich monatlich ändert, ist das eine spürbare Ersparnis.

Q: Ist WordPress die Standardwahl?
A: Es ist die häufigste, und Verbreitung bringt ein großes Ökosystem, viele Menschen, die es kennen, und entsprechend viel automatisierte Aufmerksamkeit von Angreifern. Es passt gut zu inhaltsgetriebenen Websites. Es ist nicht automatisch richtig für Anwendungen, komplexen Handel oder Websites, deren Inhalt überwiegend strukturierte Daten statt Seiten sind.

Q: Was ist der Unterschied zwischen einem CMS und einem Website-Baukasten?
A: Ein CMS verwaltet Inhalte und überlässt die Darstellung meist Templates, die Sie oder Ihre Entwicklung kontrollieren. Ein Baukasten verbindet Inhalt und Layout in einem visuellen Werkzeug. Baukästen sind für Nicht-Technische schneller und schwerer zu verlassen, weil Layoutentscheidungen im Produkt liegen statt in Code, der Ihnen gehört.

Q: Kann ich einer bestehenden statischen Website ein CMS hinzufügen?
A: Ja, und es ist ein verbreiteter Ausbauweg — entweder ein Headless CMS, das die bestehenden Templates mit Inhalten versorgt, oder eine git-basierte Bearbeitungsschicht über den aktuellen Dateien. Es ist meist weniger Arbeit als eine vollständige Migration, weil Templates und URLs bleiben, wo sie sind.

Q: Wie viele Plugins sind zu viele?
A: Es gibt keine feste Zahl, aber jedes Plugin ist ein einzuspielendes Update, ein möglicher Konflikt und eine mögliche Schwachstelle. Eine nützliche Disziplin ist, jedes gegen seinen Nutzen zu rechtfertigen: Spart es eine Stunde im Jahr und braucht vierteljährliche Aufmerksamkeit, kostet es Sie. Websites mit vierzig Plugins tragen fast immer mehrere mit, die niemand erklären kann.

## Fragen an eine Webentwicklerin vor der Beauftragung
https://websitedevelopment.biz/de/guides/fragen-an-webentwickler
Aktualisiert am 2026-08-07 · Entwickler finden

Die meisten Fragen im ersten Gespräch drehen sich um Technologie, und Technologie ist der Teil, der für den Projekterfolg am wenigsten zählt. Die Fragen, die Ergebnisse vorhersagen, drehen sich um Prozess, Eigentum und darum, was passiert, wenn etwas schiefgeht.

Dieser Leitfaden listet diese Fragen, gruppiert nach dem, was sie verraten, mit einem Hinweis, wie eine gute Antwort klingt.

### Zur Arbeit selbst
Diese klären, ob sie Ihr Projekt verstanden haben oder ihr Standardangebot beschreiben.
| Welche Fragen haben Sie zu unserem Geschäft? | Überhaupt welche. Schweigen hier ist das stärkste negative Signal, das es gibt |
| Zeigen Sie mir eine Live-Website in unserer Größenordnung | Eine URL, kein Bild; idealerweise nicht ihr Vorzeigestück |
| Was würden Sie an unserer jetzigen Website anders machen? | Konkrete Beobachtungen, also haben sie hingeschaut |
| Was ist der riskanteste Teil dieses Projekts? | Eine ehrliche Antwort — meist Inhalte oder Integrationen |
| Was ist in diesem Angebot nicht enthalten? | Eine konkrete Liste, bereitwillig gegeben |
| Wie lange, und was treibt das? | Ein Zeitplan mit Abhängigkeiten, keine einzelne Zahl |

### Zum Prozess
Diese trennen Entwicklerinnen mit einer wiederholbaren Arbeitsweise von denen, die improvisieren.
- Wo liegt der Code, und haben wir ab Tag eins Zugriff?
- Wie kommt eine Änderung von Ihrer Maschine auf die Live-Website?
- Wo nehmen wir Arbeit ab, bevor sie live geht?
- Wie oft sehen wir Fortschritt, und in welcher Form?
- Wer genau macht die Arbeit, und was passiert, wenn diese Person nicht verfügbar ist?
- Wie testen Sie — Browser, Geräte, Barrierefreiheit, Performance?
- Was brauchen Sie von uns, und bis wann?
Die Deployment-Frage ist die aufschlussreichste. Eine Antwort, in der Dateien in einen FTP-Client gezogen werden, sagt Ihnen: keine Versionskontrolle, kein Staging, kein Zurückrollen.

### Dazu, was danach passiert
Der Zeitraum, nach dem in der Präsentation niemand fragt und der sechs Monate später alle interessiert.
- Wem gehören Code, Domain und Hosting-Konten nach dem Start?
- Welcher Support ist nach dem Start enthalten, wie lange, und was zählt als Mangel?
- Was kostet danach eine kleine Änderung, und wie lange dauert sie?
- Bieten Sie Wartung an, was ist darin enthalten, und bekommen wir einen Bericht?
- Wenn wir die Zusammenarbeit beenden, was erhalten wir und wie schnell?
- Kann eine andere Entwicklerin das übernehmen? Welche Dokumentation existiert?
- Von welchen Drittanbieterdiensten wird die Website abhängen, und wer bezahlt sie?

### Antworten, die das Gespräch beenden sollten
Selten, aber sofort erkennbar.
| „Wir garantieren Platzierungen auf Seite eins" | Niemand kann das; es ist entweder Unkenntnis oder Unehrlichkeit |
| „Die Domain behalten wir in unserem Konto" | Das macht Sie zur Geisel |
| „Sie brauchen kein Staging, wir sind sorgfältig" | Alle sind sorgfältig; das ist kein Prozess |
| „Bei kleinen Websites nutzen wir keine Versionskontrolle" | Keine Historie, kein Zurückrollen, keine zweite Person |
| „Der Preis gilt nur, wenn Sie heute unterschreiben" | Drucktaktiken sagen die Zusammenarbeit voraus |
| „SEO ist enthalten" ohne Details | Entweder bedeutungslos oder es wird eine Zusatzleistung angedeutet |
| „Die Details klären wir unterwegs" | Bei einem Festpreis wird das Ihr Problem |

Q: Was ist die nützlichste einzelne Frage?
A: „Wie kommt eine Änderung von Ihrer Maschine auf die Live-Website?" Jede kompetente Person beantwortet sie in einem Satz, und die Antwort verrät, ob Versionskontrolle, Staging, Abnahme und Zurückrollen existieren. Alles andere auf der Prozessliste folgt daraus meist in die eine oder andere Richtung.

Q: Sollte ich nach bestimmten Technologien fragen?
A: Nur wo Sie eine echte Randbedingung haben — ein bestehendes System, eine Plattform, die Ihr Team schon betreibt. Sonst ist die Technologie deren Entscheidung, und danach zu fragen lädt zu einer Antwort ein, die beeindrucken soll. Fragen Sie nach den Ergebnissen: wie schnell, wie wartbar, wer sonst damit arbeiten könnte.

Q: Wie prüfe ich eine Referenz richtig?
A: Fragen Sie nach einem Problem statt nach Zufriedenheit: „Was ging schief, und wie sind sie damit umgegangen?" Jedes Projekt hat etwas. Eine Referenz, die nichts nennen kann, hatte entweder ein triviales Projekt oder ist nicht offen. Fragen Sie außerdem, ob sie sie für ein größeres Projekt wieder beauftragen würden — eine schärfere Frage als die nach der Zufriedenheit.

Q: Ist es unhöflich, nach Eigentum und Kündigung zu fragen?
A: Nein, und ein professioneller Lieferant erwartet es. Beide Seiten profitieren davon zu wissen, woran sie sind, und die Antworten sind kurz. Unbehagen bei diesen Fragen ist selbst eine Information — meist heißt es, die übliche Regelung ist für Sie ungünstiger, als sie sein sollte.

## Barrierefreiheit von Websites: Was zuerst zu beheben ist
https://websitedevelopment.biz/de/guides/website-barrierefreiheit-leitfaden
Aktualisiert am 2026-08-07 · Webdesign

Barrierefreiheitsarbeit hat eine lange Checkliste und eine kurze Liste von Dingen, die den Großteil der tatsächlichen Barrieren ausmachen. Mit der kurzen Liste zu beginnen bringt echte Nutzer schnell auf Ihre Website; mit einem vollständigen Audit zu beginnen erzeugt meist ein Dokument, das niemand abarbeitet.

Dieser Leitfaden behandelt, was zuerst zu beheben ist, wie Sie es an einem Nachmittag selbst testen, und warum Overlay-Widgets nicht die Abkürzung sind, als die sie verkauft werden.

### Die Korrekturen mit der größten Wirkung
Das sind die Barrieren, die Menschen ganz daran hindern, Aufgaben zu erledigen, statt sie nur etwas zu erschweren. Beheben Sie sie vor allem, was auf einer längeren Liste steht.
- Tastaturzugang. Jedes interaktive Element mit Tab erreichbar und mit Enter oder Leertaste bedienbar, in sinnvoller Reihenfolge, mit sichtbarem Fokusring. Wenn die Website nur mit der Maus nutzbar ist, spielt nichts anderes auf dieser Liste eine Rolle.
- Textalternativen. Sinnvoller Alt-Text bei Bildern, die Information tragen; leeres alt bei dekorativen. Ein fehlendes alt ist nicht dasselbe wie ein leeres.
- Formularbeschriftungen. Ein echtes <label>, das mit jedem Eingabefeld verbunden ist. Platzhaltertext ist keine Beschriftung — er verschwindet beim Tippen und wird nicht zuverlässig vorgelesen.
- Kontrast. Fließtext bei 4,5:1, großer Text und Bedienelemente bei 3:1, geprüft gegen den echten Hintergrund.
- Überschriften. Eine H1, keine übersprungenen Ebenen. Screenreader-Nutzer navigieren mehr über Überschriften als über alles andere.
- Linktexte. Vierzehnmal „Mehr lesen“ gibt einem Screenreader-Nutzer vierzehn identische Ziele. Sagen Sie, wohin es führt.
- Fehlermeldungen. Neben dem Feld, als Text, mit der Beschreibung, was zu tun ist — nicht nur Farbe, nicht nur ein roter Rahmen.

### Testen Sie selbst an einem Nachmittag
Sie brauchen keine Spezialsoftware, um die meisten Probleme zu finden. Diese fünf Durchgänge dauern auf einer mittelgroßen Website ein bis zwei Stunden und finden den Großteil der echten Barrieren.
| Nur Tastatur | Maus abziehen, mit Tab durch jede Seite | Fallen, unsichtbarer Fokus, unerreichbare Bedienelemente |
| Zoom auf 200 % | Browser-Textgröße, nicht Seitenzoom | Abgeschnittener Text, horizontales Scrollen, kaputte Layouts |
| Screenreader | VoiceOver oder NVDA auf den Haupt-Templates | Fehlende Beschriftungen, nichtssagende Links, unangekündigte Änderungen |
| Automatischer Scan | axe oder Lighthouse im Browser | Kontrast, fehlendes alt, ARIA-Fehlgebrauch — etwa 30 % der Probleme |
| Graustufen | Browser-Filter oder Systemeinstellung | Alles, was allein über Farbe vermittelt wird |
Automatische Werkzeuge finden ungefähr ein Drittel der Barrierefreiheitsprobleme. Sie sind ein Ausgangspunkt, keine Bestehensnote — eine Website mit 100 in Lighthouse kann per Tastatur trotzdem unbenutzbar sein.

### Die Muster, die den meisten Ärger machen
Eigene Komponenten sind der Ort, an dem Barrierefreiheit meist bricht, denn native Elemente bringen Verhalten mit, das eigene nachbauen müssen.
- Eigene Dropdowns aus divs, ohne Tastaturunterstützung oder Rollen. Ein natives <select> ist gratis und funktioniert überall.
- Modale Dialoge, die den Fokus nicht einfangen, bei Escape nicht schließen und den Hintergrund scrollbar lassen.
- Karussells, die automatisch weiterlaufen ohne Pause-Bedienelement — sie sind nahezu allen gegenüber feindselig, nicht nur behinderten Nutzern.
- Reine Icon-Buttons ohne zugänglichen Namen. Ein X ohne Beschriftung wird als „Schaltfläche“ vorgelesen.
- Infinite Scroll ohne Möglichkeit, den Fußbereich zu erreichen.
- Div-Suppe: klickbare divs statt Buttons und Links, was Tastaturunterstützung und Semantik in einem Zug entfernt.
- Bewegung, die prefers-reduced-motion ignoriert.
Die billigste Barrierefreiheits-Strategie ist, das native HTML-Element für die Aufgabe zu nehmen. Jeder eigene Ersatz ist ein Versprechen, Verhalten nachzubauen, das gratis dabei war.

### Warum Overlay-Widgets keine Lösung sind
Barrierefreiheits-Overlays versprechen Konformität aus einem einzigen Skript. Sie können sie nicht liefern, weil die zugrundeliegenden Probleme strukturell sind: Ein Skript kann nicht wissen, was ein Bild zeigt, kann keine Formularbeschriftung schreiben, die zum Zweck des Feldes passt, und kann keine Tastaturfalle in einer eigenen Komponente reparieren.

Sie stören außerdem die assistive Technik, die Menschen bereits nutzen und konfiguriert haben, weshalb mehrere Behindertenverbände davon abraten. Es lohnt sich vor allem, sie zu kennen, um sie mit einer belastbaren Begründung ablehnen zu können.
- Sie können keinen zutreffenden Alt-Text erzeugen, weil sie nicht wissen, was das Bild im Kontext bedeutet.
- Sie können keine Tastaturfallen in Komponenten beheben, die sie nicht gebaut haben.
- Sie kollidieren häufig mit den eigenen Screenreader-Einstellungen der Nutzer.
- Sie beseitigen kein rechtliches Risiko — die zugrundeliegenden Barrieren bestehen weiter.
- Das Geld ist bei den sieben Korrekturen oben auf dieser Seite besser angelegt.

Q: Ist Barrierefreiheit gesetzlich vorgeschrieben?
A: In vielen Rechtsordnungen ja, für öffentliche Stellen und zunehmend für private Unternehmen — der European Accessibility Act, der ADA in den Vereinigten Staaten in seiner Anwendung auf Websites und Entsprechungen anderswo. Die Pflichten unterscheiden sich nach Land und Branche, prüfen Sie das also lokal. Praktisch gilt: WCAG 2.2 AA ist der Standard, auf den fast jede Regulierung zeigt.

Q: Wie viel kostet Barrierefreiheit zusätzlich?
A: Von Anfang an mitgedacht sehr wenig — hauptsächlich Disziplin bei Semantik, Kontrast und Fokuszuständen. Auf eine fertige Individualwebsite nachgerüstet kann es ein erhebliches Projekt sein, weil die Korrekturen strukturell statt kosmetisch sind. Dieser Unterschied ist das ganze Argument dafür, es im Briefing anzusprechen und nicht nach dem Start.

Q: Was ist der Unterschied zwischen WCAG A, AA und AAA?
A: Das sind Konformitätsstufen. A ist das Minimum und lässt echte Barrieren bestehen; AA ist, was Regulierungen im Allgemeinen verlangen und worauf die meisten Organisationen zielen; AAA enthält Kriterien, die nicht für alle Inhalte erreichbar sind — etwa eine 7:1-Kontrastanforderung, die manche Markenpaletten nicht erfüllen können. Zielen Sie auf AA und behandeln Sie AAA als Verbesserung je Kriterium statt als Ziel.

Q: Hilft Barrierefreiheit dem SEO?
A: Indirekt und tatsächlich. Saubere Überschriftenstruktur, beschreibende Linktexte, Alt-Attribute, echte Semantik und schnelle, stabile Seiten helfen beidem. Aber die Überschneidung ist teilweise: Eine Website kann gut ranken und per Tastatur unbenutzbar sein. Machen Sie Barrierefreiheitsarbeit, weil Menschen die Website sonst nicht nutzen können, und nehmen Sie den SEO-Nutzen als Nebeneffekt.

## Webentwicklungsvertrag: Was vor der Unterschrift zu prüfen ist
https://websitedevelopment.biz/de/guides/webentwicklung-vertrag-checkliste
Aktualisiert am 2026-08-07 · Entwickler finden

Ein Webentwicklungsvertrag zählt an genau zwei Gelegenheiten: wenn das Projekt schlecht läuft und wenn die Zusammenarbeit endet. Beides ist absehbar, und eine Handvoll Klauseln bestimmt, wie viel es Sie kostet.

Dieser Leitfaden behandelt, was vor der Unterschrift zu prüfen ist, wovor jede Klausel Sie schützt, und die Punkte, über die zu verhandeln sich lohnt.

### Eigentum: die Klausel, die sich später nicht reparieren lässt
Alles andere in einem Vertrag lässt sich nachverhandeln. Eigentum nicht, sobald die Zusammenarbeit schlecht geendet hat.
- Ihnen gehört der Quellcode mit der Schlusszahlung, ohne fortlaufende Lizenzbedingung.
- Die Domain ist auf Ihre Organisation registriert, mit Ihren Abrechnungsdaten — nicht denen der Entwicklung.
- Hosting- und Drittanbieterkonten laufen auf Ihren Namen, mit der Entwicklung als Nutzerin.
- Inhalte, Bilder und Texte, die Sie geliefert haben, bleiben Ihre; fragen Sie nach allem, was sie erstellen.
- Lizenzen Dritter — Schriften, Plugins, Stockbilder — werden übertragen oder aufgelistet, damit Sie eigene kaufen können.
- Ist Code lizenziert statt übertragen, steht das ausdrücklich mit den Bedingungen dabei.
- Bei Kündigung erhalten Sie Code, Datenbank und Zugangsdaten innerhalb einer genannten Frist.
„Ihnen gehört der Code, sobald die Schlussrechnung bezahlt ist" ist der Satz, nach dem Sie suchen. „Wir räumen Ihnen eine Lizenz zur Nutzung der Website ein" ist etwas anderes, und Sie sollten wissen, dass Sie das wählen.

### Umfang, Änderungen und Korrekturen
Die meisten Streitfälle sind Umfangsstreitigkeiten unter anderem Namen. Diese Klauseln entscheiden, wer die Uneinigkeit bezahlt.
| Leistungsumfang | Eine konkrete Liste, als Anlage beigefügt, kein Absatz |
| Nicht im Umfang | Eine ausdrückliche Ausschlussliste — Inhalte, Fotografie, Pflege, SEO |
| Änderungsprozess | Wer beantragt, wer bepreist, wie freigegeben wird, Wirkung auf den Termin |
| Korrekturrunden | Eine Zahl und die Kosten einer weiteren Runde |
| Abnahme | Was als Freigabe gilt und wie lange Sie zum Prüfen haben |
| Pflichten des Kunden | Was Sie bis wann liefern müssen und die Wirkung bei Verzug |
| Verzug | Was auf beiden Seiten passiert — das sollte nicht einseitig sein |

### Zahlung, Start und Support
Zahlungen, die an Sichtbares gekoppelt sind, schützen beide Seiten; es ist keine feindselige Forderung.
- Meilensteinzahlungen gegen prüfbare Ergebnisse, nicht allein gegen Termine.
- Eine Anzahlung von 30–50 % ist üblich; volle Zahlung vor Arbeitsbeginn nicht.
- Schlusszahlung zum Start, nicht bei einer internen Freigabe, die Sie nicht prüfen können.
- Ein definierter Zeitraum nach dem Start zur Mängelbeseitigung — üblich 30 bis 90 Tage — und was ein Mangel ist.
- Der Unterschied zwischen Mangel (sie beheben ihn) und neuer Anforderung (Sie zahlen), mit Beispielen benannt.
- Reaktionszeiten nach Schweregrad, falls ein Ausfall der Website für Ihr Geschäft zählt.
- Ob Wartung enthalten, optional oder gar nicht vorgesehen ist — und ihr Preis, falls Sie sie später nehmen.

### Kündigung und die Dinge, die vergessen werden
Die Klauseln, die nur einmal zählen — und dann sehr.
| Kündigungsfrist | Beide Seiten sollten mit angemessener Frist aussteigen können |
| Zahlung bei Kündigung | Was für erbrachte, aber nicht gelieferte Arbeit geschuldet ist |
| Übergabe | Code, Datenbank, Zugangsdaten und Dokumentation, in genannter Frist |
| Haftungsobergrenze | Meist der Vertragswert; wissen Sie, wie hoch sie ist |
| Datenschutz | Erforderlich, wenn sie personenbezogene Daten in Ihrem Auftrag verarbeiten |
| Vertraulichkeit | Gegenseitig, und sie sollte die Kündigung überdauern |
| Referenzrechte | Sie werden die Arbeit zeigen wollen; regeln Sie die Bedingungen jetzt |
| Anwendbares Recht | Zählt sehr bei einem Lieferanten im Ausland |
| Streitbeilegung | Mediation vor Klage spart beiden Seiten Geld |
Ein Lieferant, dem eine klare Kündigungsklausel angenehm ist, erwartet meist, dass die Zusammenarbeit gut läuft. Widerstand dagegen ist eine Nachfrage wert.

Q: Brauche ich für einen Website-Vertrag eine Anwältin?
A: Für ein kleines Projekt ist eine klare schriftliche Vereinbarung zu den obigen Punkten meist angemessen. Für alles Umfangreichere — einen Shop, eine Anwendung oder einen Aufbau, dessen Verlust ernsthaft wehtäte — sind ein paar Stunden rechtliche Prüfung günstig gegenüber dem Wert im Risiko. Lassen Sie ihn zumindest von jemandem lesen, der für das Projekt nicht begeistert ist.

Q: Ist es normal, dass die Entwicklung die Domain hält?
A: Es ist verbreitet und nicht in Ihrem Interesse. Die Domain sollte auf Ihre Organisation mit Ihren Abrechnungsdaten registriert sein; tragen Sie die Entwicklung als technischen Kontakt ein, wenn sie Zugriff braucht. Domains in der Hand eines früheren Lieferanten sind eine der verlässlich schmerzhaftesten Situationen dieser Branche.

Q: Was ist eine angemessene Anzahlung?
A: Dreißig bis fünfzig Prozent, der Rest über Meilensteine und den Start. Eine Anzahlung ist legitim — sie deckt das Risiko des Lieferanten, dass Sie verschwinden. Volle Vorauszahlung verschiebt das gesamte Risiko zu Ihnen und gibt Ihnen keinen Hebel, wenn die Arbeit bei achtzig Prozent stehen bleibt.

Q: Was, wenn das Projekt in Verzug gerät?
A: Der Vertrag sollte Verzug auf beiden Seiten regeln, denn er wird sehr oft durch Inhalte oder Entscheidungen des Kunden verursacht. Suchen Sie eine Klausel, die das unterscheidet und die Folge benennt. Vertragsstrafen klingen beruhigend und erhöhen meist nur den Preis, weil der Lieferant das Risiko einpreist.

## Website-Launch-Checkliste: Was vor dem Livegang zu prüfen ist
https://websitedevelopment.biz/de/guides/website-launch-checkliste
Aktualisiert am 2026-08-07 · Website-Planung

Probleme am Launch-Tag sind fast nie exotisch. Es sind eine für Suchmaschinen offene Staging-Umgebung, ein Kontaktformular, das an eine Adresse geht, die niemand liest, und eine alte URL-Struktur ohne Weiterleitungen.

Diese Checkliste behandelt, was vor dem Livegang zu prüfen ist, in der Reihenfolge, in der ein Launch tatsächlich abläuft, und was in der ersten Stunde und der ersten Woche zu beobachten ist.

### Vor dem Launch: Technik
Das sind die Prüfungen, die von außen schwer auffallen und spät entdeckt teuer werden.
- HTTPS funktioniert auf jeder Seite, und HTTP leitet per 301 dorthin weiter.
- Ein kanonischer Hostname: www oder ohne www, der jeweils andere leitet weiter. Nicht beide liefern Inhalte aus.
- Die Staging-Umgebung ist passwortgeschützt oder gesperrt, und ihr noindex wurde NICHT auf die Produktion kopiert.
- Die robots.txt in der Produktion erlaubt das Crawlen. Das ist der mit Abstand häufigste Launch-Fehler.
- Eine 404-Seite existiert, liefert tatsächlich Status 404 und bietet einen Weg weiter.
- Formulare senden, speichern den Datensatz und benachrichtigen eine Adresse, die jemand liest.
- Backups sind eingerichtet und eine Wiederherstellung wurde getestet. Ungetestete Backups sind keine Backups.
- Fehlerprotokollierung ist aktiv und jemand erhält die Meldungen.
Prüfen Sie die Statuscodes, nicht nur die Seiten. Eine „404-Seite“, die HTTP 200 liefert, sagt Suchmaschinen, dass jede vertippte URL eine echte Seite ist.

### Vor dem Launch: Inhalt und SEO
Inhaltsprüfungen gehen schnell, sind aber die, die Besuchern zuerst auffallen, und die SEO-Prüfungen sind die, deren nachträgliche Korrektur schmerzt.
- Jede Seite hat einen eigenen Titel und eine Meta-Beschreibung, die zum Inhalt passen.
- Kein Platzhaltertext, kein „Lorem ipsum“, kein „[Kundenname]“ irgendwo übrig.
- Jedes Bild hat sinnvollen Alt-Text — dekorative Bilder bekommen ein leeres alt, kein fehlendes.
- Die Überschriftenstruktur ist sauber: eine H1 pro Seite, keine Sprünge von H1 zu H4.
- Alle internen Links lösen auf; keine Links auf die Staging-Domain.
- Die XML-Sitemap wird erzeugt, listet nur indexierbare URLs und ist in der robots.txt referenziert.
- Weiterleitungen von jeder alten URL mit Traffic oder Links, kartiert und getestet.
- Strukturierte Daten validieren auf den Templates, die sie tragen.
- Open-Graph-Tags erzeugen eine sinnvolle Vorschau, wenn die URL in einen Chat eingefügt wird.

### Vor dem Launch: Recht, Analytics und Barrierefreiheit
Die Teile, die am häufigsten auf „nach dem Launch“ verschoben werden, was dann nie bedeutet.
| Datenschutzerklärung | Vorhanden, korrekt zu dem, was Sie wirklich erheben, von jeder Seite verlinkt |
| Cookie-Einwilligung | Erforderlich, wenn Sie nicht notwendige Cookies setzen; blockiert sie bis zur Einwilligung |
| AGB und Impressum | Vorhanden, wo Ihre Rechtsordnung sie verlangt |
| Analytics | Einmal installiert, auf allen Seiten aktiv, mit einem Ziel für die Hauptaktion |
| Search Console | Property verifiziert und Sitemap am Launch-Tag eingereicht |
| Tastaturzugang | Jedes interaktive Element mit Tab und Enter erreichbar und bedienbar |
| Kontrast | Fließtext und Bedienelemente erfüllen WCAG AA gegen ihren Hintergrund |
| Zoom | Seite bei 200 % Textgröße ohne horizontales Scrollen nutzbar |

### Die erste Stunde und die erste Woche
Ein Launch ist kein Moment, sondern ein Zeitfenster. Die meisten Probleme, die es an der Checkliste vorbeischaffen, zeigen sich in der ersten Stunde, die SEO-Probleme in den folgenden Tagen.
- Laden Sie die Startseite vom Handy über Mobilfunk, nicht aus dem Büronetz.
- Schicken Sie das Hauptformular selbst ab und bestätigen Sie, dass die Benachrichtigung ankommt.
- Prüfen Sie fünf alte URLs auf korrekte Weiterleitung, darunter eine tiefe.
- Bestätigen Sie, dass Analytics Ihren eigenen Besuch erfasst, und schließen Sie dann Ihren Traffic aus.
- Reichen Sie die Sitemap in der Search Console ein und beantragen Sie die Indexierung der wichtigsten Seiten.
- Beobachten Sie die Server-Fehlerprotokolle in der ersten Stunde — neue Traffic-Muster bringen neue Fehler hervor.
- Nach einer Woche: Search-Console-Abdeckung auf unerwartete Ausschlüsse und Crawl-Fehler prüfen.
- Nach einer Woche: Traffic mit der alten Website vergleichen und jede Seite untersuchen, die stark verloren hat.
Starten Sie nicht am Freitagnachmittag. Geht etwas kaputt, sind die Leute, die es beheben können, zwei Tage weg, und das Problem wächst.

Q: Was ist der häufigste Launch-Fehler?
A: Eine robots.txt oder ein noindex-Meta-Tag, das vom Staging in die Produktion mitgenommen wurde. Die Website sieht für jeden Besucher perfekt aus und ist für Suchmaschinen unsichtbar, und das wird oft erst Wochen später entdeckt, wenn jemand fragt, warum nie Traffic kam. Prüfen Sie robots.txt und das Meta-Robots-Tag in der Produktion, am Launch-Tag, von außerhalb Ihres Netzes.

Q: Muss ich alte URLs weiterleiten?
A: Wenn die alte Website irgendeinen Traffic oder irgendwelche eingehenden Links hatte, ja. Kartieren Sie jede alte URL per 301 auf ihr nächstes Äquivalent. Alles auf die Startseite zu leiten, entspricht in Bezug auf angesammelte Ranking-Signale dem Löschen der Seiten, und es ist eine schlechte Erfahrung für jeden, der einem alten Link folgt.

Q: Wie lange dauert es nach einem Relaunch, bis sich der Suchtraffic erholt?
A: Bei sauberen Weiterleitungen und gleichwertigen Inhalten typischerweise zwei bis sechs Wochen Schwankung, bis sich alles setzt. Ein Einbruch in den ersten zwei Wochen ist normal. Ein Einbruch, der nach einem Monat weiter zunimmt, deutet meist auf ein technisches Problem hin — fehlende Weiterleitungen, blockiertes Crawlen oder Inhalte, die unbemerkt gestrichen wurden.

Q: Alles auf einmal starten oder in Phasen?
A: Beim Ersatz einer Website ist alles auf einmal meist einfacher: Zwei parallele Websites teilen Ihre Links auf und erzeugen Duplicate-Content-Probleme. Für neue Bereiche auf einer bestehenden Website sind Phasen in Ordnung. Was Sie nicht tun sollten: eine halbe Struktur starten und den Rest später ergänzen, ohne die URLs für das Kommende geplant zu haben.

## Freelancer, Agentur oder intern: Was passt zu Ihrem Projekt?
https://websitedevelopment.biz/de/guides/freelancer-vs-agentur-vs-intern
Aktualisiert am 2026-08-07 · Entwickler finden

Dieselbe Website kann von einer freiberuflichen Person, von einem Agenturteam oder von jemandem gebaut werden, den Sie anstellen. Das Ergebnis kann ähnlich sein; das Risikoprofil, die Kosten und was im zweiten Jahr passiert, sind es nicht.

Dieser Leitfaden vergleicht die drei nach den Faktoren, die sich tatsächlich unterscheiden, und behandelt die Mischformen, bei denen die meisten Organisationen landen.

### Der Vergleich, auf den es ankommt
Kosten sind die offensichtliche Achse und selten die entscheidende. Kontinuität ist es meist.
| Kosten für ein Projekt | Am niedrigsten | Am höchsten | Hoch, wenn es ein Projekt ist |
| Kosten über Jahre | Niedrig | Mittel bis hoch | Am niedrigsten bei fortlaufender Arbeit |
| Zeit bis zum Start | Schnell | Langsamer — in der Warteschlange | Am langsamsten — Personalsuche |
| Breite der Fähigkeiten | Schmal bis mittel | Breit | Was Sie eingestellt haben |
| Kontinuitätsrisiko | Hoch — eine Person | Niedrig | Mittel — sie können gehen |
| Prozess und QA | Sehr unterschiedlich | Meist formalisiert | Was Sie aufbauen |
| Geschäftskenntnis | Wächst mit der Zeit | Über ein Team verteilt | Am tiefsten |
| Am besten für | Definierte Projekte, laufende Kleinarbeit | Große Projekte, mehrere Disziplinen | Fortlaufende Produktarbeit |

### Der Freelancer-Fall, ehrlich
Eine gute freiberufliche Person ist das beste verfügbare Preis-Leistungs-Verhältnis für ein klar definiertes Projekt, und die Zusammenarbeit hat ein bestimmtes Fehlerbild, das man einplanen statt ignorieren sollte.
- Der Vorteil: Sie sprechen mit der Person, die die Arbeit macht; es gibt keine Kundenbetreuungsschicht und keine Marge darauf.
- Das Risiko: Krankheit, ein anderer Auftrag oder schlicht ein Weiterziehen. Ein Ein-Personen-Lieferant hat keine Redundanz.
- Wirksame Absicherungen: Code ab Tag eins in Ihrem Repository, dokumentiertes Deployment, Konten auf Ihren Namen und eine zweite Person, die das Projekt zumindest gesehen hat.
- Wo es scheitert: Projekte, die mehrere Disziplinen gleichzeitig brauchen — Design, Backend, Integrationen, QA — bei festem Termin.
- Wo es glänzt: laufende kleine Verbesserungen, wo eine Person, die Ihre Website kennt, weit mehr wert ist als ein Team, das sie nicht kennt.
Das Freelancer-Risiko ist nicht Kompetenz, sondern Verfügbarkeit. Jede Absicherung oben zielt darauf, das Projekt ohne diese Person überlebensfähig zu machen, und alle sind am Anfang billig einzurichten.

### Der Agentur-Fall, ehrlich
Sie kaufen Kapazität, Breite und Kontinuität und bezahlen den Overhead, der sie liefert.
- Der Vorteil: mehrere Fähigkeiten gleichzeitig verfügbar, ein Prozess, und das Projekt läuft weiter, wenn jemand geht.
- Die Kosten: Kundenbetreuung, Projektleitung und Marge, typischerweise 40–60 % über einer freiberuflichen Person für dasselbe Ergebnis.
- Das Risiko: Die Menschen, die präsentiert haben, sind nicht die, die bauen. Fragen Sie, wer die Arbeit tatsächlich macht, und lassen Sie sich Namen geben.
- Wo es scheitert: kleine laufende Änderungen, die gegen die Kostenstruktur einer Agentur ineffizient sind und hinter größeren Kunden zurückgestellt werden.
- Wo es glänzt: ein umfangreicher Aufbau mit echtem Termin und mehreren beteiligten Disziplinen.

### Intern und die Mischformen
Eine Entwicklerin anzustellen ergibt nur bei fortlaufender Arbeit Sinn — sonst zahlen Sie ungenutzte Kapazität und, schlimmer, eine einzelne Person ohne Gegenüber, das ihre Entscheidungen prüft.
- Nur intern passt zu Organisationen, in denen die Website ein Produkt mit Roadmap ist, kein Projekt, das endet.
- Agentur baut, Freelancer pflegt ist ein verbreitetes und sinnvolles Muster: Kapazität für den Aufbau kaufen, Kontinuität für die Jahre danach.
- Intern plus Spezialisten funktioniert, wenn Sie jemand Kompetentes im Haus haben und für konkrete Probleme Expertise dazuholen.
- Freelancer plus benannte Vertretung ist die günstigste Konstellation, die überhaupt Redundanz hat.
- Agenturpauschale mit festem Monatskontingent funktioniert, wenn das Kontingent wirklich genutzt wird; ungenutzte Stunden sind reine Kosten.

Q: Ist eine freiberufliche Person riskanter als eine Agentur?
A: Für die Kontinuität ja — eine Person kann nicht an zwei Orten sein oder krank werden, ohne das Projekt zu beeinflussen. Für die Qualität nicht grundsätzlich; die Streuung unter Freiberuflichen ist in beide Richtungen groß, und die unter Agenturen ebenso. Der richtige Vergleich ist nicht Kompetenz, sondern was passiert, wenn Ihr Lieferant nächsten Monat nicht verfügbar ist.

Q: Wie viel günstiger ist eine freiberufliche Person?
A: Typischerweise 30–50 % bei vergleichbarem Ergebnis, weil es keine Projektleitungsschicht, keine Kundenbetreuung und keine Agenturmarge gibt. Was Sie verlieren können, ist der Prozess, der Probleme abfängt — QA, Code-Review, eine zweite Meinung — und genau das ist unsichtbar, bis es fehlt.

Q: Wann lohnt es sich, eine Entwicklerin anzustellen?
A: Wenn es wirklich fortlaufende Arbeit gibt — eine Website, die ein Produkt mit Roadmap ist — und vorzugsweise, wenn es mehr als eine Person sein wird. Eine einzelne interne Entwicklerin ohne Gegenüber ist ein Wissenssilo und ein Single Point of Failure, also ein ähnliches Risiko wie beim Freelancer, nur mit höheren Fixkosten.

Q: Kann ich Ansätze mischen?
A: Die meisten Organisationen tun genau das, und es funktioniert gut: eine Agentur für den Aufbau, eine freiberufliche Person oder eine kleine Pauschale für laufende Änderungen. Voraussetzung ist, dass die Übergabe echt ist — Code in Ihrem Repository, dokumentiertes Deployment, Konten auf Ihren Namen —, sonst verbringt die zweite Partei Wochen damit, die erste zu rekonstruieren.

## Eine Webentwicklerin beauftragen: Ein praktisches Vorgehen
https://websitedevelopment.biz/de/guides/website-entwickler-beauftragen
Aktualisiert am 2026-08-07 · Entwickler finden

Eine Webentwicklerin auszuwählen ist überwiegend das Sammeln von Belegen, und die meisten sammeln die falschen: Portfolios, die die beste statt der typischen Arbeit zeigen, und Preise, die Dinge vergleichen, die nicht vergleichbar sind.

Dieser Leitfaden behandelt ein Vorgehen, das bessere Ergebnisse bringt — was Sie verschicken, was Sie fragen, was Sie prüfen und wann Sie aufhören.

### Schicken Sie allen dasselbe Briefing
Angebote sind nur vergleichbar, wenn sie dieselbe Frage beantworten. Ein einseitiges Briefing plus eine Seitenstruktur genügt und beseitigt den größten Teil der Streuung, die Angebote so unterschiedlich wirken lässt.
- Was die Website erreichen muss, und die eine Handlung, auf die es am meisten ankommt.
- Eine Seitenliste, als startkritisch oder später markiert.
- Die funktionalen Anforderungen: Formulare, Suche, Konten, Kasse, Integrationen.
- Was außerhalb des Umfangs liegt — Texterstellung, Fotografie, laufendes SEO.
- Ihr Budgetrahmen. Ihn zurückzuhalten verschwendet allen Zeit und liefert Angebote, die Sie nicht nutzen können.
- Ihr Termin und was ihn treibt.
- Wie Sie entscheiden werden und bis wann.
Einen Budgetrahmen zu nennen bedeutet nicht, dass Ihnen das obere Ende berechnet wird. Es bedeutet, dass die Angebote, die Sie erhalten, für Projekte gelten, die Sie tatsächlich kaufen können.

### Was Sie fragen und was die Antworten bedeuten
Diese Fragen trennen Entwicklerinnen, die Projekte abgeschlossen haben, von denen, die welche begonnen haben.
| Zeigen Sie mir eine Website wie meine in meiner Größenordnung | Eine Live-URL, kein Portfolio-Bild, mit Kontext |
| Wem gehören Code und Konten? | „Ihnen" — sofort, ohne Einschränkung |
| Wie kommt eine Änderung in die Produktion? | Versionskontrolle und ein Deployment-Prozess, kein FTP |
| Was passiert, wenn nach dem Start etwas kaputtgeht? | Ein definierter Supportzeitraum und was danach folgt |
| Was ist nicht enthalten? | Eine konkrete Liste, ungefragt angeboten |
| Was könnte bei diesem Projekt schiefgehen? | Ehrliche Risiken — Inhaltsverzug, Integrationen, Entscheidungen |
| Wer wird die Arbeit tatsächlich machen? | Benannte Personen, nicht „unser Team" |
| Was brauchen Sie von uns? | Eine klare Liste mit Terminen |

### Prüfen Sie die Belege selbst
Zwanzig Minuten eigenständiges Prüfen sind mehr wert als eine Stunde Gespräch, denn sie testen die Arbeit statt den Vortrag.
- Öffnen Sie zwei ihrer Live-Websites auf dem Handy, über Mobilfunk.
- Jagen Sie eine durch einen Performance-Test und sehen Sie sich das Ergebnis ehrlich an.
- Gehen Sie mit der Tabulatortaste durch eine Seite und schauen Sie, ob der Fokus sichtbar ist.
- Sehen Sie in den Quelltext: Gibt es einen Titel, eine Meta-Beschreibung, eine saubere Überschriftenstruktur?
- Sprechen Sie mit einer früheren Kundin — und fragen Sie gezielt nach einer Situation, in der etwas schiefging.
- Prüfen Sie, ob ihre eigene Website gepflegt ist. Das entscheidet nichts, aber es ist ein Signal.
Die nützlichste Referenzfrage ist nicht „waren Sie zufrieden", sondern „was ist passiert, als etwas schiefging, und wie sind sie damit umgegangen?" Jedes Projekt hat so einen Moment.

### Warnzeichen und gute Zeichen
Muster, die man in beide Richtungen stark gewichten sollte.
| Ein Angebot binnen einer Stunde, ohne Rückfragen | Fragen zu Ihrem Geschäft vor dem Angebot |
| Garantierte Platzierungen auf Seite eins | Die Erklärung, dass niemand Platzierungen garantieren kann |
| Vager Umfang mit Festpreis | Eine ausdrückliche Ausschlussliste |
| Sie halten Domain oder Hosting | Alles auf Ihren Namen registriert |
| Keine Staging-Umgebung | Sie nehmen ab dem ersten Template auf Staging ab |
| Nicht bereit, Referenzen zu nennen | Bietet sie an, bevor Sie fragen |
| Druck, diese Woche zu unterschreiben | Bereit zu warten, während Sie vergleichen |
| Volle Vorauszahlung | Meilensteinzahlungen, an Ergebnisse gekoppelt |

Q: Sollte ich das günstigste Angebot wählen?
A: Nur wenn es dieselbe Frage beantwortet wie die anderen. Ein Angebot weit unter dem Rest schließt meist etwas aus — Inhaltspflege, Tests, Korrekturen nach dem Start — oder hat das Briefing nicht gelesen. Fragen Sie schriftlich nach den Ausschlüssen und vergleichen Sie dann die Gesamtkosten des ersten Jahres inklusive Wartung und dem, was Ihnen am Ende gehört.

Q: Wie beurteile ich eine Entwicklerin, wenn ich nicht technisch bin?
A: Beurteilen Sie Prozess und Belege statt Technologie. Können sie Ihnen eine Live-Website in Ihrer Größenordnung zeigen? Nutzen sie Versionskontrolle und Staging? Beantworten sie „wem gehört der Code?" ohne zu zögern? Fragen sie nach Ihrem Geschäft? Nichts davon braucht technisches Wissen, und es sagt Ergebnisse besser voraus als der Technologiestack.

Q: Was gehört in den Vertrag?
A: Umfang mit ausdrücklicher Ausschlussliste, Meilensteine und Zahlungen, Eigentum an Code, Domain und Konten, Korrekturrunden, was nach dem Start passiert, Reaktionszeiten bei Problemen und Kündigungsfristen. Wenn es eine Klausel gibt, auf der Sie bestehen sollten, ist es das Eigentum — alles andere lässt sich später nachverhandeln, das nicht.

Q: Wie viele Entwicklerinnen sollte ich ansprechen?
A: Drei bis fünf ist der nützliche Bereich. Weniger, und Sie haben nichts zum Vergleichen; mehr, und der Bewertungsaufwand übersteigt den Wert der zusätzlichen Optionen, und Sie lassen alle warten. Schicken Sie allen dasselbe Briefing und setzen Sie einen Entscheidungstermin, damit der Prozess endet.

## Responsive Webdesign: Ein praktischer Leitfaden
https://websitedevelopment.biz/de/guides/responsive-webdesign-leitfaden
Aktualisiert am 2026-08-07 · Webdesign

Responsives Design bedeutet eine Website, die bei jeder Breite funktioniert, nicht eine separate Mobilversion. In der Praxis sind die meisten Websites auf dem Papier responsiv und an bestimmten Stellen kaputt — eine Tabelle, die horizontales Scrollen erzwingt, eine Navigation, die ein Drittel des Bildschirms frisst, ein Formular, das unter iOS unvorhersehbar zoomt.

Dieser Leitfaden behandelt die Herangehensweise, wo die echten Fehler liegen und wie man darauf testet.

### Vom schmalen Ende her gestalten
Schmal anzufangen erzwingt die Prioritätsentscheidungen. Bei 320 Pixeln ist Platz für eine Sache auf einmal, also müssen Sie entscheiden, welche das ist; ein Design danach zu verbreitern heißt vor allem, den Dingen mehr Raum zu geben.

Der umgekehrte Weg — bei 1440 gestalten und dann Dinge entfernen — erzeugt mobile Layouts, die der Desktop mit ausgeblendeten Teilen sind, und so landet wichtiger Inhalt auf display:none auf dem Gerät, das die meisten Besucher nutzen.
- Beginnen Sie Layouts bei 320–360 px, den schmalsten real verbreiteten Geräten.
- Blenden Sie mobil nie Inhalte aus, die ein mobiler Besucher braucht; verschieben oder einklappen stattdessen.
- Lassen Sie den Inhalt die Breakpoints bestimmen — setzen Sie einen, wo das Layout bricht, nicht bei Gerätenamen.
- Testen Sie mit Browser-Textgröße auf 200 %: Das ist eine verbreitete Barrierefreiheits-Einstellung und bricht mehr Layouts als jedes Handy.
Nach Geräten benannte Breakpoints altern schlecht. „Tablet“ hat in zehn Jahren sechs verschiedene Breiten bedeutet; „der Punkt, an dem das Karten-Raster hässlich wird“ ändert sich nicht.

### Die Elemente, die tatsächlich brechen
Eine Handvoll Komponenten verursacht die meisten Responsive-Fehler, und sie sind vorhersehbar genug, um sie gezielt zu prüfen.
| Tabellen | Horizontales Scrollen der ganzen Seite | Scroll-Container oder Umstapeln als Karten mit Datenbeschriftung |
| Lange Wörter / URLs | Seite scrollt seitwärts | overflow-wrap und min-width:0 bei Flex- und Grid-Kindern |
| Bilder | Überlauf oder Layoutverschiebung | max-width:100 %, explizite width- und height-Attribute |
| Navigation | Nimmt ein Drittel des Bildschirms | Einklappen oder Hauptpunkte in eine untere Leiste |
| Formulare | iOS zoomt hinein und wieder heraus geht nicht | Schriftgröße mindestens 16 px in Eingabefeldern |
| Fixierte Elemente | Verdecken den Inhalt, auf den sie verweisen | In scroll-padding und Body-Padding einrechnen |
| Modale Dialoge | Lassen sich auf kleinen Bildschirmen nicht schließen | Mobil formatfüllend mit sichtbarem Schließen-Element |

### Bilder und Medien
Bilder sind meist das Größte auf einer Seite und die häufigste Quelle von Layoutverschiebung. Drei Attribute beheben das meiste davon und kosten nichts.
- Setzen Sie immer width- und height-Attribute, damit der Browser den Platz reserviert, bevor die Datei ankommt.
- Liefern Sie moderne Formate — WebP oder AVIF — mit Fallback, wo Sie noch eines brauchen.
- Nutzen Sie srcset und sizes, damit ein Handy eine handygroße Datei lädt und kein 2000-px-Hero.
- Laden Sie Bilder unterhalb der Falz verzögert, aber nie das größte sichtbare Bild: Das ist Ihr LCP-Element.
- Geben Sie dem Hauptbild fetchpriority="high", damit es nicht hinter dekorativen Assets in der Warteschlange steht.
- Setzen Sie bei Hintergrundbildern ein Seitenverhältnis, damit der Container vor dem Laden nicht kollabiert.

### Touch, nicht nur Breite
Responsiv geht es nicht nur um Layout. Ein schmaler Viewport bedeutet meist einen Finger statt einer Maus, und Fingereingabe hat andere Anforderungen, die breitenbasierte Media Queries allein nicht abdecken.
- Touch-Ziele mindestens 44 × 44 px mit Abstand dazwischen; benachbarte 30-px-Links werden ständig danebengetippt.
- Nichts Wichtiges hinter Hover — ein reines Hover-Menü ist per Touch unerreichbar.
- Nutzen Sie pointer:coarse-Media-Queries, um Hover-Effekte zu entfernen, die nach einem Tap hängenbleiben.
- Halten Sie primäre Aktionen bei hohen Handys in Daumenreichweite; die obere rechte Ecke ist einhändig am schwersten zu erreichen.
- Beachten Sie prefers-reduced-motion: Parallax und große Übergänge verursachen bei manchen Nutzern echtes Unwohlsein.

Q: Wie viele Breakpoints brauche ich?
A: Meist drei bis fünf, und sie sollten aus Ihrem Inhalt kommen statt aus einer Geräteliste. Setzen Sie einen, wo das Layout beim Verbreitern des Fensters falsch aussieht, nicht weil ein bestimmtes Handy existiert. Websites mit einem Dutzend Breakpoints kompensieren fast immer ein Layout, das von vornherein nicht fluide war.

Q: Ist eine separate Mobilseite jemals richtig?
A: Selten. Sie bedeutet zwei Codebasen, zwei URL-Sätze, zwei Deployments und eine zu pflegende Canonical-Beziehung, und sie endet meist damit, dass eine der beiden still zurückfällt. Die Fälle, in denen es noch passiert, sind Altsysteme, die sich nicht responsiv machen lassen, und selbst dann ist es ein Notbehelf statt eines Plans.

Q: Wie teste ich responsives Design richtig?
A: Die Geräte-Emulation im Browser findet Layoutprobleme, aber nicht Touch-, Netzwerk- oder Plattformverhalten. Testen Sie auf mindestens einem echten Android der unteren Mittelklasse und einem iPhone, über Mobilfunk statt Büro-WLAN. Wiederholen Sie dann die Hauptseiten mit Browser-Textgröße auf 200 %, denn dort fallen die meisten Layouts tatsächlich auseinander.

Q: Was ist mit Datentabellen auf Handys?
A: Zwei brauchbare Optionen: die Tabelle in einen horizontal scrollenden Container mit sichtbarem Hinweis und fixierter erster Spalte setzen, oder jede Zeile als Karte umstapeln, in der jede Zelle ihre eigene Spaltenbeschriftung trägt. Der Scroll-Container erhält die Vergleichbarkeit; der Kartenstapel liest sich leichter. Entscheiden Sie danach, ob Besucher Zeilen vergleichen oder einzeln lesen.

## Website-Struktur und Sitemap: So planen Sie Ihre Seiten
https://websitedevelopment.biz/de/guides/website-struktur-und-sitemap
Aktualisiert am 2026-08-07 · Website-Planung

Die Website-Struktur ist die Anordnung Ihrer Seiten und der Pfade dazwischen. Sie entscheidet, ob ein Besucher das Gesuchte in einem Klick findet oder in dreien, und sie ist eines der stärksten Signale, die eine Suchmaschine darüber hat, worum es auf Ihrer Website geht und welche Seiten zählen.

Dieser Leitfaden behandelt, wie man eine Struktur plant, wie tief zu tief ist, wie man URLs benennt, und die Fehler, die jetzt billig zu vermeiden und nach dem Start teuer zu beheben sind.

### Nach Aufgabe gruppieren, nicht nach Organigramm
Der häufigste Strukturfehler ist eine Navigation, die abbildet, wie die Organisation aufgebaut ist, statt was Besucher tun wollten. Niemand sucht Ihre Solutions-Abteilung.

Beginnen Sie mit den Fragen, die Besucher tatsächlich stellen, gruppieren Sie die Seiten, die jede beantworten, und benennen Sie die Gruppe mit deren Worten — die fast nie Ihre internen Worte sind.
- Schreiben Sie jede Seite in eine eigene Zeile und gruppieren Sie dann Zeilen, die dieselbe Frage beantworten.
- Benennen Sie jede Gruppe in Besuchersprache: „Preise“, nicht „Kommerzielles Rahmenwerk“.
- Zielen Sie auf fünf bis sieben oberste Bereiche; mehr, und die Navigation ist nicht mehr überfliegbar.
- Passt eine Seite in keine Gruppe, ist sie meist entweder überflüssig oder eine neue Einzelgruppe — entscheiden Sie, welches.

### Wichtige Seiten flach halten
Tiefe ist die Zahl der Klicks von der Startseite. Seiten, die zählen, sollten in zwei oder drei erreichbar sein; alles auf Tiefe fünf wird selten von Besuchern gefunden und seltener von Suchmaschinen gecrawlt.

Tiefe ist nicht dasselbe wie URL-Länge. Eine Seite unter /guides/seo/technical-seo kann trotzdem einen Klick von der Startseite entfernt sein, wenn etwas direkt darauf verlinkt. Entscheidend ist der Linkpfad, nicht die Schrägstriche.
| 0 | Startseite | Verlinkt jeden obersten Bereich und die Hauptaktion |
| 1 | Bereichs-Hubs, wichtige Landingpages | In der Hauptnavigation |
| 2 | Einzelne Artikel, Produkte, Leistungen | Verlinkt von Hubs und von verwandten Inhalten |
| 3 | Varianten, tiefe Referenzseiten | Verlinkt von der Elternseite und aus der Suche |
| 4+ | Archive, alte Kampagnen | Fragen Sie, ob sie überhaupt indexiert werden sollten |
Die Startseite ist für die meisten Websites nicht der Haupteingang. Suchtraffic landet tief, also muss jede Seite sagen, wo sie ist, und den nächsten Schritt anbieten.

### URL-Muster, die man einmal entscheidet
URLs sind am Anfang billig richtig zu machen und danach schmerzhaft zu ändern, weil Ändern Weiterleitungen, verlorene Signale und kaputte externe Links bedeutet. Entscheiden Sie das Muster, bevor die erste Seite existiert.
- Kleinschreibung, Wörter durch Bindestriche getrennt, keine Unterstriche oder Leerzeichen.
- Kurz und beschreibend: /guides/website-planung-leitfaden, nicht /p?id=4821.
- Eine einheitliche Entscheidung zum abschließenden Schrägstrich, per Weiterleitung auf die kanonische Form erzwungen.
- Nehmen Sie den Bereich auf, wo er Bedeutung hinzufügt; stapeln Sie nicht jeden Vorfahren in den Pfad.
- Keine Daten in URLs, außer der Inhalt ist wirklich zeitgebunden — sie lassen zeitlose Seiten veraltet wirken.
- Für mehrsprachige Websites: Entscheiden Sie das Sprachmuster jetzt; /de/…-Präfixe sind am einfachsten zu durchdenken.

### Zwei Sitemaps, zwei Zielgruppen
Das Wort deckt zwei verschiedene Dinge ab. Eine Planungs-Sitemap ist das Diagramm, das Sie vor der Umsetzung zeichnen — Seiten und ihre Beziehungen. Eine XML-Sitemap ist eine Datei unter /sitemap.xml, die Ihre indexierbaren URLs für Suchmaschinen auflistet.

Sie brauchen beide, und sie richten sich an verschiedene Leser.
| Zielgruppe | Ihr Team und die Entwicklung | Suchmaschinen |
| Wann | Bevor das Design beginnt | Nach dem Start automatisch erzeugt |
| Enthält | Jede geplante Seite und ihre Elternseite | Jede kanonische, indexierbare URL |
| Format | Ein Diagramm oder eine verschachtelte Liste | XML, auf größeren Websites nach Bereich aufgeteilt |
| Pflege | Aktualisiert, wenn sich der Umfang ändert | Neu erzeugt, sobald sich Inhalte ändern |
Eine XML-Sitemap sollte nur Seiten auflisten, die indexiert werden sollen. Gefilterte, paginierte oder noindex-URLs verschwenden Crawl-Budget und senden widersprüchliche Signale.

Q: Wie viele Hauptnavigationspunkte sollte ich haben?
A: Fünf bis sieben für die meisten Websites. Darüber hinaus ist die Leiste nicht mehr überfliegbar, sondern wird zu einer Liste, die man liest statt streift — und auf dem Handy zu einem Menü, das niemand öffnet. Brauchen Sie wirklich mehr, ist die übliche Lösung, dass zwei Ihrer Bereiche eigentlich einer sind.

Q: Müssen URLs zur Navigation passen?
A: Sie sollten konsistent sein, müssen sie aber nicht exakt spiegeln. Entscheidend ist, dass die URL vorhersehbar und stabil ist. Tief verschachtelte Pfade, die jeden Vorfahren stapeln, sind fragil: Verschieben Sie einen Bereich, ändern sich alle URLs darunter, und Sie erben eine Weiterleitungskarte, die Sie ewig pflegen.

Q: Was passiert bei einem Relaunch mit meinen alten URLs?
A: Jede alte URL mit Traffic oder Links braucht eine 301-Weiterleitung auf ihr nächstes Äquivalent. Nicht auf die Startseite — das sagt einer Suchmaschine, dass die Seite weg ist, und verliert die angesammelten Signale. Kartieren Sie die Weiterleitungen vor dem Start, aus einem Crawl der alten Website plus Ihrer Analytics, und testen Sie sie am Tag des Livegangs.

Q: Sollte jede Seite in der Navigation stehen?
A: Nein. Navigation ist für die Seiten, die die meisten Besucher brauchen; der Rest wird über Hubs, verwandte Links, Suche und Fußbereich erreicht. Eine Seite, die in keiner Navigation steht und von nirgends verlinkt ist, ist allerdings verwaist — sie wird kaum gecrawlt und selten gefunden. Jede indexierbare Seite braucht mindestens einen internen Link von irgendwoher.

## Webdesign-Prinzipien, die das Ergebnis wirklich verändern
https://websitedevelopment.biz/de/guides/webdesign-prinzipien
Aktualisiert am 2026-08-07 · Webdesign

Viele Webdesign-Ratschläge sind Vorliebe im Gewand eines Prinzips. Eine kleinere Zahl von Entscheidungen verändert zuverlässig, was Besucher tun, und die meisten davon sind unglamourös: was zuerst sichtbar ist, ob Text lesbar ist, und wie viele Schritte zwischen jemandem und dem stehen, weswegen er gekommen ist.

Dieser Leitfaden behandelt die mit Belegen und benennt die, die wirklich Geschmackssache sind.

### Eine klare Hierarchie pro Bildschirm
Jeder Bildschirm sollte eine Sache offensichtlich am wichtigsten machen. Wenn drei Elemente mit gleichem Gewicht um Aufmerksamkeit konkurrieren, lösen Besucher die Mehrdeutigkeit auf, indem sie gehen.

Hierarchie entsteht aus Größe, Gewicht, Farbe, Abstand und Position — grob in dieser Reihenfolge der Stärke. Am wenigsten genutzt wird der Raum: Ein Element mit Platz drumherum liest sich als wichtig, ohne laut zu sein.
- Eine primäre Aktion pro Bildschirm, anders gestaltet als alles andere.
- Sekundäre Aktionen vorhanden, aber visuell leiser — Umriss statt Fläche.
- Überschriften, die den Inhalt beschreiben, keine cleveren, die nichts beschreiben.
- Raum bewusst eingesetzt: Eine überfüllte Seite hat keine Hierarchie, nur Dichte.

### Lesbarkeit vor Dekoration
Schwer lesbarer Text kostet Sie Leser, egal wie gut geschrieben er ist. Das sind messbare Schwellen, keine Meinungen.
| Fließtextgröße | 16–18 px auf dem Handy | Unter 16 px zoomt iOS beim Formularfokus, und kleiner Text verliert Leser |
| Zeilenlänge | 55–75 Zeichen | Längere Zeilen lassen das Auge beim Rücksprung die Stelle verlieren |
| Zeilenhöhe | 1,5–1,7 im Fließtext | Enger Durchschuss senkt die Lesegeschwindigkeit messbar |
| Textkontrast | Mindestens 4,5:1, besser 7:1 | WCAG AA; Grau auf Grau versagt draußen am Handy |
| Kontrast von Bedienelementen | 3:1 gegen den Hintergrund | Nutzer müssen sehen, wo ein Eingabefeld endet |
| Absatzlänge | Drei bis vier Zeilen | Lange Blöcke werden auf dem Handy übersprungen |
Prüfen Sie den Kontrast gegen den tatsächlichen Hintergrund, einschließlich Verläufen und Bildern. Ein Wert, der auf Weiß besteht, kann auf dem Hero-Bild scheitern, über dem er tatsächlich liegt.

### Formulare für den Abschluss gestalten, nicht für Symmetrie
In Formularen werden die meisten Website-Ziele tatsächlich erreicht, und dort landet die wenigste Designaufmerksamkeit. Jedes Feld, das Sie hinzufügen, kostet Abschlüsse; jedes Feld, das Sie entfernen, ist geschenktes Geld, wenn Sie die Daten nicht brauchten.
- Fragen Sie das Minimum ab, das Sie zum Antworten brauchen. Den Rest fragen Sie in der Antwort.
- Eine Spalte. Zweispaltige Formulare führen zu übersprungenen Feldern und sind mobil schlechter.
- Beschriftungen über den Feldern, immer sichtbar — reine Platzhalter-Labels verschwinden beim Tippen.
- Richtige Eingabetypen und Autocomplete-Attribute, damit Handys die passende Tastatur zeigen und ausfüllen anbieten.
- Validieren Sie beim Verlassen des Feldes, nicht bei jedem Tastendruck, und setzen Sie den Fehler neben das Feld.
- Leeren Sie das Formular bei einem Fehler nie. Verlorene Eingaben sind der häufigste Abbruchgrund.
- Sagen Sie nach dem Absenden, was als Nächstes passiert und wie lange es dauert.

### Was Geschmack ist und was nicht
Klarheit über diesen Unterschied spart viel Zeit in Abnahmemeetings. Die linke Spalte ist diskutierbar; die rechte nicht.
| Farbpalette | Kontrastwerte gegen den echten Hintergrund |
| Schriftwahl | Fließtextgröße und Zeilenlänge |
| Illustrationsstil | Ob Bilder sinnvollen Alt-Text haben |
| Hero-Bild oder keines | Ob die primäre Aktion ohne Scrollen sichtbar ist |
| Runde oder eckige Ecken | Ob Fokuszustände für Tastaturnutzer sichtbar sind |
| Animationsstil | Ob Animation prefers-reduced-motion beachtet |
| Layoutdichte | Ob Touch-Ziele mindestens 44 px groß sind |

Q: Zählt „above the fold“ noch?
A: Nicht als Regel, dass alles Wichtige dorthin passen muss — Menschen scrollen, und das seit zwanzig Jahren. Wichtig ist, dass der obere Seitenbereich innerhalb weniger Sekunden beantwortet: „Was ist das und ist es für mich?“ Tut er das, scrollen Besucher für das Detail. Tut er es nicht, wird weiter unten nichts gelesen.

Q: Wie viele Schriften sollte eine Website verwenden?
A: Meist eine oder zwei Familien, wobei Schnitte die Arbeit übernehmen, die zusätzliche Familien machen würden. Der praktische Grund ist Performance, nicht Geschmack: Jede weitere Familie und jeder weitere Schnitt ist eine zusätzliche Datei, die geladen werden muss, bevor Text korrekt erscheint. Eine gut gewählte Familie mit drei Schnitten deckt fast jede Website ab.

Q: Lohnt sich ein Dark Mode?
A: Er lohnt sich, wenn Sie ihn von Anfang an mit Design-Tokens umsetzen können, wo er sehr wenig kostet. Ihn auf eine fertige Website nachzurüsten bedeutet, jede Farbe, jedes Bild und jeden Schatten zu prüfen, und das ist ein echtes Projekt. Wenn Sie ihn unterstützen, respektieren Sie standardmäßig die Systemeinstellung und lassen Sie den Nutzer sie überschreiben.

Q: Sollte das Design dem der Wettbewerber gleichen?
A: Konventionen sollten übereinstimmen — Navigation oben, Warenkorb oben rechts, Logo verlinkt zur Startseite —, weil deren Bruch Verständnis kostet, ohne etwas zu bringen. Alles oberhalb der Konventionen ist Ihr Unterscheidungsraum. Der Fehler ist, das Layout eines Wettbewerbers komplett zu kopieren, denn damit importiert man Entscheidungen, die zu dessen Inhalten passten und nicht zu Ihren.

## Ein Anforderungsdokument für die Website schreiben
https://websitedevelopment.biz/de/guides/website-anforderungsdokument
Aktualisiert am 2026-08-07 · Website-Planung

Ein Anforderungsdokument existiert, damit Sie und die Entwicklerin dieselbe Website beschreiben. Es muss nicht lang sein. Ein vierseitiges Briefing, das beide Seiten tatsächlich gelesen haben, verhindert mehr Streit als eine fünfzigseitige Spezifikation, die keiner zu Ende gebracht hat.

Dieser Leitfaden behandelt, was hineingehört, was Sie weglassen können und wie Sie den wichtigsten Abschnitt schreiben: was das Projekt nicht ist.

### Wozu ein Anforderungsdokument dient
Es hat drei Aufgaben: mehreren Entwicklern erlauben, dasselbe zu bepreisen, damit die Angebote vergleichbar sind; Ihnen eine Referenz geben, wenn es Uneinigkeit über den Umfang gibt; und Sie zwingen, Entscheidungen zu treffen, solange sie noch billig sind.

Es ist kein Design-Briefing und keine technische Spezifikation. „Die Website muss schnell laden“ ist eine Anforderung; „Redis für Object Caching verwenden“ ist eine Lösung, und sie zu wählen, bevor Sie jemanden beauftragt haben, entzieht Ihnen genau die Expertise, für die Sie zahlen.
- Nennen Sie Ergebnisse und Randbedingungen, keine Umsetzungen.
- Schreiben Sie es so, dass jemand außerhalb Ihrer Organisation es ohne Rückruf versteht.
- Halten Sie es kurz genug, um es in einem Zug zu lesen — vier bis acht Seiten genügen für die meisten Websites.
- Datieren und versionieren Sie es, denn es wird sich ändern.

### Die Abschnitte, die sich lohnen
Diese Struktur deckt die meisten Website-Projekte ab. Lassen Sie weg, was nicht zutrifft, statt es aufzufüllen.
| Hintergrund | Was die Organisation tut und warum die Website gebaut oder ersetzt wird |
| Ziele | Primäres Ziel, sekundäre Ziele und wie Erfolg gemessen wird |
| Zielgruppe | Zwei oder drei Besuchergruppen und die Frage, mit der jede ankommt |
| Seitenstruktur | Jede Seite, in Bereiche gruppiert, als startkritisch oder später markiert |
| Funktionale Anforderungen | Formulare, Suche, Konten, Filter, Buchung, Checkout — was jedes leisten muss |
| Integrationen | Jedes externe System, mit Ansprechpartner und Link zur API-Dokumentation |
| Inhalt | Wer welche Seite schreibt, wer freigibt, wann sie fällig ist |
| Nicht-funktional | Performance, Barrierefreiheit, Browser- und Geräteunterstützung, Sprachen, Sicherheit |
| Nicht im Umfang | Ausdrücklich ausgeschlossene Arbeit — der wertvollste Abschnitt |
| Randbedingungen | Budgetrahmen, Termin und feste Vorgaben (bestehender Host, vorgeschriebenes CMS) |

### Schreiben Sie prüfbare Anforderungen
Eine Anforderung ist nützlich, wenn beide Seiten hinterher übereinstimmen können, ob sie erfüllt wurde. „Die Website sollte schnell sein“ ist nicht prüfbar; „die Produktlistenseite erreicht Largest Contentful Paint unter 2,5 Sekunden auf einem Android-Mittelklassegerät über 4G“ schon.

Dasselbe gilt für Funktionen. „Ein Kontaktformular“ lässt jede Frage offen, auf die es ankommt.
| Ein Kontaktformular | Sechs Felder, Spamschutz, Speicherung in der Datenbank, Mail an zwei Adressen, DSGVO-Einwilligung |
| Mobilfreundlich | Nutzbar ab 320 px, alle Touch-Ziele mindestens 44 px, kein horizontales Scrollen |
| Schnell | LCP unter 2,5 s und CLS unter 0,1 auf den vier Haupt-Templates, gemessen über 4G |
| Barrierefrei | WCAG 2.2 AA auf Templates, geprüft per Tastatur- und Screenreader-Durchgang |
| SEO-freundlich | Editierbare Titel und Beschreibungen, saubere URLs, Sitemap, strukturierte Daten bei Artikeln |
| Mehrsprachig | Drei Sprachen, übersetzte URLs, hreflang-Tags, Sprachumschalter auf jeder Seite |

### Die Ausschlussliste
Das ist der Abschnitt, den alle überspringen, und derjenige, der das Projekt rettet. Schreiben Sie die Dinge auf, die eine vernünftige Person als enthalten annehmen könnte, und sagen Sie klar, dass sie es nicht sind — oder nehmen Sie sie auf, falls sie es sein sollten.

Das vor Eintreffen der Angebote zu tun bedeutet, dass die Angebote vergleichbar sind. Es danach zu tun bedeutet Streit.
- Texterstellung und Korrektorat — gehen Sie davon aus, dass es Ihre Sache ist, sofern das Angebot nichts anderes sagt.
- Fotografie, Illustration und Stock-Lizenzen.
- Inhaltspflege: Wer tippt 200 Produkte ins CMS?
- E-Mail-Einrichtung, DNS-Umzug und Übertragung des Hosting-Kontos.
- Laufende SEO-Arbeit, abgegrenzt von der technischen SEO-Einrichtung zum Start.
- Schulung, Dokumentation und Übergabe.
- Support nach dem Start: was abgedeckt ist, wie lange, und was abgerechnet wird.
Eine gute Entwicklerin ergänzt diese Liste unaufgefordert. Wer ohne Rückfragen allem zustimmt, hat sie meist nicht gelesen, und die Uneinigkeit ist lediglich vertagt.

Q: Wie lang sollte ein Anforderungsdokument sein?
A: Vier bis acht Seiten decken die meisten Unternehmenswebsites ab. Shops und Anwendungen werden länger, weil der funktionale Teil wächst, aber jenseits von zwanzig Seiten fragen Sie sich, was da beschrieben wird, das ein Gespräch nicht klären könnte. Der Maßstab ist, ob beide Seiten es gelesen haben, nicht ob es vollständig ist.

Q: Sollte ich die Technologie vorgeben?
A: Nur wo Sie eine echte Randbedingung haben: ein vorhandenes CMS, das Ihr Team kennt, ein Host, bei dem Sie bleiben müssen, ein System, das angebunden werden muss. Ansonsten nennen Sie das Ergebnis und lassen die Beauftragten die Umsetzung wählen. Einen Stack vorzugeben, den Sie nicht verstehen, verengt Ihre Optionen und liefert eine schlechtere Antwort.

Q: Brauche ich zusätzlich Wireframes?
A: Grobe Wireframes für die drei oder vier wichtigsten Templates nehmen mit sehr wenig Aufwand viel Mehrdeutigkeit heraus und sind weit billiger zu ändern als ein Design. Sie ersetzen die schriftlichen Anforderungen nicht — sie zeigen Anordnung, nicht Verhalten —, aber beides zusammen lässt sich deutlich genauer bepreisen als jedes für sich.

Q: Was, wenn ich manche Antworten nicht kenne?
A: Schreiben Sie „wird noch entschieden“ und benennen Sie, wer entscheidet und bis wann. Eine ehrliche Lücke mit Verantwortlichem ist in Ordnung; eine erfundene Antwort nicht, denn das Angebot wird darauf aufbauen. Entwickler bepreisen Unsicherheit ohnehin, also bringt es meist eine bessere Zahl, die Unsicherheit sichtbar zu machen, statt sie zu verstecken.

## Der Webdesign-Prozess, Schritt für Schritt
https://websitedevelopment.biz/de/guides/webdesign-prozess
Aktualisiert am 2026-08-07 · Webdesign

Webdesign ist nicht der Teil, in dem jemand Farben aussucht. Es ist eine Abfolge von Entscheidungen, die sich von „wofür ist diese Website“ bis auf „dieser Button, diese Größe, diese Beschriftung“ verengt, und jeder Schritt ist billiger zu ändern als der darauffolgende.

Dieser Leitfaden behandelt die Phasen der Reihe nach, was jede hervorbringt, und die zwei Punkte, an denen Designprojekte zuverlässig steckenbleiben.

### Discovery: was das Design erreichen muss
Vor allem Visuellen braucht die Designerin dasselbe wie die Entwicklung: das primäre Ziel, die Zielgruppe, die Seitenstruktur und die Randbedingungen. Fängt sie ohne diese an, bekommen Sie ein Design, das im Portfolio gut aussieht und scheitert, sobald echte Inhalte eintreffen.

Diese Phase erzeugt Einigkeit, keine Artefakte. Eine einseitige Zusammenfassung, die beide Seiten akzeptieren, genügt.
- Die eine Handlung, die die Website antreiben muss, und wie sie gemessen wird.
- Zwei oder drei Besuchergruppen und die Frage, mit der jede ankommt.
- Markenvorgaben, die wirklich existieren: Logo, Farben, Schriften, Tonalität.
- Technische Randbedingungen: das CMS, die Plattform, die Geräte, auf die es tatsächlich ankommt.
- Beispiele für Websites, die dem Kunden gefallen — und, nützlicher, warum.

### Struktur und Wireframes
Wireframes klären Anordnung und Hierarchie ohne die Farbdiskussion. Sie beantworten, was auf jedem Template steht, in welcher Reihenfolge und was der Besucher tun soll — solange Änderungen noch Minuten kosten.

Wireframen Sie die Templates, nicht jede Seite. Die meisten Websites haben vier bis acht verschiedene Templates und dutzende daraus gebaute Seiten.
| Startseite | Was ist das und ist es für mich? | In den richtigen Bereich gehen |
| Bereichs-Hub | Was steckt hier drin? | Einen Eintrag wählen |
| Artikel / Detail | Die eigentliche Antwort | Lesen, dann den nächsten Schritt gehen |
| Produkt | Ist es das Richtige und was kostet es? | In den Warenkorb legen |
| Kontakt / Formular | Wie fange ich an? | Absenden |
| Suchergebnisse | Gefunden? | Ergebnis öffnen oder verfeinern |
Wireframen Sie mit realistischen Textlängen. Ein Layout, das um eine Sechs-Wort-Überschrift gebaut ist, bricht in dem Moment, in dem eine echte vierzehn Wörter lang wird.

### Visuelles Design und das Designsystem
Visuelles Design überträgt die Marke auf die Wireframes: Typo-Skala, Farbe, Abstände, Zustände und Komponenten. Bei allem, was größer als eine Broschürenseite ist, lohnt sich ein kleines System — ein Satz Komponenten mit definierten Zuständen — statt einer Sammlung unverbundener Seitenbilder.

Der Grund ist nicht Ordnungsliebe. Ein System sagt der Entwicklung, was in den Fällen passiert, die die Mockups nicht zeigen, und diese Fälle sind der Großteil der Website.
- Eine Typo- und eine Abstandsskala, damit keine Zahl ein Einzelfall ist.
- Farb-Tokens, deren Kontrast gegen die tatsächlichen Hintergründe geprüft ist.
- Komponentenzustände: Standard, Hover, Fokus, Aktiv, Deaktiviert, Ladend, Fehler, Leer.
- Responsives Verhalten je Komponente, nicht nur eine Mobilversion der Startseite.
- Was bei zu viel Inhalt passiert und was bei keinem.

### Wo Designprojekte steckenbleiben
Zwei Fehler verursachen den Großteil der Verzögerung, und beide sind Prozessprobleme, keine Geschmacksfragen.
- Feedback ohne Verantwortlichen. Sechs Leute kommentieren, zwei widersprechen sich, und die Designerin soll schlichten. Benennen Sie eine Person, die Feedback bündelt und entscheidet.
- Inhalt, der nicht existiert. Designs werden gegen Platzhaltertext freigegeben, dann kommt der echte Text doppelt so lang und das Layout wird neu gemacht. Gestalten Sie mit echtem Inhalt, auch mit grobem echtem Inhalt.
- Unbegrenzte Korrekturrunden. Legen Sie die Zahl vorab fest — meist zwei oder drei — und was eine weitere Runde kostet. Ohne Grenze treiben Projekte, statt fertig zu werden.
- Freigabe, die keine ist. „Sieht gut aus“ in einem Meeting ist keine Freigabe. Holen Sie sie schriftlich ein, je Template, mit Datum.
Die nützlichste Frage in einer Abnahme ist nicht „gefällt es Ihnen“, sondern „hilft das dem Besucher bei dem, wofür die Website vereinbart wurde“. Geschmacksdiskussionen enden nie; Zieldiskussionen schon.

Q: Mit wie vielen Korrekturrunden sollte ich rechnen?
A: Zwei oder drei sind bei einem Template-Projekt üblich. Wichtiger als die Zahl ist, dass sie schriftlich vereinbart ist, zusammen mit den Kosten einer weiteren Runde. Unbegrenzte Korrekturen klingen großzügig und bedeuten in der Praxis, dass das Projekt nie zu einer Entscheidung kommt, weil nichts zum Festlegen zwingt.

Q: Sollten Design und Entwicklung dieselbe Person oder dasselbe Team sein?
A: Bei kleinen Projekten ist eine Person für beides effizient und spart eine Übergabe. Bei größeren sind es wirklich verschiedene Fähigkeiten, und die Trennung liefert meist bessere Arbeit — vorausgesetzt, das Design liefert ein System mit Zuständen und Responsive-Regeln statt einer Bildersammlung. Das Risiko liegt in der Übergabe, nicht in der Trennung.

Q: Brauche ich ein fertiges Design, bevor die Entwicklung beginnt?
A: Sie brauchen die Templates gestaltet, nicht jede Seite. Die Entwicklung kann starten, sobald das Designsystem und die zwei oder drei komplexesten Templates stehen; der Rest kann während der Umsetzung fertig werden. Ohne irgendetwas Geklärtes zu starten bedeutet Nacharbeit, und jede letzte Seite vor der ersten Codezeile fertigzustellen bedeutet, Leerlauf zu bezahlen.

Q: Welche Ergebnisse sollte ich am Ende bekommen?
A: Bearbeitbare Quelldateien für jedes Template und jede Komponente, eine dokumentierte Typo- und Farbskala, exportierte Assets in den Formaten, die die Umsetzung braucht, und die schriftlich festgehaltenen Responsive-Regeln. Fragen Sie vor Beginn, ob Sie die Quelldateien erhalten oder nur Exporte — der Unterschied zählt beim ersten Mal, wenn Sie eine Kleinigkeit ohne die ursprüngliche Designerin ändern müssen.

## Was kostet eine Website? Realistische Spannen nach Projekttyp
https://websitedevelopment.biz/de/guides/was-kostet-eine-website
Aktualisiert am 2026-08-07 · Website-Planung

Jede einzelne Zahl für „eine Website“ führt in die Irre, denn derselbe Begriff deckt eine fünfseitige Broschürenseite ab und einen Shop mit 4.000 Produkten und drei Systemanbindungen. Nützlich ist die Form der Spannen und was einen zwischen ihnen bewegt.

Dieser Leitfaden behandelt typische Kosten nach Projekttyp, die Faktoren, die den Preis wirklich treiben, die laufenden Kosten, die selten im Angebot stehen, und wie man zwei Angebote vergleicht, die sich um den Faktor fünf unterscheiden.

### Typische Spannen nach Projekttyp
Dies sind breite Marktspannen für professionelle Arbeit, keine Angebote. Regionale Sätze schwanken stark, und dasselbe Briefing kostet bei einem Solo-Freelancer weniger als bei einer Agentur mit Projektleitung und QA-Prozess — Sie kaufen unterschiedlich viel Risikoabdeckung, nicht nur unterschiedlich viel Code.
| Template- / Baukastenseite | 500 – 3.000 $ | Vorhandenes Theme, Ihre Inhalte, leichte Anpassung |
| Kleine Unternehmensseite | 3.000 – 12.000 $ | Eigenes Design, CMS, 5–15 Seiten, SEO-Grundeinrichtung |
| Mittelgroße Individualseite | 12.000 – 50.000 $ | Eigenes Designsystem, individuelle Templates, Integrationen |
| Onlineshop | 5.000 – 80.000 $+ | Plattform, Katalog, Zahlung, Versand, Steuern, Migration |
| Webanwendung | 40.000 – 250.000 $+ | Eigene Logik, Konten, Rechte, laufende Releases |
| Relaunch einer bestehenden Seite | 60–90 % eines Neubaus | Selten günstiger als neu, sobald die Migration eingerechnet ist |
Ein Relaunch ist meist kein Rabatt. Inhalte migrieren, URLs erhalten und vorhandenes Verhalten nachbauen ist Arbeit, die eine Neuentwicklung nicht hat.

### Was den Preis tatsächlich treibt
Die Seitenzahl sagt wenig über die Kosten. Zwanzig Seiten aus drei Templates sind günstiger als fünf Seiten, die alle verschieden sind. Den Preis bewegen individuelle Logik, Integrationen und Inhaltsmenge.
- Anzahl unterschiedlicher Templates, nicht Anzahl der Seiten. Jedes eigene Layout ist Design plus Umsetzung plus QA.
- Integrationen. Jedes System, mit dem die Website sprechen muss — CRM, ERP, Zahlung, Buchung, E-Mail — bedeutet Arbeit und eine weitere Stelle, die kaputtgehen kann.
- Inhaltsmigration. 40 Seiten von Hand umzuziehen ist ein Nachmittag; 4.000 Produkte mit Bildern und Varianten ist ein eigenes Projekt.
- Sprachen. Eine zweite Sprache verdoppelt selten, ist aber nie kostenlos: Struktur, URLs, hreflang und ein Übersetzungsprozess.
- Individuelle Logik. Preisregeln, Konfiguratoren, Berechtigungen und Workflows sind, wohin Budgets tatsächlich fließen.
- Ziele für Barrierefreiheit und Performance. Von Anfang an eingeplant billiger als nachgerüstet, aber in keinem Fall null.

### Die Kosten, die nicht im Angebot stehen
Ein Umsetzungsangebot ist der Anfang der Ausgaben, nicht das Ende. Die laufenden Kosten sind einzeln klein und zusammen erheblich, und sie kommen, ob sie jemand erwähnt hat oder nicht.
| Domain | 10 – 50 $ | Achten Sie darauf, dass sie auf Ihren Namen läuft, nicht auf die Agentur |
| Hosting | 60 – 3.000 $+ | Von Shared bis Managed Cloud; ein Shop braucht mehr als eine Broschürenseite |
| SSL-Zertifikat | 0 – 200 $ | Kostenlos genügt für die meisten Websites |
| CMS- / Plattformgebühren | 0 – 30.000 $+ | E-Commerce-Plattformen nehmen oft zusätzlich einen Umsatzanteil |
| Plugins und Lizenzen | 100 – 2.000 $ | Verlängerungen vergisst man leicht, bis etwas nicht mehr funktioniert |
| Wartung und Updates | 10–20 % der Umsetzungskosten | Sicherheitspatches, Backups, kleine Korrekturen |
| Inhalt und Fotografie | Sehr unterschiedlich | Häufig der größte nicht eingeplante Posten |

### Wie man ein auffällig günstiges Angebot liest
Ein Angebot deutlich unter den anderen ist nicht automatisch schlecht, aber es beantwortet immer eine andere Frage. Finden Sie heraus, welche, bevor Sie über den Preis vergleichen.
- Fragen Sie schriftlich, was ausgeschlossen ist. Inhaltspflege, SEO-Einrichtung, Schulung und Korrekturen nach dem Start sind die üblichen Auslassungen.
- Fragen Sie, wem nach dem Start Code, Domain und Hosting-Konto gehören. Lautet die Antwort nicht „Ihnen“, ist der Preis nicht der Preis.
- Fragen Sie, wie viele Korrekturrunden enthalten sind und was Runde vier kostet.
- Fragen Sie, was passiert, wenn in Woche zwei etwas kaputtgeht: abgedeckt, stundenweise oder ein neues Projekt?
- Bitten Sie um eine Live-Website in Ihrer Größenordnung — nicht die schönste Arbeit, die ähnlichste.
- Vergleichen Sie die Summe für das erste Jahr, nicht die Umsetzungszahl. Genau dort hören günstige Angebote auf, günstig zu sein.
Die zwei Angebote, über die man sich Sorgen machen sollte, sind das, welches ein Drittel der anderen beträgt, und das, welches eine Stunde nach dem Briefing eintrifft. Beide bedeuten meist, dass das Briefing nicht gelesen wurde.

Q: Warum unterscheiden sich Angebote zum selben Briefing so stark?
A: Weil sie unterschiedlich viel Risiko und unterschiedlich viel Prozess bepreisen. Ein Solo-Entwickler kalkuliert die eigenen Stunden. Eine Agentur kalkuliert Designer, Entwickler, Projektleitung, QA und die Kosten der Reparatur, falls die Person, die es gebaut hat, geht. Keines ist falsch; sie passen zu verschiedenen Projekten und verschiedener Toleranz für Pannen.

Q: Ist eine Website im Monatsabo ein gutes Geschäft?
A: Es kommt darauf an, was passiert, wenn Sie aufhören zu zahlen. Manche Abos bündeln Umsetzung, Hosting und Wartung, und Sie behalten nichts, wenn Sie gehen — über drei oder vier Jahre kostet das meist mehr, als eine Website zu besitzen. Andere sind echte Managed Services mit Ausstiegspfad. Fragen Sie, was Ihnen gehört und was bei Kündigung passiert, bevor Sie die Monatszahl mit irgendetwas vergleichen.

Q: Sollte ich eine Anzahlung leisten?
A: Eine Anzahlung ist üblich — typisch 30–50 % vorab, der Rest an Meilensteinen oder zum Start. Nicht üblich ist, die volle Summe zu zahlen, bevor irgendetwas existiert. Koppeln Sie Zahlungen an sichtbare Ergebnisse und machen Sie die Schlusszahlung zum Start fällig statt bei einer internen Freigabe, die Sie nicht prüfen können.

Q: Wie viel sollte ich für Wartung einplanen?
A: Rechnen Sie mit 10–20 % der Umsetzungskosten pro Jahr für eine CMS-basierte Website: Sicherheitsupdates, Plugin-Verlängerungen, Backups, kleine Inhaltsänderungen und gelegentliche Störungen. Ein Shop oder eine Anwendung braucht mehr, weil mehr in Bewegung ist. Websites, die Wartung auslassen, sparen das Geld nicht; sie geben es später im Notfall aus.

## Website planen: Der vollständige Leitfaden zur Projektplanung
https://websitedevelopment.biz/de/guides/website-planung-leitfaden
Aktualisiert am 2026-08-07 · Website-Planung

Die meisten Website-Projekte geraten nicht in Verzug, weil der Code schwierig war. Sie geraten in Verzug, weil der Plan dünn war: Niemand hatte sich darauf geeinigt, was die Website erreichen soll, wer die Texte schreibt oder was „fertig“ bedeutet.

Dieser Leitfaden behandelt die Planungsarbeit vor Design und Umsetzung, in der Reihenfolge, in der sie tatsächlich nützlich ist, sowie die Entscheidungen, deren spätere Änderung teuer wird.

### Beginnen Sie mit einer Aufgabe, die die Website erfüllen muss
Eine Website, die alles können soll, leistet meist nichts Messbares. Schreiben Sie vor allem anderen die eine Handlung auf, die am wichtigsten ist: ein abgeschicktes Formular, ein Anruf, ein Kauf, eine Buchung, ein Download.

Alles Weitere — Seitenstruktur, Navigation, was oberhalb der Falz steht, wie viel Sie ausgeben sollten — ergibt sich aus dieser Antwort. Eine Website, deren Hauptaufgabe Anfragen sind, ist ein anderes Projekt als eine Website, die 4.000 Produkte verkaufen soll.
- Primäres Ziel: die eine Handlung, die Sie behalten würden, wenn Sie nur eine behalten dürften.
- Sekundäre Ziele: nützlich, aber nicht wert, das primäre Ziel dafür zu beschneiden.
- Wie Sie es messen: eine Zahl, die Sie nächstes Quartal prüfen können, nicht „mehr Traffic“.
- Was die Website nicht leisten muss: aufgeschrieben, damit es außerhalb des Projektumfangs bleibt.
Wenn zwei Personen in Ihrer Organisation unterschiedliche primäre Ziele nennen würden, taucht diese Uneinigkeit in Woche sechs der Umsetzung wieder auf. Klären Sie sie in Woche null, wo sie ein Meeting kostet statt einen Neubau.

### Wissen, wer ankommt und weshalb
Zielgruppenforschung muss keine formale Übung sein. Was Sie brauchen, ist eine kurze, ehrliche Beschreibung der zwei oder drei Gruppen, die tatsächlich vorbeikommen, mit welcher Frage jede ankommt und was sie vertreiben würde.
| Erstkäufer | Können die das, was ich brauche? | Kein Beleg, keine Preise, keine Klarheit |
| Bestandskunde | Wo ist das, was ich jetzt brauche? | Die Aufgabe liegt drei Klicks tief |
| Jemand, der vergleicht | Wodurch unterscheidet sich das? | Austauschbare Texte, die zu jedem Wettbewerber passen |
| Ein Bewerber | Wie ist es, hier zu arbeiten? | Keine Karriereseite oder eine veraltete |

### Entscheiden Sie die Seiten, bevor Sie das Design entscheiden
Die Seitenstruktur ist auf Papier das Billigste zu ändern und nach der Design-Freigabe eines der Teuersten. Listen Sie jede Seite auf, gruppieren Sie sie in Bereiche und markieren Sie, welche zum Start nötig sind und welche später kommen können.

Der übliche Fehler ist eine Struktur, die Ihr Organigramm abbildet statt der Aufgabe des Besuchers. Niemand sucht Ihre „Solutions-Abteilung“; die Leute suchen das, was sie brauchen.
- Listen Sie jede Seite, die Sie zu brauchen glauben, einzeln auf, ohne zu gruppieren.
- Markieren Sie jede als startkritisch oder später. Seien Sie streng: Die meisten Websites starten mit weniger Seiten als geplant.
- Gruppieren Sie die startkritischen in höchstens fünf oder sechs oberste Bereiche.
- Schreiben Sie den einen Satz auf, den jede Seite liefern muss. Gelingt das nicht, sollte die Seite wohl nicht existieren.
- Prüfen Sie, ob das primäre Ziel von jeder Hauptseite aus mit einem Klick erreichbar ist.

### Inhalt ist der kritische Pfad — planen Sie ihn zuerst
Texte, Fotos und Produktdaten halten mehr Starts auf als jedes technische Problem. Die Umsetzung ist fertig, und die Website steht sechs Wochen im Staging und wartet auf eine Über-uns-Seite.

Entscheiden Sie jetzt, wer welche Seite schreibt, wer sie freigibt und wann sie fällig ist — und nehmen Sie diese Termine so ernst wie die Entwicklungs-Meilensteine. Hat intern niemand Zeit, kalkulieren Sie einen Texter ein; das ist billiger als ein untätiges Entwicklungsteam.
- Benennen Sie für jede Textseite einen Verantwortlichen und ein Datum, nicht „Marketing“.
- Entscheiden Sie, was mit bestehenden Inhalten geschieht: migrieren, neu schreiben oder streichen. Das meiste sollte gestrichen werden.
- Buchen Sie Fotografie früh — sie hat die längste Vorlaufzeit von allem auf der Liste.
- Für einen Shop: Produktdaten vor Projektbeginn exportieren und bereinigen, nicht währenddessen.
- Einigen Sie sich, wer die endgültige Freigabe hat. Zwei gleichrangige Freigebende sind ein Terminrisiko.
Ein nützlicher Test: Wäre die Website morgen fertig, könnten Sie sie füllen? Lautet die Antwort nein, ist der Inhalt Ihre eigentliche Deadline.

### Budgetrahmen und Entscheidung über den Umsetzungsweg
Die Planung endet mit zwei Zahlen und einer Wahl: was Sie ausgeben können, wann es live sein muss und ob dies eine Template-, eine CMS- oder eine Individualentwicklung wird. Diese drei bestimmen, mit wem Sie überhaupt sprechen sollten.
| Website-Baukasten | Kleine Broschürenseite, keine ungewöhnlichen Anforderungen | Sie stoßen an eine Grenze und müssen neu anfangen |
| CMS (z. B. WordPress) | Inhaltsgetriebene Website, häufige Updates durch Nicht-Entwickler | Plugin-Wildwuchs und laufende Wartung |
| E-Commerce-Plattform | Produktverkauf, üblicher Checkout-Bedarf | Plattformgebühren und begrenzte Anpassbarkeit |
| Individualentwicklung | Die Website ist das Produkt, oder Integrationen schließen anderes aus | Höchste Kosten, und die Wartung gehört Ihnen |

Q: Wie lange sollte die Planung dauern?
A: Für eine kleine Unternehmensseite ein bis zwei Wochen echte Arbeit — nicht verstrichene Zeit. Für einen Shop oder eine Anwendung drei bis sechs Wochen, das meiste davon für Inhaltsinventur und Produktdaten statt für Dokumente. Zieht sich die Planung über Monate, ist meist das primäre Ziel nicht geklärt und die Diskussion dreht sich im Kreis.

Q: Brauche ich ein formales Anforderungsdokument?
A: Sie brauchen etwas Schriftliches, auf das beide Seiten zeigen können, aber es muss nicht lang sein. Eine Seitenstruktur, eine Liste der Funktionen im Umfang, eine Liste der ausdrücklich ausgeschlossenen Punkte und ein Inhaltsverantwortlicher je Seite verhindern mehr Streit als eine fünfzigseitige Spezifikation, die niemand liest. Die Ausschlussliste ist der Teil, den alle überspringen, und der Teil, der das Projekt rettet.

Q: Sollte ich in dieser Phase schon das Design planen?
A: Planen Sie die Struktur, nicht die Optik. Zu entscheiden, welche Seiten existieren und was jede erreichen soll, ist Planung; Farben und Schriften zu wählen, ist Design — und es vor der Struktur zu tun bedeutet, dass das Design umgebaut wird, sobald echte Inhalte eintreffen. Wireframes sind der nützliche Mittelweg.

Q: Was, wenn sich die Anforderungen mitten im Projekt ändern?
A: Das werden sie. Entscheidend ist, dass Sie vorher vereinbart haben, wie Änderungen behandelt werden: wer sie anfordern darf, wer sie bepreist und ob sie den Starttermin verschieben. Ein Projekt mit Änderungsprozess wird kontrolliert später fertig; eines ohne wird im Streit später fertig.

## Die Werkzeuge der Webentwicklung, auf die es wirklich ankommt
https://websitedevelopment.biz/de/guides/beste-webentwicklung-werkzeuge
Aktualisiert am 2026-08-07 · Website-Entwicklung

Werkzeuglisten veralten schnell und helfen jemandem, der eine Website beauftragt, selten. Was bleibt, ist der Satz *Kategorien*, den ein kompetentes Projekt nutzt, und was ihr Fehlen darüber sagt, wie das Projekt laufen wird.

Dieser Leitfaden behandelt die Werkzeugkategorien, auf die es ankommt, was jede verhindert, und die Fragen, die zeigen, ob eine Entwicklerin so arbeitet.

### Die nicht verhandelbaren Kategorien
Das sind keine Vorlieben. Ein Projekt ohne sie sammelt Risiko an, das im schlechtesten Moment auftaucht — meist wenn etwas kaputtgeht und niemand sagen kann, was sich geändert hat.
| Versionskontrolle | Verlorene Arbeit, unerklärte Änderungen, kein Zurück | „In welchem Repository liegt der Code und bekomme ich Zugang?“ |
| Staging-Umgebung | Testen in der Produktion | „Wo nehme ich ab, bevor es live geht?“ |
| Automatisiertes Deployment | Eine Person, die freitags um 18 Uhr Dateien kopiert | „Wie kommt eine Änderung in die Produktion?“ |
| Backups | Totalverlust | „Wie oft, wohin, und wann haben Sie zuletzt eines zurückgespielt?“ |
| Fehler-Monitoring | Stille Ausfälle, die wochenlang niemand bemerkt | „Wie erfahren Sie, dass etwas kaputt ist?“ |
| Verfügbarkeits-Monitoring | Es vom Kunden zu erfahren | „Wer wird alarmiert, wenn die Website ausfällt?“ |
| Abhängigkeits-Updates | Bekannte Schwachstellen bleiben bestehen | „Wie werden Sicherheitsupdates eingespielt?“ |
Das stärkste einzelne Signal ist die Antwort auf „Wie kommt eine Änderung in die Produktion?“. Wenn es dabei ums Ziehen von Dateien in einen FTP-Client geht, fehlt vermutlich alles andere auf dieser Liste auch.

### Build- und Frontend-Werkzeuge
Hier bewegt sich die Mode am schnellsten und hier ist sie für Sie als Auftraggeber am wenigsten wichtig. Es zählt das Ergebnis, nicht das Werkzeug, das es hervorgebracht hat.
- Ein Build-Schritt, der Assets minimiert, bündelt und optimiert — Seitengewicht ist ein Konversionsproblem, kein Reinheitsproblem.
- Eine Bild-Pipeline, die moderne Formate und mehrere Größen automatisch erzeugt. Von Hand exportierte Bilder werden nie aktuell gehalten.
- Ein CSS-Ansatz mit System — Variablen, Tokens, wie auch immer benannt — statt angesammelter Einzelfallregeln.
- Nur das JavaScript, das die Seite braucht. Ein Framework ist für eine Anwendung eine legitime Wahl und für eine Broschürenseite meist Ballast.
- Browser-Unterstützung schriftlich definiert. „Moderne Browser“ ist keine Spezifikation.

### Test- und Qualitätswerkzeuge
Vollständige automatisierte Testsuiten sind auf einer Marketingseite selten gerechtfertigt. Ein wenig Automatisierung auf den Pfaden, die Geld kosten, ist fast immer gerechtfertigt.
- Automatisierte Prüfungen nur auf den kritischen Pfaden: Checkout, Registrierung, das Hauptkontaktformular.
- Ein automatisch geprüftes Performance-Budget — eine Zahl, die einen Build scheitern lässt, keine Hoffnung.
- Automatisierte Barrierefreiheits-Scans in der Pipeline, im Wissen, dass sie etwa ein Drittel der Probleme finden.
- Browserübergreifende Prüfungen auf den Browsern, die Ihre Analytics tatsächlich zeigt, nicht auf einer Liste von allem.
- Ein Staging-Inhaltsbestand, der echte Textlängen abbildet, einschließlich der unbequemen.
Ein Performance-Budget ist die Automatisierung mit dem höchsten Nutzen für eine Inhaltsseite: Ohne eines steigt das Seitengewicht jeden Monat leise, und niemand ist zuständig.

### Worauf Sie Zugriff haben sollten
Unabhängig davon, welche Werkzeuge die Entwicklung bevorzugt, sollten diese Konten vom ersten Tag an auf Ihren Namen laufen. Beim Kickoff ist das weit leichter zu regeln als nach dem Ende einer Zusammenarbeit.
- Domain-Registrar — auf den Namen Ihrer Organisation, mit Ihren Abrechnungsdaten.
- Hosting-Konto, mit der Entwicklung als Nutzer statt als Eigentümerin.
- Code-Repository, mit Ihrer Organisation als Eigentümerin.
- Analytics- und Search-Console-Properties.
- Jeder Drittanbieterdienst, von dem die Website abhängt: Zahlung, E-Mail, CDN, Fehler-Monitoring.
- Eine schriftliche Liste davon, aufbewahrt dort, wo Ihr Team sie findet.

Q: Muss ich diese Werkzeuge verstehen?
A: Nein, aber Sie sollten fragen, ob es sie gibt und wer Zugriff hat. Die Fragen in der Tabelle oben beantwortet jede kompetente Entwicklerin in je einem Satz, und Zögern bei den Fragen zu Deployment und Backups ist ein echtes Signal statt einer Stilfrage.

Q: Ist ein JavaScript-Framework nötig?
A: Für eine Webanwendung meist ja. Für eine Marketing- oder Inhaltsseite meist nicht — und es kostet oft Performance ohne Nutzen, weil der Browser ein Framework laden und ausführen muss, bevor er Text anzeigt, der auch im HTML hätte stehen können. Die richtige Frage ist, welches Problem es auf Ihrer Website löst, und „das nutzen wir eben“ ist keine Antwort.

Q: Was ist ein Performance-Budget?
A: Eine vereinbarte Grenze — zum Beispiel unter 200 KB JavaScript und Largest Contentful Paint unter 2,5 Sekunden auf den Haupt-Templates —, die automatisch geprüft wird und den Build scheitern lässt, wenn sie überschritten wird. Es wirkt, weil es Performance von etwas, das alle für wichtig halten, in etwas verwandelt, das ein Deployment blockiert.

Q: Woran erkenne ich, dass die Website gewartet wird?
A: Bitten Sie um eine monatliche Notiz: was aktualisiert wurde, was gepatcht wurde, wie die Verfügbarkeit war und welche Fehler auftraten. Erzeugt eine Wartungspauschale keinen Bericht, lässt sich sorgfältige Wartung schwer von gar keiner unterscheiden, und Sie erfahren es meist während eines Vorfalls.

## Individualentwicklung vs. Templates: So entscheiden Sie
https://websitedevelopment.biz/de/guides/individualentwicklung-vs-templates
Aktualisiert am 2026-08-07 · Website-Entwicklung

Ein Template ist ein vorgefertigtes Design mit Codebasis, das Sie konfigurieren. Eine Individualentwicklung wird für Ihre Anforderungen gebaut. Templates sind billiger und schneller — bis genau zu dem Punkt, an dem Sie etwas brauchen, das das Template nicht kann, und dann sind sie teurer, als individuell zu starten es gewesen wäre.

Dieser Leitfaden behandelt, wo dieser Punkt üblicherweise liegt, wie der echte Kostenunterschied über einige Jahre aussieht, und den hybriden Weg, der zu den meisten Websites passt.

### Der ehrliche Vergleich
Beide Wege sind legitim. Die Frage ist, mit welchem Satz Einschränkungen Sie die nächsten drei Jahre lieber leben.
| Anfangskosten | Niedrig | Hoch |
| Zeit bis zum Start | Tage bis Wochen | Wochen bis Monate |
| Performance | Oft schlecht — trägt Funktionen mit, die Sie nie nutzen | So gut, wie Sie bezahlen |
| Gestalterische Eigenständigkeit | Erkennbar ein Template | Ihre |
| Ungewöhnliche Anforderungen | Sperrt sich | Von Anfang an eingeplant |
| Wartung | Hängt daran, dass es den Anbieter weiter gibt | Ihre Planung |
| Späterer Umzug | Schwer — Logik steckt in Theme-Einstellungen | Leichter — es ist Ihr Code |

### Wo Templates an eine Grenze stoßen
Die Grenze ist selten visuell. Templates lassen sich meist überzeugend umgestalten. Wogegen sie sich sperren, sind strukturelle Anforderungen, und die tauchen sechs Monate nach dem Start auf.
- Ein Inhaltstyp, den das Template nicht vorgesehen hat. Fallstudien mit strukturierten Feldern, ein Verzeichnis, ein Veranstaltungskalender mit Logik.
- Integrationen. Das Template setzt sein eigenes Kontaktformular voraus; Sie brauchen die Daten in Ihrem CRM mit Ihrer Feldzuordnung.
- Performance-Ziele. Templates liefern jede Funktion für jeden Käufer, also laden Sie einen Page Builder, eine Slider-Bibliothek und drei Icon-Fonts, die Sie nie nutzen.
- Barrierefreiheit. Sind die Komponenten des Templates nicht barrierefrei, heißt Beheben das Theme zu bearbeiten — was Updates bricht.
- Mehrsprachige Struktur. Nachträglich angeflanschte Übersetzungs-Plugins erzeugen URL-Strukturen, die später schwer rückgängig zu machen sind.
- Redaktioneller Ablauf. Mehrere Autoren, Freigaben und Terminierung liegen meist jenseits dessen, was ein Theme bietet.
Das teure Muster ist nicht, ein Template zu wählen. Es ist, ein Template zu wählen und dann zwei Jahre lang eine Entwicklerin dafür zu bezahlen, dagegen anzukämpfen.

### Gesamtkosten über drei Jahre
Allein die Umsetzungspreise zu vergleichen schmeichelt dem Template. Der relevante Vergleich enthält Lizenzen, Plugins, die Entwicklungszeit für Umgehungslösungen und das, was passiert, wenn das Theme aufgegeben wird.
| Erstumsetzung | Niedrig | Hoch |
| Theme- und Plugin-Lizenzen | Jährlich, und sie steigen | Keine |
| Entwicklung für Umgehungslösungen | Sammelt sich Jahr für Jahr an | Niedrig |
| Performance-Nachbesserung | Häufig | Selten, wenn gut gebaut |
| Größeres Versions-Upgrade | Kann Anpassungen brechen | Kontrolliert |
| Anbieter gibt das Produkt auf | Erzwungener Neubau | Nicht zutreffend |
Für eine wirklich einfache Website gewinnt das Template über drei Jahre klar. Der Umschlagpunkt kommt mit der ersten strukturellen Anforderung, die das Theme nicht hat.

### Der hybride Weg, den die meisten Websites brauchen
Der verbreitete Mittelweg ist ein eigenes Theme auf einer etablierten Plattform: Sie bekommen das CMS, das Ökosystem und die Sicherheitsupdates, und das Frontend gehört Ihnen statt einem gekauften Theme.
- Nutzen Sie ein etabliertes CMS oder eine Commerce-Plattform — bauen Sie Content-Management nicht neu.
- Bauen Sie die Frontend-Templates selbst, statt ein Theme zu kaufen. Dort leben Performance und Eigenständigkeit.
- Nutzen Sie Plugins nur für echte Standardfunktionen: Zahlung, SEO-Metadaten, Backups, Formulare.
- Schreiben Sie eigenen Code für alles, was spezifisch für Ihr Geschäft ist, damit es nicht einem Plugin-Autor ausgeliefert ist.
- Halten Sie die Zahl der Abhängigkeiten bewusst klein; jede ist ein Update, eine Lizenz und eine mögliche Sicherheitslücke.

Q: Kann ich mit einem Template anfangen und später individuell werden?
A: Ja, und das ist ein vernünftiger Plan, wenn Sie wissen, dass die Migration ein echtes Projekt ist. Halten Sie die Inhaltsstruktur vom ersten Tag an sauber und portierbar — das entscheidet, ob der spätere Umzug eine Woche oder ein Quartal dauert. Schmerzhaft macht die Migration Geschäftslogik, die in Theme-Einstellungen und Plugin-Konfiguration vergraben ist, also halten Sie dort so wenig wie möglich.

Q: Sind Templates schlecht für SEO?
A: Nicht von Natur aus, aber viele sind langsam, und Geschwindigkeit ist ein Ranking- und ein Konversionsfaktor. Die üblichen Probleme sind aufgeblähtes JavaScript, unoptimierte Bilder und Markup, das eine saubere Überschriftenstruktur und strukturierte Daten umständlich macht. Ein gut gewähltes minimales Template kann völlig in Ordnung sein; ein Page-Builder-Theme mit vierzig Modulen ist es meist nicht.

Q: Wie beurteile ich ein Template vor dem Kauf?
A: Jagen Sie die Live-Demo durch einen Performance-Test und sehen Sie sich Seitengewicht und Skriptanzahl an, nicht die Verkaufsseite. Prüfen Sie den Update-Verlauf — ein Theme mit letzter Aktualisierung vor achtzehn Monaten ist eine Belastung. Probieren Sie die Demo nur mit der Tastatur. Und schauen Sie im Support-Forum, wie der Autor auf Fehlermeldungen reagiert; das sagt Ihre nächsten drei Jahre voraus.

Q: Lohnt sich Individualentwicklung für ein kleines Unternehmen?
A: Für eine geradlinige Broschürenseite meist nicht — das Geld ist besser in Inhalte und Fotografie investiert, die das Ergebnis stärker bewegen. Sie lohnt sich, sobald die Website etwas tut, das für Ihr Geschäft spezifisch ist: ein Konfigurator, ein ungewöhnlicher Buchungsablauf, eine Anbindung an das System, mit dem Sie den Betrieb führen. Eigenständiges Aussehen allein rechtfertigt den Unterschied selten.

## Der Webentwicklungsprozess erklärt
https://websitedevelopment.biz/de/guides/webentwicklung-prozess
Aktualisiert am 2026-08-07 · Website-Entwicklung

Jede Webentwicklungs-Methodik ordnet dieselben Phasen anders an. Die Phasen selbst zu verstehen — was jede hervorbringt und was sie abschließt — ist nützlicher als der Name der Methodik, denn daran erkennen Sie, ob das Projekt dort steht, wo es stehen sollte.

Dieser Leitfaden behandelt die sieben Phasen, typische Dauern für eine mittelgroße Website und wie eine echte Freigabe bei jeder aussieht.

### Die sieben Phasen
Die Dauern hier unterstellen eine mittelgroße Individualwebsite mit einem kleinen Team. Sie dehnen sich weit stärker mit Inhaltsmenge und Integrationen als mit der Seitenzahl.
| 1. Discovery | Ziele, Zielgruppe, Umfang, Randbedingungen | 1–2 Wochen |
| 2. Struktur | Seitenstruktur, Inhaltsmodell, Wireframes | 1–2 Wochen |
| 3. Design | Templates, Komponentensystem, Responsive-Regeln | 2–4 Wochen |
| 4. Umsetzung | Funktionierende Templates, CMS, Integrationen | 4–10 Wochen |
| 5. Inhalt | Echte Texte, Bilder und Daten im System | Läuft parallel — oft die längste |
| 6. Test | Funktional, browserübergreifend, Performance, Barrierefreiheit | 1–2 Wochen |
| 7. Launch | Live-Website, Weiterleitungen, Monitoring, Übergabe | 2–5 Tage |
Phase 5 ist die, die überzieht. Sie ist als parallel gezeichnet, weil sie in Phase 2 beginnen sollte, nicht weil sie klein wäre.

### Was jede Phase abschließt
Eine Phase ist nicht fertig, weil Zeit vergangen ist. Sie ist fertig, wenn etwas Bestimmtes schriftlich von jemandem mit Befugnis vereinbart wurde. Ohne das läuft die Arbeit auf einem Fundament weiter, das sich noch bewegen kann.
- Discovery: ein unterzeichneter Umfang mit ausdrücklicher Ausschlussliste.
- Struktur: eine freigegebene Seitenstruktur und ein Inhaltsmodell mit Feldnamen, die Ihr Team versteht.
- Design: freigegebene Templates für jedes eigenständige Layout, einschließlich Mobil- und Leerzuständen.
- Umsetzung: jedes Template auf Staging mit realistischem Inhalt vorgeführt.
- Inhalt: jede startkritische Seite gefüllt und von einer benannten Person Korrektur gelesen.
- Test: eine vereinbarte Fehlerliste, aufgeteilt in Startblocker und Korrekturen nach dem Start.
- Launch: eine abgearbeitete Startcheckliste und eine bestätigte Zugangsübergabe.

### Wasserfall, agil oder etwas dazwischen
Der eigentliche Unterschied liegt darin, wann der Umfang fixiert wird. Projekte mit festem Umfang lassen sich präzise bepreisen und gehen schlecht mit Änderungen um; iterative Projekte gehen gut mit Änderungen um und können keine feste Gesamtsumme zusagen. Die meiste Website-Arbeit liegt dazwischen: fester Umfang bis zum Start, danach iterativ.
| Preis | Vorab bekannt | Satz je Sprint oder je Monat |
| Änderung | Formaler Änderungsantrag, neu bepreist | Durch Neupriorisierung des Backlogs aufgefangen |
| Am besten für | Klare, stabile Anforderungen | Produkte in Entwicklung und unklare Anforderungen |
| Ihr Risiko | Für etwas zahlen, das nicht mehr passt | Kosten laufen ohne harten Stopp |
| Braucht von Ihnen | Entscheidungen vorab | Dauerhafte Verfügbarkeit zum Priorisieren |
Hüten Sie sich vor Festpreis bei vagem Umfang. Das ist die schlechteste Kombination: Die Entwicklung schützt ihre Marge, indem sie Mehrdeutigkeit eng auslegt, und jede Klärung wird zur Verhandlung.

### Wo der Prozess üblicherweise schiefgeht
Dieselben vier Fehler verursachen die meisten Überschreitungen, und keiner davon ist technisch.
- Design gegen Platzhalterinhalt freigegeben. Der echte Text kommt doppelt so lang und das Layout wird neu gebaut.
- Integrationen zu spät entdeckt. „Es muss auch mit unserem Warenwirtschaftssystem sprechen“ in Woche acht ist ein neues Projekt, keine Änderung.
- Kein einzelner Entscheider. Feedback kommt von fünf Leuten, zwei widersprechen sich, und niemand hat die Befugnis zu entscheiden.
- Tests als Phase statt als Gewohnheit. Fehler, die in Woche zehn gefunden und in Woche drei eingebaut wurden, kosten ein Vielfaches.

Q: Wie lange dauert eine typische Website?
A: Eine kleine Template-Website zwei bis vier Wochen. Eine mittelgroße Individualwebsite typischerweise drei bis fünf Monate von Anfang bis Ende. Shops und Anwendungen dauern länger. Die Variable, die das am stärksten bewegt, ist nicht die Codekomplexität, sondern die Verfügbarkeit von Inhalten und die Entscheidungsgeschwindigkeit auf Kundenseite.

Q: Können Phasen sich überlappen?
A: Manche sollten es. Inhalt sollte während der Struktur beginnen, und Tests sollten die ganze Umsetzung begleiten statt nur am Ende zu stehen. Was sich nicht überlappen sollte, sind Design und Umsetzung desselben Templates — gegen ein Design zu bauen, das sich noch bewegt, garantiert Nacharbeit und ist die häufigste Quelle von „das haben wir doch schon gebaut“-Diskussionen.

Q: Was, wenn wir mitten im Projekt etwas ändern müssen?
A: Rechnen Sie damit und vereinbaren Sie den Mechanismus vorab: wer eine Änderung anfordern darf, wer sie bepreist und ob sie den Starttermin verschiebt. Kleine Änderungen, die still aufgefangen werden, sind der Weg, auf dem ein Projekt einen Monat abdriftet, ohne dass jemand sagen kann, wann. Ein schriftliches Änderungsprotokoll löst das meiste davon.

Q: Sollte ich je Phase zahlen?
A: Meilensteinzahlungen, die an prüfbare Ergebnisse gekoppelt sind, sind für beide Seiten die fairste Struktur — typisch eine Anzahlung, dann Zahlungen bei Designfreigabe, Fertigstellung und Start. Vermeiden Sie vollständige Vorauszahlung und vermeiden Sie Zahlung erst bei Fertigstellung, was das gesamte Liquiditätsrisiko auf die Entwicklung schiebt und Sie meist mehr kostet.

## Wie funktioniert Webentwicklung? Der vollständige Ablauf
https://websitedevelopment.biz/de/guides/wie-funktioniert-webentwicklung
Aktualisiert am 2026-08-07 · Website-Entwicklung

Von außen kann Webentwicklung wie eine lange Stille aussehen, gefolgt von einer fertigen Website. In Wirklichkeit ist es eine Abfolge von Umgebungen, Kontrollpunkten und Entscheidungen, und die Kundenseite hat an nahezu jedem davon Pflichten.

Dieser Leitfaden behandelt, wie ein Projekt tatsächlich läuft, wonach Sie wann gefragt werden, und die Kontrollpunkte, an denen ein Problem noch billig zu beheben ist.

### Umgebungen: wo die Website lebt, bevor sie live ist
Fast jedes professionelle Projekt betreibt drei Kopien der Website. Zu wissen, welche Sie gerade ansehen, verhindert sehr viel Verwirrung bei der Abnahme.
| Lokal | Die Entwicklung | Tagesarbeit; die sehen Sie nie |
| Staging | Sie und die Entwicklung | Abnahme, Tests und Freigabe — für Suchmaschinen gesperrt |
| Produktion | Besucher | Die Live-Website |
Auf Staging eingegebene Inhalte erscheinen nicht automatisch in der Produktion, sofern das Projekt nicht auf Migration ausgelegt ist. Fragen Sie früh, denn 200 Produkte zweimal einzutippen ist ein reales Risiko.

### Die Abfolge einer typischen Umsetzung
Die Bezeichnungen unterscheiden sich zwischen Teams, aber die Reihenfolge ist recht einheitlich, weil jeder Schritt auf dem vorherigen aufbaut.
- Kickoff. Anforderungen bestätigt, Zugänge erteilt, Ansprechpartner benannt, Termine vereinbart.
- Setup. Repository, Umgebungen, CMS oder Framework installiert, Deployment-Pipeline.
- Templates. Das Design wird zu funktionierenden Templates, meist das komplexeste zuerst.
- Inhaltsmodellierung. Felder und Inhaltstypen, damit Ihr Team ohne Layoutschäden bearbeiten kann.
- Integrationen. Zahlung, CRM, E-Mail, Analytics — jede braucht Zugangsdaten von Ihnen.
- Inhaltspflege. Ihre oder deren, je nachdem, was im Angebot stand.
- Tests. Funktional, browserübergreifend, Performance, Barrierefreiheit.
- Prüfungen vor dem Start. Weiterleitungen, robots, Sitemap, Analytics, Backups.
- Launch. DNS-Umstellung, Verifikation, Monitoring.
- Nach dem Start. Korrekturen, Übergabe, Schulung, dann Wartung.

### Was Ihre Seite liefern muss, und wann
Die meisten Verzögerungen, die wie Entwicklungsverzögerungen aussehen, sind Wartezeiten auf den Kunden. Das sind die Punkte, die bereitliegen sollten, bevor danach gefragt wird, denn jeder blockiert Arbeit, wenn er zu spät kommt.
| Domain- und DNS-Zugang | Setup | Der Start lässt sich nicht terminieren |
| Markenmaterial und Logodateien | Templates | Platzhalter-Branding durch die ganze Abnahme |
| Seiteninhalte und Bilder | Inhaltspflege | Der häufigste Grund für einen verpassten Starttermin |
| Produktdaten | Inhaltspflege | Der Shop-Aufbau steht komplett still |
| Zugangsdaten Dritter | Integrationen | Integrationsarbeit ist mitten im Sprint blockiert |
| Feedback zu jeder Abnahme | Jeder Kontrollpunkt | Nacharbeit, weil die Umsetzung weitergelaufen ist |
| Rechtsseiten | Vor dem Start | Start verschoben wegen einer Datenschutzerklärung |

### Kontrollpunkte, an denen ein Problem noch billig ist
Die Änderungskosten steigen im Projektverlauf stark. Das sind die Momente, in denen man richtig hinsehen sollte statt zu überfliegen, denn nach jedem kostet dieselbe Änderung ein Vielfaches.
- Nach den Wireframes: Struktur und Priorität sind noch gratis zu ändern.
- Nach dem ersten gebauten Template: hier zeigt sich, ob das Design echte Inhalte überlebt.
- Nach der Inhaltsmodellierung: bearbeiten Sie selbst eine Seite. Ist es jetzt umständlich, bleibt es jahrelang umständlich.
- Nach der ersten Integration: prüfen Sie, ob die Daten dort landen, wo Ihr Team tatsächlich arbeitet.
- Auf Staging mit echten Inhalten: der letzte Punkt, an dem Layoutprobleme billig sind.
- Vor der DNS-Umstellung: Weiterleitungen, Analytics und Formulare geprüft.
Die Abnahme auf dem Handy ist nicht optional. Die meisten Websites bekommen den Großteil ihres Traffics von Handys, und reine Desktop-Abnahme ist der Weg, auf dem mobile Probleme in die Produktion gelangen.

Q: Wie viel meiner Zeit wird das Projekt kosten?
A: Mehr, als die meisten einplanen. Rechnen Sie mit einem wöchentlichen Kontrollpunkt von dreißig bis sechzig Minuten, plus Inhaltsarbeit, die eher in Tagen als in Stunden gemessen wird. Der stärkste einzelne Prädiktor für einen pünktlichen Projektabschluss ist, ob die Kundenseite eine Person mit Entscheidungsbefugnis und Zeit zur Abnahme hat.

Q: Was ist ein Sprint und muss mich das interessieren?
A: Ein Sprint ist ein fester Zeitraum — meist eine oder zwei Wochen —, in dem ein vereinbartes Arbeitspaket fertiggestellt und Ihnen gezeigt wird. Er interessiert Sie, weil er den Rhythmus der Entscheidungen definiert: Feedback während eines Sprints ist billig, Feedback drei Sprints später ist Nacharbeit. Arbeitet Ihre Entwicklung nicht in Sprints, wollen Sie aus demselben Grund trotzdem einen regelmäßigen Kontrollpunkt.

Q: Kann ich Fortschritt sehen, bevor die Website fertig ist?
A: Ja, und Sie sollten. Fordern Sie ab dem ersten Template Staging-Zugang an. Halbfertige Arbeit zu sehen ist unbequem, aber weit besser als eine Enthüllung am Ende, wenn strukturelles Feedback teuer ist. Rechnen Sie damit, dass es unfertig aussieht — genau darum sieht man früh hin.

Q: Was passiert unmittelbar nach dem Start?
A: Ein kurzer Zeitraum — üblich sind zwei bis vier Wochen —, in dem kleine Korrekturen abgedeckt sind, dann der Übergang in eine Wartungsvereinbarung oder in gar nichts. Klären Sie vorab, welches von beidem, was als Korrektur statt als neue Anforderung zählt und wen man außerhalb der Geschäftszeiten erreicht, wenn die Website ausfällt. „Das regeln wir später“ ist der Weg, auf dem Websites ungewartet enden.

## Was ist Webentwicklung? Ein vollständiger Leitfaden
https://websitedevelopment.biz/de/guides/was-ist-webentwicklung
Aktualisiert am 2026-08-07 · Website-Entwicklung

Webentwicklung ist die Arbeit, aus einem Design und einem Satz Anforderungen eine laufende Website zu machen: das Markup und die Gestaltung, die ein Besucher sieht, die Serverlogik und die Daten dahinter, sowie das Deployment und die Wartung, die alles am Laufen halten.

Dieser Leitfaden behandelt, was der Begriff einschließt, wie er sich von Webdesign unterscheidet, was die Aufteilung in Frontend und Backend in der Praxis bedeutet und welche Teile ein konkretes Projekt braucht.

### Was der Begriff umfasst
„Webentwicklung“ wird für alles verwendet, von der Installation eines Themes bis zum Bau einer maßgeschneiderten Anwendung. Gleich bleibt die Abfolge: Anforderungen werden zu Templates, Templates werden zu Seiten, Seiten bekommen Daten, und das Ganze wird ausgerollt, gemessen und gewartet.

Design entscheidet, wie es aussieht und wie es sich verhält. Entwicklung lässt es existieren, schnell laufen, echte Inhalte überstehen und nach dem Start weiterlaufen.
- Frontend: das HTML, CSS und JavaScript, das im Browser des Besuchers läuft.
- Backend: der serverseitige Code, die Datenbank und die APIs, die Daten liefern und speichern.
- CMS-Arbeit: Templates und Felder, damit Nicht-Entwickler Inhalte gefahrlos bearbeiten können.
- Integrationen: Zahlung, CRM, E-Mail, Analytics, Versand, Buchung, ERP.
- Infrastruktur: Hosting, Domains, Zertifikate, CDN, Backups, Deployment.
- Qualität: Tests, Performance, Barrierefreiheit, Sicherheit, Monitoring.

### Webentwicklung vs. Webdesign
Die beiden Begriffe werden oft zusammen angeboten und sind wirklich verschiedene Arbeiten. Bei kleinen Projekten macht eine Person beides; bei größeren sind es getrennte Personen, und zu wissen, was Sie einkaufen, verhindert eine ganze Kategorie von Streitfällen.
| Frage | Wie soll es aussehen und sich verhalten? | Wie wird es gebaut, damit es funktioniert? |
| Ergebnis | Wireframes, visuelle Entwürfe, ein Komponentensystem | Funktionierende Templates, Datenmodelle, eine ausgerollte Website |
| Hauptwerkzeuge | Designsoftware, Prototyping-Werkzeuge | Code-Editoren, Versionskontrolle, Build-Werkzeuge, ein CMS |
| Scheitert als | Website, die verwirrt oder nicht zur Marke passt | Website, die langsam ist, ausfällt oder nicht bearbeitbar ist |
| Änderungen kosten | Minuten im Wireframe-Stadium | Stunden bis Tage, sobald gebaut |
Trennt ein Angebot beides nicht, fragen Sie, was passiert, wenn Sie bereits ein Design haben. Die Antwort sagt Ihnen, welche Arbeit tatsächlich bepreist wird.

### Frontend und Backend in der Praxis
Die Aufteilung betrifft, wo Code läuft, nicht die Senioritätsstufe. Frontend-Code wird im Browser des Besuchers ausgeführt und befasst sich daher mit Darstellung, Interaktion, Responsivität und Barrierefreiheit. Backend-Code läuft auf einem Server und befasst sich daher mit Daten, Authentifizierung, Geschäftsregeln und Integrationen.

Eine Marketingseite kann fast vollständig Frontend sein, mit einem CMS als Inhaltslieferant. Ein Shop oder eine Anwendung braucht erhebliche Backend-Arbeit, weil Geld, Bestand und Konten Regeln haben, die man einem Browser nicht anvertrauen kann.
| Broschürenseite auf einem CMS | Der Großteil der Arbeit | Nur Templates und Felder |
| Inhaltsseite mit Suche und Filtern | Hoch | Mittel — Indexierung und Abfragen |
| Onlineshop | Hoch | Hoch — Katalog, Checkout, Steuern, Abwicklung |
| Buchungs- oder Terminseite | Mittel | Hoch — Verfügbarkeit, Konflikte, Benachrichtigungen |
| Webanwendung | Hoch | Sehr hoch — Konten, Rechte, Geschäftslogik |

### Was ein Webentwicklungsprojekt tatsächlich liefert
Über „die Website“ hinaus sind dies die Ergebnisse, die im Vertrag benannt gehören — denn ihr Fehlen fällt erst auf, wenn Sie sie brauchen, meist wenn die ursprüngliche Entwicklung nicht mehr verfügbar ist.
- Der Quellcode, in einem Repository, auf das Sie Zugriff haben.
- Zugang zu Hosting, Domain und allen Drittanbieterkonten, auf Ihren Namen.
- Ein dokumentierter Weg, eine Änderung auszurollen, nicht eine Person, die weiß, wie es geht.
- Ein CMS oder Adminbereich mit den Inhaltstypen, die Ihr Team tatsächlich bearbeitet.
- Backups, die einmal wiederhergestellt wurden, damit Sie wissen, dass sie funktionieren.
- Dokumentation der Integrationen und wo deren Zugangsdaten liegen.
- Schulung oder eine Übergabesitzung für alle, die die Inhalte pflegen.
Die wertvollste einzelne Klausel in einem Webentwicklungsvertrag ist die, die sagt, dass Ihnen Code und Konten gehören. Alles andere lässt sich nachverhandeln; diese eine nicht, sobald die Zusammenarbeit endet.

Q: Ist Webentwicklung dasselbe wie Web Development?
A: Die Begriffe werden in den meisten Zusammenhängen austauschbar verwendet. „Web Development“ ist etwas breiter und schließt oft Webanwendungen und APIs ein, die keine Websites im engeren Sinne sind; „Webentwicklung“ impliziert meist eine Website mit Seiten und Inhalten. Im Briefing kommt es nicht auf die Formulierung an, sondern darauf, ob das Projekt eigene Geschäftslogik hat — das verändert Kosten und benötigte Fähigkeiten.

Q: Brauche ich eine Entwicklerin, wenn ich einen Baukasten nutze?
A: Für eine einfache Website oft nicht, und das ist eine legitime Wahl. Sie wollen trotzdem vielleicht eine für die Dinge, die Baukästen schlecht können: Performance, strukturierte Daten, Anbindung an Ihre bestehenden Systeme und den späteren Umzug. Ein verbreitetes Muster ist, es selbst zu bauen und für ein konkretes Problem jemanden hinzuzuholen statt für die ganze Website.

Q: Was ist ein Fullstack-Entwickler?
A: Jemand, der sowohl am Frontend als auch am Backend arbeitet. Für kleine und mittelgroße Website-Projekte ist eine kompetente Fullstack-Person meist die effizienteste Besetzung, weil die Übergabekosten zwischen zwei Spezialisten den Tiefenvorteil übersteigen. Bei großen Projekten lohnt sich die Spezialisierung, weil die nötige Tiefe auf jeder Seite schneller wächst, als eine Person sie abdecken kann.

Q: Wie viel einer Website ist Code und wie viel Inhalt?
A: Nach Aufwand ist Inhalt meist die größere Hälfte und fast immer das Terminrisiko. Eine Umsetzung kann fertig sein und die Website trotzdem Wochen vom Start entfernt, weil Produktbeschreibungen, Fotos und Rechtsseiten nicht geschrieben sind. Planen Sie den Inhalt mit derselben Ernsthaftigkeit wie die Entwicklungs-Meilensteine, und der Starttermin wird erreichbar.