WordPress, Joomla oder hartes HTML/PHP?

In Erstgesprächen hören wir selten „wir brauchen Joomla 5 mit ACL“. Wir hören: Die Kollegin soll Texte ändern. Der Verband hat drei Sprachen. Der Einkauf will keine Plugin-Rechnungen. Die IT erlaubt nur PHP auf dem bestehenden Tarif. Google soll uns finden, aber bitte ohne Magie. Irgendwer im Raum hat auf einer Konferenz React gehört.

Daraus ein Stack zu machen, ist Handwerk. Wir sitzen in Gampaha, Sri Lanka, unter der Leitung von Hesadu Dissanayaka. Deutsch, Sie-Form, Festpreis. Keine erfundenen Kundenlogos, oft NDA. Keine Ranking-Garantie. Die Website, die Sie gerade lesen, ist hartes PHP — bewusst. Das macht PHP nicht für jedes Briefing richtig. Es macht uns ehrlich: Wir verkaufen nicht immer das, womit wir selbst live gehen.

Unten steht der Rahmen, mit dem wir in realen Anfragen entscheiden. Ohne Firmennamen. Muster reichen: Handwerk mit einer Leistung, Mittelstand mit Redaktion, Verband mit Sprachen und Rechten, Produkt mit Konfigurator, internes Portal. Die Namen der Auftraggeber gehören in Verträge, nicht in Blogposts.

Vier Werkzeuge, vier Jobs

WordPress, Joomla, hartes HTML/PHP, React. Node.js hängt oft an React als API, ist aber kein Ersatz für eine Broschüre. Mobile Apps sind ein anderes Produkt. Wer alles in einen Satz packt, kauft Komplexität auf Vorrat.

Die Zeilen sind Startpunkte. Ein Verband kann WordPress mit Rollen hinbiegen und unglücklich werden. Ein Handwerksbetrieb kann Joomla erben und sollte es behalten, weil die Inhalte und die Mehrsprachigkeit schon da sind. Wechsel „weil alle WordPress machen“ ist ein Projekt. Er ist kein Automatismus.

Wir fragen zuerst: Wer ändert nächste Woche eine Überschrift — und womit? Die Antwort sortiert den Stack zuverlässiger als jede Trendliste.

Fragen, die ein Briefing entscheiden

Nicht „welches CMS ist das beste“. Diese Frage lehnen wir ab. Es gibt keines. Es gibt Randbedingungen. Die folgenden Fragen stellen wir, oft unbequem, weil sie Arbeit auf Auftraggeberseite erzeugen. Ohne sie schätzen wir zu niedrig oder zu hoch. Beides ist schlecht. Zu niedrig kippt das Projekt. Zu hoch verlieren Sie den internen Freigabeprozess.

1. Wie oft ändern sich welche Inhalte — Startseite, Leistungen, Blog, Preise, Stellen?
2. Wer ändert sie: Geschäftsführung, Marketing, Ehrenamt, niemand außer uns?
3. Welche Sprachen, welche Rechtsräume, welche Hosting-Vorgaben (EU, PHP-Version, kein Node)?
4. Muss die Site ranken (Inhalte, URLs, Crawl) oder ist sie hinter Login?
5. Welche Systeme müssen angebunden werden — oder ist das ein Wunsch aus einer Folie?
6. Was passiert in zwei Jahren, wenn wir nicht mehr im Chat sind: interne IT, anderer Dienstleister, Datei plus FTP?

Wenn Punkt 6 keine Antwort hat, bauen wir trotzdem so, dass jemand fremdes den Code lesen kann. Dokumentation auf Deutsch. Keine stillen Subunternehmer ohne Ihr Wissen. Git, Staging, klare Abhängigkeiten.

WordPress: Redaktion mit Betriebspflicht

Stärke: Editor, Ökosystem, viele Dienstleister, die im Notfall übernehmen können. Schwäche: Angriffsfläche, Update-Takt, Verführung zum Plugin. Passt, wenn Texte häufig wechseln und Sie selbst pflegen wollen. Wir bauen dann ein eigenes Theme, nicht ein gekauftes Universalskelett. Details unter WordPress.

In Briefings klingt das oft so: „Die Assistenz soll News einstellen, ohne uns anzurufen.“ Das ist ein valides WordPress-Argument. Es ist kein Argument für einen Page-Builder, der die Datenbank vollschreibt. Blöcke, wenige Plugins, EU-Hosting, lokale Schriften. WooCommerce nur, wenn Sie verkaufen — nicht falls irgendwann.

Wann wir WordPress abraten

Wenn niemand Updates einspielt. Wenn die Site fünf Seiten hat und zwei Jahre stehen bleibt. Wenn die IT WordPress auf einem Tarif verbietet, der nur statisches HTML darf. Wenn das eigentliche Produkt ein Dashboard ist und WordPress als Fassade drumgeklebt würde. Fassaden-CMS erzeugen doppelte Auth, doppelte Preview, doppelte Kosten.

Übernahmen bestehender WP-Instanzen machen wir nach Sichtung. Manche sind gesund und brauchen ein Theme. Manche sind ein Museum. Museen renoviert man oder man zieht um. Beides hat einen Preis. Umziehen nach Joomla nur weil jemand Joomla mag, ist selten klug. Umziehen in hartes PHP, wenn Redaktion tot ist, oft schon.

Joomla: Rechte und Sprachen, kleinerer Markt

Stärke: ACL, Mehrsprachigkeit, strukturierte Sites in Verbänden, Kammern, Lehre, manchen Behördenkontexten. Schwäche: weniger Freelancer, weniger Blog-Tutorials, leichteres Argument im Einkauf gegen „warum nicht WordPress“. Ein Wechsel nur wegen Talentmarkt kann trotzdem teurer sein als ein sauberer Joomla-Relaunch — Inhalte, Module, Sprachen, Redirects. Unter Joomla steht, was wir tun: Templates, Overrides, Härtung, Migration 4/5.

Briefing-Muster: „Wir haben vier Redaktionsgruppen, die nur ihre Rubrik sehen dürfen.“ WordPress kann das mit Rollen-Plugins. Joomla kann das näher am Kern. Kern schlägt Plugin, wenn die Organisation das System schon kennt. Kennt sie es nicht und hat nur eine Person, die samstags im Admin war, ist der Talentmarkt ein echtes Risiko. Das sagen wir. Wir beschönigen Joomla nicht, nur weil wir es anbieten.

Relaunch statt Flucht

Veraltete Joomla-Instanzen sind Einfallstore. Das ist kein Grund, überstürzt nach WordPress zu kippen und die Mehrsprachigkeit in einem Plugin neu zu erfinden. Erst härten, Backup, Update-Pfad. Dann entscheiden, ob das Inhaltsmodell noch trägt. Flucht ins vermeintlich Populäre erzeugt oft zwei unfertige Systeme plus eine Redirect-Liste, die niemand pflegt.

Hartes HTML und PHP: Tempo, Kontrolle, Pflegevertrag

Stärke: Ladezeit, Sicherheit, SEO-Kontrolle, geringe Betriebskosten, Markup genau so, wie Crawler und Screenreader es brauchen. Schwäche: Redakteure brauchen uns oder ein minimales eigenes Backend. Diese Site folgt dem Modell. Includes, Strict Types, Routing ohne Magie. Kein Plugin-Ökosystem, das uns nachts weckt.

Briefing-Muster: „Wir ändern Texte zweimal im Jahr, Impressum muss sitzen, bitte schnell.“ Das ist HTML/PHP. Formulare, SMTP, Rechtstexte, Schema, Sitemap. Inhalte in Dateien oder kleinem Admin. Leistungsseite: PHP und HTML.

SEO ohne CMS-Ballast

Canonicals, eine Host-Variante, echte Überschriften, keine Builder-Suppe. Core Web Vitals sind hier weniger Theater. Das ersetzt keine Inhalte. Eine schnelle leere Seite rankt nicht, weil sie schnell ist. Sie ist nur weniger im Weg. Rankings bleiben Wettbewerb. Wir liefern Indexierbarkeit, Search Console, keine Platz-1-Zusage.

Pflege: Sie schicken Korrekturen, wir spielen sie ein. Oder Sie bekommen Content-Dateien mit kurzer Anleitung. Wöchentliche Landingpages durch ein Team ohne Git — dann ist hartes PHP das falsche Versprechen. Wir merken das im Briefing, nicht nach Launch.

React: wenn Zustand das Produkt ist

Stärke: Komponenten, komplexe Oberflächen, Apps im Browser, Konfiguratoren, Dashboards. Schwäche: mehr Bewegteile, SEO nur mit SSR oder SSG sauber, Hosting nicht immer der PHP-Tarif der Hausagentur. Für Broschüren meist zu schwer. React-Leistung und der Überblick unter Technologien.

Briefing-Muster: „Nutzer konfiguriert ein Produkt, sieht Preis live, speichert Entwürfe, Login.“ Das ist React plus API (oft Node oder PHP). WordPress als Theme drumherum ist hier Sand im Getriebe. Umgekehrt: fünf Leistungsseiten in einer Client-only-SPA zu begraben, schadet der Auffindbarkeit. Wir setzen SSR oder lassen Inhalte serverseitig in PHP, statt Märchen zu erzählen, Crawler hätten sich an SPA gewöhnt und alles sei fein.

React ist kein Designgewinn

Ein schönes Interface entsteht in Typografie und Hierarchie, nicht in einer Library. Wer React bucht, um „modern zu wirken“, zahlt Laufzeit und Build, ohne den Job zu lösen. Modern wirkt eine Seite, die in 3G auf einem mittelalten Android lesbar ist und Impressum trägt. Das geht in PHP. Das geht in React. Es geht nicht durch das Logo der Library im Footer.

Muster aus Briefings — anonym, konkret

Handwerk, eine Leistung, Kontakt, drei Fotos, Impressum. Entscheidung: HTML/PHP oder One-Pager. WordPress nur, wenn der Meister wöchentlich baustellenbloggt und das wirklich tut. Viele wollen das. Wenige tun es nach Monat zwei. Wir fragen nach den letzten zwölf Texten, die intern entstanden sind. Die Antwort ist ehrlicher als die Roadmap-Folie.

Mittelständischer Hersteller, 10 Seiten, zwei Sprachen, Assistenz pflegt News. Entscheidung: WordPress, Custom Theme, ein SEO-Plugin oder hartes SEO im Theme, Formulare ohne US-SaaS. Joomla, wenn Mehrsprachigkeit und Rechte schon Joomla-DNA sind.

Verband, Landesgruppen, Dokumente, drei Sprachen, Redakteure mit engen Rechten. Entscheidung: oft Joomla behalten oder hart sanieren. WordPress nur mit bewusstem Rollenkonzept und Schulung. Hartes PHP, wenn die Redaktion in Wahrheit eine Geschäftsstelle ist, die uns vierteljährlich sammelt — dann können Dateien reichen.

Industrie mit Produktkonfigurator und öffentlicher Broschüre. Entscheidung: Broschüre PHP oder WordPress, Konfigurator React, API daneben. Nicht alles in einem CMS-Plugin erzwingen. Zwei Systeme mit klarer Grenze sind billiger als ein System, das beides schlecht macht.

Internes Portal, Login, Rollen, keine Google-Ambition. Entscheidung: React/Node oder PHP-App. CMS nur, wenn Redaktion Hilfeartikel schreibt. SEO-Pakete haben hier nichts verloren. Wer sie trotzdem einbaut, zahlt für Theater.

Migration: der Preis, über den niemand sprechen will

Inhalte herausholen, URLs mappen, Dateien, Formulare, Redirects, Search Console, Anker in PDFs die niemand findet. Das ist der unsichtbare Block. Ein CMS-Wechsel ohne Redirect-Konzept verbrennt Jahre an Sichtbarkeit — nicht weil Google böse ist, sondern weil 404 die Arbeit der Vorgänger entsorgt.

Wir listen Alte-URL nach Neue-URL. Wir spielen 301, nicht „wird sich finden“. Wir versprechen trotzdem keine Rankings. Wir versprechen, den Schaden einer Migration nicht zu vergrößern.

Datenmüll mitnehmen ist auch ein Fehler. Alte Slider-Shortcodes, tote Kampagnen, zehn Impressumsversionen. Relaunch ist der Moment zum Löschen. Löschen braucht Freigabe. Freigabe braucht eine Person mit Mandat. Ohne Mandat kopieren wir Müll teuer in ein neues Theme.

Hosting und Betrieb über drei Jahre

PHP-Tarif in der EU trägt WordPress, Joomla, hartes PHP. React/Node braucht oft andere Laufzeiten, Container oder Platform-as-a-Service. Das ist nicht besser. Es ist anders. IT-Richtlinien mancher Häuser erlauben kein Node. Dann ist React-SSR dort Politik, nicht Geschmack.

Updates: WordPress und Joomla brauchen sie. Hartes PHP braucht PHP-Version und Dependency-Updates, aber keinen wöchentlichen Plugin-Kalender. React braucht npm-Audits, Build, Node-Versionen. Wer intern niemanden hat, kauft Betreuung. Unsere Betreuung ist ein Modul, kein Zwang. Ohne Betreuung schreiben wir trotzdem, was Sie wann tun müssen.

Backups und Staging gelten für alle vier. Ohne Staging ist jedes Update ein Live-Experiment. Wir arbeiten nicht als Experiment auf Production, wenn Staging machbar ist. Manchmal ist das Hosting so klein, dass Staging extra kostet. Dann gehört das in den Festpreis oder in Ihre IT-Entscheidung.

SEO, Barriere, Recht — stackübergreifend

Impressum, Datenschutz, Cookie-Logik, lokale Fonts: das gilt in jedem Stack. React entbindet nicht vom DDG. WordPress entbindet nicht von sauberem HTML. Joomla entbindet nicht von Consent vor Tracking. Hartes PHP entbindet nicht von verständlichen Texten.

Barrierefreiheit: Semantik, Kontrast, Fokus. Ein volles BFSG-Audit ist extra, in jedem Stack. Wer „wir sind barrierefrei, weil WordPress“ sagt, verwechselt CMS mit Konformität.

Wir sitzen außerhalb der EU. Personenbezogene Anfragen nach Sri Lanka: Transparenz, Art. 46, EU-Hosting der Site selbst. Das ist unabhängig davon, ob das Frontend in PHP oder React gerendert wird. Stack-Wahl löst keine Drittlandfrage.

Kostenrahmen, grob, ohne Paket-Theater

Die Spannen auf der Preisseite bleiben: One-Pager HTML ab 1.290 € netto, Unternehmenswebsite 1.990–4.900 €, WordPress 1.790–5.500 €, Joomla-Relaunch oft 1.890–6.000 €, React-Anwendungen ab 3.900 €. Shop und App liegen darüber. Steuern nach Einzelfall. Kein Stack ist „das Premium“, nur weil er teurer ist. Teurer ist meist mehr Bewegteile oder mehr Templates.

Ein React-Broschürenprojekt, das in PHP 2.400 € wäre, wird nicht wertvoller, nur teurer. Ein WordPress, das niemand pflegt, wird in Jahr zwei teurer als hartes PHP plus zwei Textaufträge. TCO schlägt Sticker-Preis. Wir rechnen das im Angebot in Sätzen, nicht in einer Excel-Simulation mit Fantasiezinsen.

Was wir nicht tun

Keinen Stack wählen, weil er in unserem Portfolio besser aussieht. Keine Fake-Case-Studies. Keine „wir sind die führende Agentur für …“. Keine Garantie, dass Google die neue Technik belohnt. Crawling kann schnell starten. Konkurrenz um Begriffe nicht.

Kein heimliches Headless, weil es sich nach Architektur anhört. Headless heißt zwei Deployments, Preview-Probleme, Auth zwischen CMS und Frontend. Manchmal richtig. Oft eine Lösung, die das Briefing nicht gestellt hat.

Keine stille Ersetzung von Joomla durch WordPress in einem „Relaunch“, der intern als Facelift verkauft wird. Wenn wir wechseln, steht der Wechsel im Angebot. Überraschungen gehören in den Scope, nicht in den Staging-Link.

Team, nicht Trend: wer den Stack morgen trägt

Ein CMS ohne Redakteur ist ein ungenutzter Editor plus Update-Pflicht. Eine React-App ohne JavaScript im Haus ist eine Abhängigkeit von uns oder vom nächsten Dienstleister. Hartes PHP ohne Git-Übung in Ihrer IT ist trotzdem oft leichter zu übergeben als ein Builder-Lock-in. Wir fragen nach Skills, nicht um zu prüfen, ob Sie „technisch genug“ sind. Wir fragen, damit der Stack nicht an uns als Person klebt.

Verbände mit Ehrenamt: der Admin muss verzeihen. Wenige Rechte, klare Rubriken, keine Möglichkeit, das Layout zu zerlegen. Joomla oder WordPress mit harten Rollen. Kein Page-Builder für Menschen, die zweimal im Jahr eine PDF-Sitzung hochladen.

Mittelstand mit Marketing-Abteilung: Vorschau, Entwürfe, Medien. WordPress ist hier oft ehrlich. Solange niemand den Editor zum Design-Tool umbaut. Design-Systeme gehören in Theme und Richtlinien, nicht in 40 frei verschiebbare Widgets auf der Startseite.

Produktteams mit Designern in Figma und Entwicklern in TypeScript: React kann die Übergabe verkürzen. Content-Seiten trotzdem serverseitig. Gemischte Teams scheitern, wenn Designer Komponenten bauen, die SEO-Texte in Client-State verstecken.

Inhaltsmodell vor Theme-Wahl

Leistungen, Standorte, Personen, Downloads, FAQ: Das sind Typen. In WordPress Custom Post Types oder Blöcke. In Joomla Artikel plus Kategorien plus eigene Felder. In PHP Dateien oder eine kleine Tabelle. In React oft ein Headless-CMS — und dann sind Sie bei zwei Systemen. Wer das Inhaltsmodell nicht zeichnet, kauft ein Theme und stopft alles in Seiten. Nach einem Jahr findet niemand die Telefonnummer der Filiale, weil sie in drei Layouts kopiert wurde.

Zeichnen heißt: eine Liste. Kein Workshop-Theater. Welche Felder Pflicht sind, welche mehrsprachig, welche nur intern. Danach erst das Tool. Tool-first erzeugt Schatten-Excel neben dem CMS. Die Excel gewinnt immer. Dann haben Sie zwei Wahrheiten und eine Website, die lügt.

Zeitlinien, grob und ehrlich

Hartes PHP für eine Broschüre: oft schneller im Launch, langsamer in der Selbstbedienung. WordPress: länger im Theme-Bau, danach schneller in der Redaktion. Joomla-Relaunch: Migrationszeit nicht unterschätzen. React: Frontend plus API plus Auth — selten „in zwei Wochen live“, außer der Scope ist ein Prototyp ohne Datenwanderung. Wer den Termin vor dem Stack setzt, zwingt uns zu HTML/PHP oder zu einem rücksichtslos kleinen WordPress. Das kann richtig sein. Es muss gesagt sein.

Mischformen, die wir erlauben — und die wir stoppen

Erlaubt: öffentliche Broschüre in PHP, Kundenportal in React unter /konto. Erlaubt: WordPress für News, statische Kampagnen-Microsite daneben. Stoppen: WordPress und Joomla parallel „weil Abteilungen das so wollen“, ohne Redirect- und Login-Konzept. Stoppen: React-Islands auf jeder Broschüren-URL, nur weil eine Komponente einen Tab braucht. Tabs gehen in HTML.

Stoppen auch: ein CMS nur als Jobbörse, während die eigentliche Firma auf einer anderen Domain mit anderem Impressum lebt, ohne Verweis. Rechtlich und redaktionell entstehen dann zwei Wahrheiten. Crawler und Bewerber mögen das nicht. Wir verlinken intern klar oder wir führen die Auftritte zusammen. Zusammenführen ist Inhaltspolitik, nicht ein Plugin.

Mehrsprachigkeit in Mischformen: hreflang nur, wenn die Sprachen wirklich existieren. Eine englische Button-Leiste auf einer deutschen Seite ist keine Locale. Ein PDF auf Englisch in einem deutschen Ordner auch nicht. Sprachen sind URL-Sets plus Pflege. Ohne Pflege lieber eine Sprache, sauber.

Übergabe, die einen zweiten Dienstleister überlebt

README, lokale Setup-Hinweise, PHP-Version, Node-Version falls vorhanden, ENV-Beispiel ohne Secrets, Liste der Cronjobs, wo Backups liegen, wer DNS kann. Das klingt nach Hygiene. Es ist der Unterschied zwischen einem Studio und einer Blackbox. Wir sind in Sri Lanka. Ihre nächste IT kann in Leipzig sitzen. Der Code muss trotzdem lesbar sein.

Zugänge: Staging, Production, Search Console, Hosting. Wir wollen sie nicht als private Macht. Wir wollen sie dokumentiert in Ihrer Hand. Wenn ein Auftrag endet, endet unser privilegierter Zugang. Das gehört in den Vertrag, nicht in ein schlechtes Gewissen.

Designsysteme überleben den Stack-Wechsel besser als Builder-Daten. Tokens, Typo, Raster, Komponenten in Figma oder in CSS — das lässt sich in PHP und in React nachbauen. Shortcodes einer Seite von 2017 lassen sich oft nur mit Tränen nachbauen. Deshalb: Inhalte strukturieren, Layouts als Templates, keine einmaligen Sonderseiten ohne Not. Sonderseiten gibt es. Sie sind die teuren. Sie sollen selten sein und benannt.

Wenn zwei Stakeholder zwei Stacks wollen, moderieren wir eine Entscheidung, wir bauen nicht beide „zum Vergleich“ auf Production. Zwei Produktivsysteme ohne Owner sind das teuerste Briefing, das wir kennen. Ein Prototyp auf Staging: ja. Ein jahrelanger Parallelbetrieb ohne Migrationsdatum: nein, außer Sie zahlen ihn bewusst als Betrieb, nicht als Provisorium. Bewusst zahlen heißt: zwei Hostings, zwei Update-Kalender, zwei Impressen wenn die Domains getrennt sind. Wer das will, soll es sehen, bevor es still entsteht.

So entscheiden wir mit Ihnen

Gespräch, oft asynchron plus ein Call in der MEZ-Überlappung. Sie schicken die alte URL oder das PDF. Wir sagen, welcher Stack zur Redaktion und zum Hosting passt. Manchmal zwei Optionen mit Preisdelta. Sie wählen. Festpreis auf den gewählten Scope. Anzahlung, Umsetzung, Staging, Launch.

Wenn Vertraulichkeit nötig ist, NDA zuerst. Wir nutzen das Briefing nicht als Referenz. Deshalb lesen Sie hier Muster, keine Marken. Wer Referenzen mit Logo als Pflicht setzt, filtert uns heraus. Das ist in Ordnung. Wir filtern umgekehrt Auftraggeber heraus, die Ranking in 48 Stunden oder eine Münchner Briefkastenadresse von uns verlangen.

Der Hosting-Tarif entscheidet mit, nicht erst hinterher

IT sagt oft: nur PHP, kein Node, Standort EU, bestimmtes Panel. Dann ist React-SSR Politik, nicht Geschmack. Wir fragen das in der ersten Mail, nicht nach dem Moodboard. Ein Stack, der auf dem erlaubten Tarif nicht läuft, ist kein Angebot, sondern eine zweite Baustelle. Unter Preise stehen Spannen für das, was auf üblichen PHP-Tarifen trägt. Sonderlaufzeiten stehen extra da.

DNS, PHP-Version, SSH ja oder nein: das klingt nach Kleinkram. Es entscheidet, ob wir deployen oder ZIP-Uploads ins Wurzelverzeichnis schicken. Beides geht. Beides hat einen anderen Betriebspreis. Wir schreiben ihn auf.

WordPress auf einem Tarif ohne Staging ist möglich. Es ist unruhiger. Unruhiger rechnen wir ein oder wir raten zu hartem PHP. Die Empfehlung hängt am Host, nicht an unserer Lieblingssprache. Leistungsbild WordPress setzt voraus, dass Updates irgendwo getestet werden können — bei Ihnen oder bei uns. Getestet heißt: Kopie, klicken, dann Production. Nicht umgekehrt.

Inhalte retten, bevor der Stack wechselt

Bevor jemand „wir wollen aber WordPress“ sagt, exportieren wir, was wertvoll ist: URLs, Texte, Dateien, Formularziele. Der Stack kann warten. Verlorene Pfade warten nicht. Wir haben Relaunches gesehen, die visuell stimmten und in der Search Console eine 404-Lawine auslösten. Nicht, weil Google ungerecht ist. Weil niemand die Map gebaut hat.

Welche fünf Adressen dürfen auf keinen Fall sterben? Impressum, Leistungsseite, die eine Unterseite, die seit Jahren Anfragen trägt. Danach erst Theme oder hartes PHP. Webdesign ohne URL-Plan ist Fassade auf einem Umzug ohne Adressnachsendeauftrag. Wir notieren die fünf Adressen im Angebot, nicht nur im Call. Was nicht im Angebot steht, überlebt den Stack-Wechsel oft nicht.

Techniküberblick: Technologien. Vertiefung: WordPress, Joomla, PHP/HTML, React. Wenn der Stack-Satz steht oder eben noch nicht: Kontakt.

Letzter Satz, weil er in Briefings fehlt: Der Stack ist umkehrbar, solange Inhalte und URLs sauber sind. Unumkehrbar wird es durch Builder-Lock-in, fehlende Redirects und durch Code, den niemand erklärt. Dagegen arbeiten wir. Nicht gegen WordPress, nicht gegen Joomla, nicht gegen React. Gegen Unklarheit.

Dazu eine Einschätzung holen Leistungen