Word­Press ist nicht im­mer die rich­ti­ge Wahl für das Con­tent-Ba­ckend – und wir sa­gen das of­fen, weil es uns lang­fris­tig mehr bringt als Ih­nen ge­gen­über eine Tech­no­lo­gie zu be­wer­ben, die nicht op­ti­mal passt. Der ehr­li­che Ver­gleich mit den an­de­ren CMS-Op­tio­nen in un­se­rem Tech Stack ge­hört zur Be­ra­tung dazu.

Wann Word­Press Head­less die rich­ti­ge Wahl ist

Word­Press Head­less funk­tio­niert be­son­ders gut, wenn eine be­stehen­de Word­Press-In­stal­la­ti­on mi­griert oder er­wei­tert wer­den soll – das Re­dak­ti­ons­wis­sen und die vor­han­de­nen In­hal­te blei­ben er­hal­ten, das Front­end wird mo­der­ni­siert. Es funk­tio­niert eben­so gut, wenn ein Team Word­Press be­reits kennt und nicht um­ler­nen soll, wenn ein brei­tes Plug­in-Öko­sys­tem ge­nutzt wer­den soll, oder wenn die Kom­bi­na­ti­on aus Word­Press und Woo­Com­mer­ce als Head­less-Com­mer­ce-Ba­ckend ge­fragt ist.

Für con­tent­ge­trie­be­ne Web­sites mit ei­nem kla­ren Re­dak­ti­ons­team und ho­hem Traf­fic ist Word­Press Head­less eine aus­ge­reif­te, wirt­schaft­lich at­trak­ti­ve Wahl.

Wann Sa­ni­ty oder Pay­load CMS die bes­se­re Al­ter­na­ti­ve sind

Für Pro­jek­te, die von Grund auf neu ge­baut wer­den, emp­feh­len wir häu­fig Sa­ni­ty oder Pay­load CMS. Sa­ni­ty ist dann in­ter­es­sant, wenn struk­tu­rier­te In­hal­te über meh­re­re Ka­nä­le aus­ge­spielt wer­den sol­len – Web­site, App, News­let­ter, Di­gi­tal Signage – und wenn das In­halts­mo­dell kom­plex und mehr­spra­chig ist. Die Ent­wick­ler­er­fah­rung ist mo­der­ner als bei Word­Press, das In­halts­mo­dell fle­xi­bler zu ge­stal­ten.

Pay­load CMS ist un­se­re Wahl, wenn ein CMS eng mit ei­ner Next­JS-Ap­pli­ka­ti­on ver­zahnt wer­den soll und ma­xi­ma­le Kon­trol­le über Da­ten­mo­dell und Lo­gik ge­fragt ist. Pay­load läuft im sel­ben Next­JS-Pro­jekt, teilt die Da­ten­bank, braucht kei­ne se­pa­ra­te API. Für an­spruchs­vol­le Web­an­wen­dun­gen, die in­halts­ver­wal­te­te Be­rei­che ent­hal­ten, ist das oft die ele­gan­te­re Lö­sung.

Word­Press Head­less ist also nicht au­to­ma­tisch das Rich­ti­ge – aber dort, wo es passt, ist es schwer zu schla­gen.

Die Rol­le von Su­pa­ba­se in hy­bri­den Ar­chi­tek­tu­ren

In Pro­jek­ten, die ne­ben dem CMS auch Nut­zer­kon­ten, For­mu­lar­ver­ar­bei­tun­gen, kom­ple­xe­re Da­ten­struk­tu­ren oder Echt­zeit-Funk­tio­nen er­for­dern, er­gän­zen wir Word­Press Head­less mit Su­pa­ba­se als Da­ten­schicht. Su­pa­ba­se lie­fert Post­greS­QL-Da­ten­bank, Au­then­ti­fi­zie­rung und Echt­zeit-Sub­scrip­ti­ons – und lässt sich naht­los in ein Next­JS-Front­end in­te­grie­ren. Bei­de Sys­te­me spre­chen über APIs mit dem Front­end, ohne von­ein­an­der ab­hän­gig zu sein. So ent­steht eine Ar­chi­tek­tur, in der Word­Press das ist, was es gut kann – In­hal­te ver­wal­ten – und Su­pa­ba­se das, was Word­Press nie gut konn­te: struk­tu­rier­te Ge­schäfts­da­ten in Echt­zeit ver­wal­ten.

DSGVO, di­gi­ta­le Sou­ve­rä­ni­tät und war­um Hos­ting-Ent­schei­dun­gen un­ter­schätzt wer­den

Klas­si­sches Word­Press ist in die­sem Punkt oft das ge­rings­te Pro­blem – es läuft auf ei­ge­ner In­fra­struk­tur, die Da­ten blei­ben dort, wo man sie hin­stellt. Das Head­less-Set­up än­dert dar­an grund­sätz­lich nichts, er­öff­net aber Wahl­mög­lich­kei­ten, die im klas­si­schen Set­up nicht be­stehen.

Wo liegt das Front­end?

Head­less-Frontends wer­den häu­fig auf Platt­for­men wie Ver­cel oder Net­li­fy de­ployt – US-ame­ri­ka­ni­sche An­bie­ter, die zwar her­vor­ra­gen­de Ent­wick­ler­er­fah­run­gen bie­ten, aber den­sel­ben struk­tu­rel­len Da­ten­schutz­fra­gen un­ter­lie­gen wie an­de­re US-Cloud-Diens­te. Der Cloud Act ist kei­ne hy­po­the­ti­sche Be­dro­hung; er ist gel­ten­des US-Recht. Für Un­ter­neh­men, die Wert auf di­gi­ta­le Sou­ve­rä­ni­tät le­gen, emp­feh­len wir De­ploy­ments auf Hetz­ner – deut­sches Un­ter­neh­men, Re­chen­zen­tren in Deutsch­land und Finn­land, kei­ne Ver­bin­dung zu US-ame­ri­ka­ni­schen Hy­pers­ca­lern. Ver­cel und Net­li­fy blei­ben eine Op­ti­on für Pro­jek­te, bei de­nen Ent­wick­lungs­ge­schwin­dig­keit und glo­ba­le Edge-Per­for­mance Prio­ri­tät ha­ben und die Da­ten­schutz­an­for­de­run­gen we­ni­ger streng sind.

Das Ba­ckend: Word­Press auf kon­trol­lier­ter In­fra­struk­tur

Das Word­Press-Ba­ckend läuft bei uns be­vor­zugt auf Hetz­ner – oder auf Raid­bo­xes für Pro­jek­te, bei de­nen ver­wal­te­tes Word­Press-Hos­ting mit au­to­ma­ti­schen Up­dates und pro­fes­sio­nel­lem Sup­port sinn­voll ist. Raid­bo­xes ist ein deut­sches Un­ter­neh­men mit Fo­kus auf ge­nau die­sen An­wen­dungs­fall: si­che­res, DSGVO-kon­for­mes Word­Press-Hos­ting ohne den ope­ra­ti­ven Auf­wand des Selbst­be­triebs. Für Pro­jek­te mit stren­gen Com­pli­ance-An­for­de­run­gen oder ho­hem Da­ten­vo­lu­men be­vor­zu­gen wir ei­ge­ne Hetz­ner-Ser­ver mit voll­stän­di­ger Kon­trol­le über Kon­fi­gu­ra­ti­on, Up­dates und Back­up-Pro­zes­se.

Ent­kopp­lung als Si­cher­heits­vor­teil

Ein oft über­se­he­ner Vor­teil des Head­less-Set­ups: Die Word­Press-In­stanz ist nicht di­rekt öf­fent­lich zu­gäng­lich. Das Front­end kom­mu­ni­ziert über eine API – das Word­Press-Ad­min-In­ter­face ist nicht über die öf­fent­li­che URL er­reich­bar. Das re­du­ziert die An­griffs­flä­che er­heb­lich. Kein au­to­ma­ti­sier­ter Scan­ner fin­det das wp-log­in.php. Kein Bru­te-Force-An­griff trifft di­rekt den Kern des Sys­tems. Se­cu­ri­ty-Har­dening auf API-Ebe­ne er­setzt die auf­wän­di­ge Plug­in-ba­sier­te Ab­si­che­rung, die klas­si­sche Word­Press-Set­ups er­for­dern.

Make or Buy: Auch bei CMS-Ent­schei­dun­gen neu zu be­wer­ten

Die Make-or-Buy-Dis­kus­si­on fin­det in der Re­gel auf der An­wen­dungs­ebe­ne statt – ei­ge­ne Soft­ware oder Stan­dard­lö­sung. Sel­te­ner wird sie auf der CMS-Ebe­ne ge­führt. Da­bei ist sie auch hier re­le­vant.

Was Word­Press mit­bringt, und was das be­deu­tet

Word­Press hat ei­nen Markt­an­teil von über 40 Pro­zent im Web. Das ist kein Zu­fall und kein Trend – es ist das Er­geb­nis von zwei Jahr­zehn­ten Wei­ter­ent­wick­lung, ei­nem rie­si­gen Öko­sys­tem und ei­ner Re­dak­ti­ons­ober­flä­che, die Mil­lio­nen von Men­schen ken­nen. Die In­ves­ti­ti­on in Word­Press-Ex­per­ti­se ist eine In­ves­ti­ti­on in et­was, das bleibt. Das Plug­in-Öko­sys­tem spart in vie­len Fäl­len er­heb­li­chen Ent­wick­lungs­auf­wand: For­mu­lar­ver­ar­bei­tung, SEO-Kon­fi­gu­ra­ti­on, Mehr­spra­chig­keit, Zu­griffs­kon­trol­le – für all das gibt es aus­ge­reif­te Lö­sun­gen, die nicht neu ent­wi­ckelt wer­den müs­sen.

Im Head­less-Kon­text be­deu­tet das: Das CMS-Ba­ckend ist weit­ge­hend fer­tig. Der Ent­wick­lungs­auf­wand kon­zen­triert sich auf das Front­end und die In­te­gra­ti­on – bei­des sind Be­rei­che, in de­nen KI-ge­stütz­te Ent­wick­lung heu­te er­heb­li­che Ge­schwin­dig­keits­ge­win­ne er­mög­licht. Ein Next­JS-Front­end auf Ba­sis ei­ner Word­Press-API lässt sich heu­te we­sent­lich schnel­ler auf­bau­en als noch vor drei Jah­ren, weil ein Groß­teil der Code-Ge­ne­rie­rung durch KI-Werk­zeu­ge un­ter­stützt wird.

Wann eine voll­stän­di­ge In­di­vi­du­al­ent­wick­lung sinn­vol­ler ist

Wenn das, was ge­baut wer­den soll, weit über Con­tent-Ma­nage­ment hin­aus­geht – ei­ge­ne Be­nut­zer­kon­ten, kom­ple­xe Ge­schäfts­lo­gik, Echt­zeit-Da­ten, trans­ak­tio­na­le Funk­tio­nen –, dann ist Word­Press als Ba­ckend zu be­grenzt, egal ob Head­less oder nicht. In die­sen Fäl­len emp­feh­len wir den Wech­sel zu Su­pa­ba­se als Da­ten­schicht und Pay­load CMS oder gar kei­nem CMS als In­halts­schicht. Der Stack wird dann ge­ziel­ter, aber auch kom­ple­xer in der Ein­rich­tung.

Die Ent­schei­dung, die wir ge­mein­sam mit un­se­ren Kun­den tref­fen, ist nie tech­no­lo­gie­ge­trie­ben. Sie be­ginnt im­mer mit der Fra­ge: Was soll das Sys­tem in drei Jah­ren kön­nen – und wel­che Ar­chi­tek­tur er­mög­licht das mit dem ge­rings­ten struk­tu­rel­len Wi­der­stand?

War­um wir auf die­sen Stack set­zen

1. Word­Press als Ba­ckend: Rei­fe, die man nicht nach­bau­en kann

Word­Press wird seit 2003 ent­wi­ckelt. Das Plug­in-Öko­sys­tem um­fasst zehn­tau­sen­de Er­wei­te­run­gen, von de­nen vie­le über Jah­re pro­duk­tiv ein­ge­setzt und wei­ter­ent­wi­ckelt wur­den. Die Re­dak­ti­ons­ober­flä­che ken­nen Mil­lio­nen von Men­schen welt­weit. Die­se Rei­fe hat ei­nen ech­ten wirt­schaft­li­chen Wert: ge­rin­ge­re Ein­ar­bei­tungs­zei­ten, be­währ­te Lö­sun­gen für häu­fi­ge An­for­de­run­gen, ein brei­ter Markt an Ent­wick­lern und Sup­port-An­bie­tern. Für Con­tent-Ba­ckend-Auf­ga­ben gibt es we­nig, das in die­ser Kom­bi­na­ti­on mit­hal­ten kann.

2. WP­Gra­ph­QL: struk­tu­rier­te In­hal­te, sau­ber ab­ge­fragt

REST-APIs lie­fern mehr Da­ten als nö­tig. WP­Gra­ph­QL er­mög­licht prä­zi­se Ab­fra­gen – das Front­end er­hält ge­nau die Fel­der, die es braucht, in der Struk­tur, die es er­war­tet. Das re­du­ziert La­de­zei­ten, ver­ein­facht die Da­ten­ver­ar­bei­tung im Front­end und macht das API-De­sign ex­pli­zit statt im­pli­zit. Für kom­ple­xe Con­tent-Mo­del­le mit Be­zie­hun­gen zwi­schen ver­schie­de­nen In­halts­ty­pen ist Gra­ph­QL der sau­be­re­re An­satz.

3. Next­JS als Front­end: Per­for­mance und Fle­xi­bi­li­tät ohne Kom­pro­miss

Next­JS ist nicht des­halb un­se­re Wahl, weil es ge­ra­de mo­dern ist, son­dern weil es die rich­ti­gen Ei­gen­schaf­ten für lang­le­bi­ge Pro­jek­te mit­bringt. Ser­ver­sei­ti­ges Ren­de­ring für dy­na­mi­sche In­hal­te, sta­ti­sche Ge­ne­rie­rung für sta­bi­le Sei­ten, In­cre­men­tal Sta­tic Re­ge­ne­ra­ti­on für In­hal­te, die sich häu­fig ak­tua­li­sie­ren – jede Sei­te be­kommt die Ren­de­ring-Stra­te­gie, die zu ih­rem An­wen­dungs­fall passt. Das Er­geb­nis sind La­de­zei­ten im Mil­li­se­kun­den-Be­reich, Core Web Vi­tals-Wer­te, die SEO-An­for­de­run­gen er­fül­len, und eine Ar­chi­tek­tur, die un­ter Last sta­bil bleibt.

4. Edge-Caching und CDN: der letz­te Ki­lo­me­ter

Ein tech­nisch per­fek­tes Front­end bringt we­nig, wenn es beim Nut­zer lang­sam an­kommt. Wir in­te­grie­ren Cloud­fla­re oder ver­gleich­ba­re CDN-Lö­sun­gen in un­se­re De­ploy­ments – sta­ti­sche As­sets wer­den welt­weit ver­teilt, dy­na­mi­sche In­hal­te in­tel­li­gent ge­cacht. Der Un­ter­schied im Nut­zer­er­le­ben ist mess­bar, be­son­ders auf mo­bi­len Ver­bin­dun­gen und in Märk­ten au­ßer­halb gro­ßer Städ­te.

5. Self-Hos­ting wo sinn­voll, Ma­na­ged Ser­vices wo prak­tisch

Wir be­trei­ben Word­Press-Ba­ckends be­vor­zugt auf Hetz­ner oder Raid­bo­xes – je nach Pro­jekt­an­for­de­run­gen. Next­JS-Frontends de­ploy­en wir auf Hetz­ner, Ver­cel oder Net­li­fy. Die Ent­schei­dung hängt von Da­ten­schutz­an­for­de­run­gen, Be­triebs­mo­dell und Bud­get ab. Wir emp­feh­len, was passt – nicht, was uns die höchs­te Mar­ge bringt.

6. Er­fah­rung aus rea­len Pro­jek­ten

Wir ha­ben Head­less-Word­Press-Pro­jek­te für Un­ter­neh­men un­ter­schied­li­cher Bran­chen und Grö­ßen ge­baut – von con­tent­ge­trie­be­nen Mar­ke­ting-Platt­for­men über mehr­spra­chi­ge in­ter­na­tio­na­le Web­sites bis zu hy­bri­den Set­ups mit Com­mer­ce-In­te­gra­ti­on. Die­se Er­fah­rung fließt in jede Ar­chi­tek­tur­ent­schei­dung ein.