Individuelle Weblösungen
Eine Weblösung ist individuell, wenn sie sich an Ihrem Geschäft ausrichtet und nicht umgekehrt. Das klingt selbstverständlich, ist es aber nicht: Der Großteil der Projekte, die bei uns landen, scheitert nicht an der Optik, sondern daran, dass ein Baukasten oder ein gekauftes Theme irgendwann an eine Grenze stößt – eine Schnittstelle zur Warenwirtschaft, ein Freigabeprozess für Inhalte, ein Formular mit Logik, eine zweite Sprache.
Wann sich der Aufwand lohnt – und wann nicht
Es gibt gute Gründe, keine individuelle Lösung zu bauen. Wenn Sie eine Handvoll Seiten brauchen, keine Anbindungen an andere Systeme haben und Inhalte selten ändern, ist ein solides Standard-Theme auf einem gängigen Content-Management-System die wirtschaftlichere Entscheidung. Wir sagen das auch, wenn wir dadurch ein kleineres Projekt bekommen.
Individuell wird es sinnvoll, sobald mindestens einer dieser Punkte zutrifft:
- Daten müssen zwischen Systemen fließen – ERP, CRM, Warenwirtschaft, Buchhaltung, ein Buchungs- oder Ticketsystem.
- Mehrere Personen pflegen Inhalte und brauchen unterschiedliche Rechte, Vorschauen oder Freigaben.
- Die Seite hat eine eigene Logik: Konfiguratoren, Rechner, Filter über große Datenmengen, Kundenbereiche mit Login.
- Sie betreiben mehrere Marken, Sprachen oder Länderversionen aus einem Redaktionsbestand heraus.
- Der Wettbewerb sieht aus wie Sie, weil alle dasselbe Theme gekauft haben.
Was wir bauen
Egal, ob Onlineshop, Unternehmenswebsite, Magazin oder Plattform – der Ablauf bleibt ähnlich, der technische Unterbau nicht.
Unternehmenswebsites sind der häufigste Fall: Leistungen, Referenzen, Kontaktwege, oft dazu ein Karrierebereich mit Stellenanzeigen und Bewerbungsformular.
Onlineshops haben eigene Anforderungen an Zahlungsarten, Versandregeln, Steuerlogik und Produktdaten. Dafür gibt es eine eigene Seite: einen Onlineshop erstellen lassen.
Landingpages verfolgen ein einzelnes Ziel und werden meist gemeinsam mit einer Kampagne geplant. Wie sie aufgebaut sind, steht auf der Seite zur professionellen Landingpage.
Magazine, Blogs und Portale leben von Redaktionsprozessen: Kategorien, Autoren, geplante Veröffentlichungen, Archivseiten, die auch nach Jahren noch gefunden werden.
Interne Anwendungen laufen im Browser statt auf dem Rechner: Dashboards, Verwaltungsoberflächen, Werkzeuge für den Vertrieb. Technisch ist das der Übergang zur Webentwicklung im engeren Sinn.
Die Technologieentscheidung fällt vor dem Design
Welches System ein Projekt trägt, hängt an drei Fragen: Wie oft ändern sich Inhalte, wie viele Kanäle sollen sie ausspielen, und was muss angebunden werden?
Ein klassisches CMS wie WordPress oder TYPO3 rendert Seiten beim Aufruf und ist stark, wenn Redaktion und Ausgabe eng zusammengehören. Ein Headless-CMS trennt beides: Die Inhalte liegen in einem Redaktionssystem und werden per API abgerufen – von der Website, einer App, einem Newsletter-Tool oder einem Display in der Filiale. Der Jamstack-Ansatz baut daraus vorab statische Seiten, die ein CDN ausliefert. Das ist schnell und schwer angreifbar, verlangt aber einen Build-Prozess und passt schlecht zu Inhalten, die sich sekündlich ändern.
Keine dieser Varianten ist grundsätzlich besser. Wir entscheiden das im Projekt und begründen es, statt jedem Kunden dasselbe System zu verkaufen.
Ablauf eines Projekts
Analyse. Was ist da, was funktioniert, wo bricht es ab? Bei bestehenden Seiten sehen wir uns die Zahlen an, bevor wir etwas ändern – Einstiegsseiten, Absprünge, Suchanfragen in der Google Search Console.
Konzept und Informationsarchitektur. Seitenstruktur, Navigation, URL-Schema. Bei einem Relaunch entstehen hier die Weiterleitungen, damit bestehende Rankings nicht verloren gehen.
Gestaltung. Layout, Typografie, Komponenten. Wie Oberflächen entstehen und was dabei geprüft wird, beschreibt die Seite zum User Interface Design.
Umsetzung. Frontend, Backend, Schnittstellen, Redaktionsoberfläche. Sie sehen Zwischenstände auf einer Testumgebung, nicht erst das Ergebnis.
Launch und Betrieb. Umzug, Monitoring, Updates. Danach hört die Arbeit nicht auf, sie wird nur ruhiger.
Was wir vor jedem Launch prüfen
Ein Teil der Qualität einer Weblösung ist messbar, und diese Messungen laufen bei uns, bevor eine Seite live geht.
Die Core Web Vitals von Google bestehen aus drei Werten: LCP (Largest Contentful Paint) misst, wann der größte sichtbare Inhalt steht, INP (Interaction to Next Paint) die Reaktionszeit auf Eingaben, CLS (Cumulative Layout Shift) das Springen des Layouts während des Ladens. INP hat den früheren Wert FID im März 2024 abgelöst und misst schärfer, weil er alle Interaktionen einer Sitzung betrachtet und nicht nur die erste. Was dahintersteckt und woran es meist hängt, erklärt der Wiki-Eintrag zu Page Speed.
Dazu kommen Punkte, die kein Nutzer sieht und die trotzdem über den Erfolg entscheiden: Bilder in WebP oder AVIF statt in unkomprimiertem JPEG, HTTP/3 auf dem Server, sauber gesetzte Überschriftenebenen, Formulare mit richtigen Labels, ausreichende Kontraste, Bedienbarkeit per Tastatur. Und ein Consent-Banner, das erst nach aktiver Einwilligung Skripte nachlädt – seit dem TDDDG ist die Zustimmung vor dem Setzen nicht optionaler Zusatz, sondern Voraussetzung.
Wenn eine bestehende Seite abgelöst wird
Ein Relaunch ist kein Neubau auf leerer Fläche. Die alte Seite hat Rankings, Verlinkungen von außen, gesetzte Lesezeichen und Kampagnen, die auf bestimmte URLs zeigen. Genau daran scheitern Relaunches am häufigsten: Die neue Seite ist besser, und die Zugriffe brechen trotzdem ein.
Deshalb gehört zu jedem Umbau eine Bestandsaufnahme, bevor gestaltet wird. Welche Seiten bringen heute Besucher, welche Suchanfragen führen dorthin, welche URLs haben Verweise von anderen Websites? Aus dieser Liste entsteht eine Zuordnung: Jede alte Adresse bekommt ein neues Ziel, und zwar eines, das inhaltlich passt – nicht pauschal die Startseite. Diese Weiterleitungen werden vor dem Umschalten getestet, nicht danach.
Der zweite Punkt ist der Inhalt selbst. Bei den meisten gewachsenen Websites lohnt eine ehrliche Durchsicht: Was wird gelesen, was ist überholt, was war nie richtig? Seiten zusammenzuführen ist meist wirkungsvoller, als sie einzeln mitzuschleppen.
Betrieb, Pflege und Weiterentwicklung
Eine Weblösung ist kein Möbelstück. CMS und Erweiterungen bekommen Sicherheitsupdates, Browser ändern ihr Verhalten, Suchmaschinen ihre Bewertung. Wir übernehmen die Pflege bestehender Projekte – auch solcher, die nicht von uns stammen –, kümmern uns um Updates, Backups und Monitoring und entwickeln die Seite schrittweise weiter, statt alle fünf Jahre alles wegzuwerfen.
Wenn Ihr Projekt auf unserer Infrastruktur laufen soll, finden Sie die Details unter Webhosting. Und falls die Investition auf einmal zu groß ist: Eine Website oder einen Shop kann man auch leasen statt kaufen.
Sprechen wir über Ihr Vorhaben
Am schnellsten kommen wir weiter, wenn Sie uns grob sagen, was entstehen soll, was heute im Weg steht und bis wann es stehen muss. Alles Weitere klären wir im Gespräch – hier geht es zur Anfrage, dort können Sie auch direkt einen Termin buchen.
Unsere Kunden
