WordPress-Webdesign
Custom Themes,
statt Schablonen.
Ihr WordPress sieht aus wie zehntausend andere Seiten? Das liegt am Theme. Wir entwerfen und bauen Custom WordPress-Themes von Grund auf - eigenes Design-System, nativer Block-Editor, frei von Page-Builder- und Themeforest-Abhängigkeit. Das Ergebnis ist ein Theme, das ganz zu Ihrer eigenen Marke gehört.
Sechs Leistungen,
die ein Custom Theme ausmachen.
Ein Custom Theme gehört in eine eigene Kategorie. Hier steckt, was wir für jedes Theme standardmäßig liefern und warum jeder Punkt eine bewusste Entscheidung ist.
01 Design-System - Typografie, Farben, Spacing als Token-Foundation
02 Custom Gutenberg-Blocks - für wiederkehrende Layouts, ohne Page-Builder
03 theme.json und globale Styles - WP-native, kein proprietäres Format
04 Accessibility nach WCAG AA - Tastaturnavigation, Kontraste, Aria-Labels
05 Performance - Lazy-Loading, WebP/AVIF, Critical-CSS, kein JS-Ballast
06 Mehrsprachigkeit - WPML, Polylang oder manuell je nach Anforderung
System statt Theme Eigenes Theme,
Eigenes Theme,
eigene Regeln.
Ein Custom Theme enthält genau die Komponenten, die Ihre Inhalte brauchen, statt der zehntausend Optionen eines Universal-Themes. Das hält die Seite schnell und die Pflege einfach.
Design entsteht
im Browser.
Custom-Theme vs. Themeforest
Themeforest-Themes sind ein Kompromiss
Ein Themeforest-Theme muss für jeden funktionieren. Der Anwaltskanzlei, dem Fitnessstudio, dem Online-Shop, der Unternehmensberatung. Deshalb bringt es alles mit: zwanzig Headeralternativen, acht Footer-Varianten, drei Slider-Plugins, einen eigenen Page-Builder und irgendwo tief im Code hunderte Funktionen, die kein Mensch je aufrufen wird. Das klingt nach Flexibilität. In der Praxis ist es das Gegenteil.
Wer ein Themeforest-Theme kauft, kauft einen Kompromiss. Die Seite wird langsam, weil ungenutzte Styles und Scripts trotzdem geladen werden. Das Design wird generisch, weil die Grundstruktur für jeden passt und damit für niemanden wirklich passt. Und Pflege wird teuer, weil Updates des Theme-Anbieters eigene Anpassungen regelmäßig zerstören. Wenn der Anbieter sein Theme nach drei Jahren nicht mehr weiterentwickelt - was oft passiert - sitzt man auf einem veralteten Fundament ohne Ausweg außer Neuaufbau.
Themeforest hat seinen Platz: schnelle Landingpages, interne Tools, Projekte mit weniger als drei Monaten Lebensdauer. Für alles, das länger laufen und eine eigene Markenidentität haben soll, ist es der falsche Ausgangspunkt.
Custom-Theme - weniger ist mehr
Ein Custom-Theme enthält genau das, was das Projekt braucht: die Slider, die tatsächlich zum Einsatz kommen, das eine Header-Layout, das die Marke trägt, und sauberes Markup statt Page-Builder-Ballast. Das hat direkte Konsequenzen für Performance, Pflegbarkeit und Weiterentwicklung.
Die Seitentypen werden definiert, bevor eine Zeile Code entsteht: Startseite, Leistungsseite, Blog-Artikel, Kontaktseite - was das Projekt braucht, bekommt ein Template. Was es nicht braucht, wird nicht gebaut. Das Theme bleibt schlank und lesbar. Wenn in zwei Jahren ein neuer Entwickler einsteigt, findet er eine Codebasis, die er versteht, nicht ein Labyrinth aus Fallbacks und Feature-Flags für Anwendungsfälle, die nie existiert haben.
Wartung vereinfacht sich drastisch. Es gibt keine Abhängigkeit von einem Theme-Anbieter. WordPress-Core-Updates brechen nichts, weil das Theme sauber nach Coding Standards geschrieben ist und keine internen APIs nutzt, die gerne mal ohne Ankündigung ändern. Updates können eingespielt werden ohne Angst vor Folgeschäden.
Page-Builder vs. Block-Editor
Elementor, Divi, WPBakery - Page-Builder hatten ihre Zeit. Als Gutenberg noch nicht existierte oder nur eingeschränkt nutzbar war, waren sie eine verständliche Lösung. Das hat sich geändert. Der native WordPress-Block-Editor ist heute mächtig genug, um jeden Inhalt abzubilden, den ein normaler Auftritt braucht - und er tut es ohne eigenen Layer zwischen Inhalt und Datenbank.
Page-Builder speichern Layout-Informationen in serialisierten Feldern in der Datenbank. Das bedeutet: wenn das Page-Builder-Plugin deaktiviert wird oder seine Datenstruktur ändert, sind die Inhalte nicht mehr lesbar. Vendor-Lock-in auf Datenbankebene. Custom Blocks für den nativen Block-Editor haben dieses Problem nicht - die Blöcke sind HTML-Kommentare im Post-Content, lesbar und portierbar.
Wir bauen Custom Blocks für den Block-Editor. Jeder Block hat eine
edit-Funktion (was der Redakteur sieht) und eine
save-Funktion (was gespeichert wird), eine saubere
block.json-Deklaration mit Versionierung, und Block-Supports für
die Dinge, die WordPress von Haus aus kann: Farben, Abstands-Controls, responsive
Einstellungen. Was nativ geht, bauen wir nicht selbst.
Gestaltung, die
dem Inhalt dient.
Was im Theme-Paket steckt
Ein abgeliefertes Custom-Theme ist ein dokumentiertes System, das weit über einen Ordner mit PHP-Dateien hinausgeht und das ein Team ohne Entwicklerwissen bedienen kann.
Page-Templates abdecken alle Seitentypen des Projekts: Hero-Layouts, Two-Column-Seiten, Vollbreite-Seiten mit Sidebar, Blog-Index, Archiv-Templates, Einzel-Artikel. Jedes Template ist eine eigene PHP-Datei mit klarem Namen und direkt auffindbar, statt versteckt in einem Theme-Options-Panel.
Custom-Block-Library liefert die Blöcke, die das Projekt wirklich braucht, gezielt gebaut statt von einem Generator in hundert halbgaren Varianten ausgespuckt. Jeder Block ist gebaut für einen konkreten Anwendungsfall: Hero-Banner, Feature-Grid, Testimonial-Reihe, CTA-Bereich, Accordion - was der Auftritt braucht und was der Redakteur häufig ändern wird.
Style-Guide-Page im WordPress-Admin zeigt alle verfügbaren Blöcke, Typografie-Varianten, Farbpalette und Spacing-Abschnitte in einer einzigen Seite. Redakteure können sehen, was verfügbar ist, ohne jemanden fragen zu müssen. Neue Teammitglieder haben einen Einstieg.
Dokumentation in Markdown liegt im Theme-Repository: welche Blöcke
es gibt, wie theme.json-Werte geändert werden, welche Plugins zum
Setup gehören, wie Updates sicher eingespielt werden. Die Doku ist von Anfang an
Teil der Lieferung, statt eines vagen "wir erklären es Ihnen später mal".
Optional kommt hinzu:
- WP-CLI-Setup für Datenbankoperationen auf der Kommandozeile
- GitHub-Actions-Deploy-Pipeline für automatische Deployments bei Push auf main
- Staging-Environment mit automatischem Sync vom Live-System
Performance ist
Teil des Designs.
Performance wird bei uns nicht nachträglich optimiert. Sie ist Teil des Design-Systems von Anfang an.
Image-Compression-Pipeline: Alle Bilder werden in WebP und AVIF
konvertiert und als <picture>-Element mit AVIF als bevorzugtem
Format und WebP als Fallback ausgegeben. JPEG bleibt als letzter Fallback für
Browser ohne moderne Format-Unterstützung. Lazy-Loading per nativem
loading="lazy"-Attribut ist Standard für alles außerhalb des
sichtbaren Bereichs. Above-the-fold-Bilder bekommen fetchpriority="high"
und kein Lazy-Loading - Largest Contentful Paint ist ein Ranking-Faktor, der in die
laufende SEO-Betreuung hineinspielt.
Critical-CSS und deferred JS: Styles, die für den ersten sichtbaren
Bereich gebraucht werden, werden inline im <head> ausgeliefert.
Alles andere wird nachgeladen. JavaScript, das nicht für das initiale Rendering
gebraucht wird, bekommt defer oder async. Kein Render-Blocking
durch Skripte die am Ende der Seite nichts bringen.
Cache-Setup: Caching passiert auf zwei Ebenen. Hostseitig - Nginx FastCGI-Cache oder serverseitiges Objekt-Caching je nach Hosting-Umgebung. WordPress-seitig - Object-Cache mit Redis oder Memcached für Datenbankabfragen, Fragment-Caching für dynamische Bereiche. WP-seitig empfehlen wir LiteSpeed Cache oder WP Rocket je nach Server - nicht zehn Caching-Plugins gleichzeitig, die sich gegenseitig im Weg stehen.
Vom Briefing zum
fertigen Theme.
Vier Phasen, keine Überraschungen. So entsteht ein Custom WordPress-Theme das zu Ihrer Marke passt und in zehn Jahren noch gepflegt werden kann.
01.
Discovery und Marken-Workshop.
01
Erst verstehen,
was Ihre Marke braucht.
Wir starten mit einem Marken-Workshop - kein 30-Minuten-Briefing-Formular, sondern ein strukturiertes Gespräch über Tonalität, Zielgruppe, Wettbewerbsumfeld und Designpräferenzen. Was funktioniert bei Mitbewerbern, was nicht? Welche Marken-Assoziationen soll die Seite auslösen? Was ist das absolute No-Go?
Wir schauen uns bestehende Materialien an: Logo, CI-Manual falls vorhanden, bisherige Website, Printmedien, Präsentation. Alles, was Hinweise auf die visuelle Sprache Ihrer Marke gibt. Wenn kein CI-Manual vorliegt, klären wir im Workshop welche Design-Entscheidungen vor Projektstart getroffen werden müssen - Typografie-Richtung, Farbprinzipien, Bildsprache.
Sie erhalten ein schriftliches Scope-Dokument: welche Seitentypen gebaut werden, welche Custom Blocks enthalten sind, welche Plugins zum Setup gehören, was optional ist, und wovon wir abraten. Vor Projektstart liegt alles auf dem Tisch.
02.
Design-System und Figma-Prototyp.
02
Sehen bevor
gebaut wird.
Aus dem Workshop-Ergebnis entsteht ein Design-System als Figma-Datei: Typografie-Skala (welche Schriftgrößen, welche Schriftschnitte, welche Zeilenhöhenverhältnisse), Farbsystem mit Light- und optionalem Dark-Mode, Spacing-Skala, Eck-Radien, Schatten-Tokens. Alles, was später in theme.json landet, ist hier als visuelles System entschieden bevor eine Zeile Code entsteht.
Auf Basis des Design-Systems entstehen Mockups der wesentlichen Seitentypen: Startseite, Leistungsseite, Kontaktseite, Blog-Artikel. Und die Komponenten-Bibliothek: alle Custom Blocks in allen Varianten, mit Hover-, Focus- und Active-States. Was Sie freigeben, bauen wir danach in Code um.
Freigaben passieren am konkreten Prototyp, den Sie vorab sehen und anfassen. So entfällt das Nachjustieren, weil im Code etwas anders aussieht als erwartet. Block-Patterns und Seitenlayouts werden im Prototyp so abgebildet, dass der Redakteur später in Gutenberg intuitiv arbeiten kann.
03.
Theme-Entwicklung und Block-Bau.
03
Custom Code,
lesbar und dokumentiert.
Das Theme entsteht als eigenes Parent-Theme nach WordPress Coding Standards - kein Child-Theme auf einem Drittanbieter-Fundament. theme.json trägt das Design-System als globale Token: alle Farben, Abstands-Werte, Schriftgrößen und Eck-Radien sind dort zentralisiert. Wer eine Farbe ändern will, ändert sie an einer Stelle und das System zieht sie durch.
Custom Blocks werden als native Gutenberg-Blocks gebaut - mit edit- und save-Funktion, Block-Supports für Farben und Abstands-Controls, und sauberer block.json-Deklaration mit Versionierung und Block-API-Version 3. Keine Shortcodes, keine Page-Builder, kein versteckter proprietärer Code in Datenbankfeldern.
Jede Funktion bekommt einen klaren Ort: Design-Logik in theme.json und CSS, Template-Logik in PHP-Templates, Block-Logik in einem Block-Plugin. Accessibility gehört von der ersten Zeile an dazu: WCAG-AA-Kontraste, Tastaturnavigation, Aria-Labels und Fokus-Styles sind Teil des Entwicklungsprozesses und werden gleich mitgebaut, statt am Ende abgehakt.
04.
Migration, Launch und Übergabe.
04
Live gehen,
und danach.
Inhalte werden in die neue Installation eingepflegt oder migriert - Redaktion, Datenbankimport, Migration von einem anderen CMS. Medien-Bibliothek wird gesäubert, interne Links werden aktualisiert, Redirects werden vollständig aufgesetzt bevor die Domain wechselt. Kein Ranking-Punkt geht verloren weil jemand vergessen hat eine 301-Weiterleitung einzurichten.
Vor dem Launch checken wir Performance (Core Web Vitals, PageSpeed-Score), Sicherheits-Header, Caching-Konfiguration, SSL, Backup-Automatisierung und Staging-Zugang. SEO-Basics sind gesetzt: XML-Sitemap, robots.txt, strukturierte Daten wo sinnvoll, Canonical-Tags, Open-Graph-Meta.
Mit dem fertigen Theme erhalten Sie die Dokumentation: Custom-Block-Anleitung, theme.json-Erklärung, Plugin-Liste mit Funktion, Update-Routine. Wir schulen Ihr Team im Block-Editor - praxisnah am realen Projekt. Was häufig bearbeitet wird, bekommt erklärte Block-Patterns die ohne Entwickler-Wissen nutzbar sind.
Bevor wir anfangen.
Page-Builder wie Elementor oder Divi - ja oder nein?
Nein, und das ist eine bewusste Entscheidung. Page-Builder erzeugen aufgeblasenen Markup, verlangsamen die Seite und schaffen Vendor-Lock-in auf Datenbankebene - wenn das Plugin deaktiviert wird oder seinen Datenformat ändert, sind die Inhalte nicht mehr lesbar. Wir bauen stattdessen Custom Blocks für den nativen Gutenberg-Editor. Das läuft schneller, ist zukunftssicher und lässt sich ohne proprietäre Abhängigkeit weiterpflegen. Wenn Sie bereits eine Elementor- oder Divi-Site haben und sanieren wollen, ist das möglich - das besprechen wir im Konzept.
Ist ein Themeforest-Theme auch eine Option?
Für einfache Anforderungen mit sehr kleinem Budget und kurzer Lebensdauer manchmal. Für alles, das länger laufen und eine eigene Markenidentität haben soll, empfehlen wir es nicht. Themeforest-Themes bringen ungenutzten Code, proprietäre Page-Builder und eine Update-Abhängigkeit von einem externen Anbieter mit, dessen Weiterentwicklung Sie nicht beeinflussen können. Wenn der Anbieter sein Theme nach drei Jahren einstellt oder mit einem Major-WP-Update inkompatibel wird, stehen Sie vor einem ungeplanten Neuaufbau.
Was kostet ein Custom WordPress-Theme?
Das hängt vom Scope ab: Anzahl der Seitentypen, Custom Blocks, Animationen, Mehrsprachigkeit, E-Commerce-Anbindung, Design-Aufwand. Ein schlankes Custom Theme für einen Unternehmensauftritt mit bis zu acht Seiten liegt in einem anderen Preisrahmen als ein Theme mit zwanzig Block-Typen, WPML-Integration und eigenem Design-System von Null. Nach dem Briefing bekommen Sie ein konkretes Angebot für den definierten Umfang - keine Stundensätze, keine offenen Enden. Die Konzeptphase wird in der Regel separat angeboten.
Wie tief geht die Gutenberg-Block-Editor-Integration?
Vollständig nativ. Alle Custom Blocks werden als echte Gutenberg-Blocks gebaut mit Block-API v3, eigener edit-Funktion im Editor und save-Funktion für den gespeicherten Output. Block-Supports für Farben, Abstands-Controls und responsive Einstellungen werden genutzt wo sie nativ verfügbar sind. theme.json trägt das globale Design-System. Ihr Redakteur arbeitet im Standard-WordPress-Editor ohne Drittanbieter-Plugin und ohne Lernkurve für proprietäre Systeme.
Kann das Theme später angepasst oder erweitert werden?
Ja, das ist ein explizites Entwicklungsziel. Der Theme-Code folgt WordPress Coding Standards und ist vollständig dokumentiert. Neue Block-Typen, weitere Seitentemplate, Farbschema-Erweiterungen oder zusätzliche Sprachversionen können durch uns oder durch jeden anderen Entwickler ergänzt werden, der mit Standard-WordPress vertraut ist. Kein proprietäres Lock-in-Format, kein Code der nur mit unserem Tooling lesbar ist. Für kleinere Anpassungen liefern wir eine Anleitung, für größere Updates kommen wir gerne rein.
Welche WordPress-Version wird unterstützt?
Wir entwickeln gegen die aktuelle WordPress-Version und unterstützen die zwei vorherigen Major-Versionen. In der Praxis bedeutet das: das Theme läuft sicher auf den drei aktuellsten WordPress-Versionen. Sicherheitsrelevante Patches spielen wir bei Pflege-Kunden auf dem Staging-System ein und deployen nach Freigabe auf Live. Kein blindes Update-Drücken auf der Live-Site.
Ist das Theme Multisite-tauglich?
Optional und gegen Mehraufwand. WordPress Multisite eignet sich gut für Marken-Familien, Franchise-Systeme oder mehrsprachige Auftritte unter verschiedenen Domains, die dieselbe Codebasis teilen sollen. Nicht jedes Projekt profitiert davon - ob Multisite die sinnvollere Lösung ist, besprechen wir im Konzept. Wir richten Multisite auf, konfigurieren Domain-Mapping und schulen Administratoren.
WPML oder Polylang für Mehrsprachigkeit?
Kommt auf den Anforderungskontext an. WPML ist stabiler, besser in Großinstallationen getestet und hat einen ausgereiften String-Translation-Layer für Theme-Texte - dafür kostenpflichtig. Polylang ist gratis in der Grundversion, reicht für viele Projekte vollständig aus, hat aber bei sehr komplexen Inhaltsstrukturen Grenzen. Wenn das Projekt Translation-Memory, professionelle Übersetzungs-Workflows oder WPML-kompatible Plugins erfordert, empfehlen wir WPML. Für einfachere Mehrsprachigkeit ist Polylang die schlankere Wahl. Wir empfehlen nach Projektsituation, nicht nach Provision.
Accessibility - welches Level wird eingehalten?
WCAG AA ist unser Standard, ohne Aufpreis. Das bedeutet: Farbkontraste geprüft (Kontrastverhältnis mindestens 4.5:1 für Normtext), alle interaktiven Elemente per Tastatur erreichbar, Fokus-Styles sichtbar, Bilder mit Alt-Text, Formulare mit sichtbaren Labels, ARIA-Landmarks für Screenreader. WCAG AAA ist auf Anfrage möglich und hängt stark vom Inhalt ab - einige AAA-Kriterien betreffen redaktionelle Entscheidungen, nicht nur Code.
Gehört mir der Code nach Projektabschluss?
Ja, vollständig. Nach vollständiger Bezahlung erhalten Sie das komplette Theme-Repository mit allen Quell-Dateien, der vollständigen Git-History und der Dokumentation. Kein Abo, keine laufende Lizenzgebühr, keine Einschränkung in der Nutzung. Sie können den Code intern pflegen, einem anderen Entwickler übergeben oder erweitern - ohne uns fragen zu müssen.