PublishLayer
EN NL
Terug naar blog
EN NL

Laravel contentplatform architectuur: headless, multi-site en workflow in één stack

2026-04-15 · 7 min leestijd

Veel organisaties groeien uit hun klassieke WordPress- of monolithische CMS-installatie. Je wilt meerdere merken, talen en kanalen bedienen, zonder je contentmodel telkens opnieuw uit te vinden. Tegelijk wil je AI inzetten in je redactieworkflow, maar niet je hele stack omgooien.

In die context is een Laravel content platform een logische keuze: een centrale, headless contentlaag met multi-site publishing en een expliciete workflowlaag. In dit artikel schetsen we een concrete architectuur die je als technische basis kunt gebruiken.

We focussen op:

  • Hoe je een headless CMS in Laravel structureert (contentmodel, API, permissions).
  • Hoe je multi site publishing in Laravel oplost zonder copy-paste content.
  • Hoe je een Laravel content workflow en AI-ondersteuning modelleert.
  • Hoe je vanaf dag één rekening houdt met SEO architectuur in Laravel.

Hoofdsectie: Architectuur van een Laravel content platform

1. Kernprincipes van een Laravel content platform

Een volwassen Laravel content platform draait om drie lagen:

  • Content kernel: generiek contentmodel, taxonomie, metadata, media.
  • Experience layer: sites, kanalen, presentatielogica, theming (buiten Laravel of in aparte frontends).
  • Workflow & governance: rollen, statussen, reviewflows, AI-assistentie, logging.

Laravel is hier geschikt omdat je:

  • Een strikt domeinmodel kunt opzetten (Eloquent + custom repositories).
  • API-first kunt werken (Laravel API Resources, Sanctum/Passport).
  • Complexe workflows en policies kunt afdwingen (Policies, Gates, Events, Jobs).

2. Headless CMS in Laravel: contentkernel en API

2.1 Contentmodel en entiteiten

De basis van een headless CMS in Laravel is een generiek maar uitbreidbaar contentmodel. Typische kernentiteiten:

  • ContentType: definieert het schema (velden, validatie, weergave).
  • ContentItem: de daadwerkelijke contentinstantie (JSON payload + relationele velden).
  • Taxonomy en Term: categorieën, tags, thematische clusters.
  • MediaAsset: afbeeldingen, documenten, video’s met varianten en rechten.

Een praktische aanpak is om de hoofdcontent in een content_items-tabel op te slaan met:

  • content_type_id
  • site_id (of null voor globale content)
  • locale
  • slug
  • data (JSON met velden)
  • status (draft, in_review, published, archived)
  • published_at, unpublished_at

Daarbovenop definieer je per ContentType een JSON-schema of eigen velddefinitie, zodat je flexibel blijft zonder voor elk type een aparte tabel te moeten maken.

2.2 API-laag en contracten

Een headless Laravel content platform staat of valt met een stabiel API-contract. Aanbevolen keuzes:

  • REST API voor de meeste frontends, met Laravel API Resources voor consistente output.
  • GraphQL als je veel verschillende frontends en complexe queries hebt.
  • Versionering via URL (/api/v1/...) of headers.

Belangrijke endpoints:

  • GET /content/{type} met filters op site, locale, status, taxonomy.
  • GET /content/{type}/{slug} voor detailweergave.
  • GET /navigation/{site} voor menu’s en sitemaps.
  • GET /search voor fulltext of externe zoekintegratie.

Voor performance combineer je:

  • Response caching (bijv. via Laravel cache tags per site/locale).
  • Eager loading van relaties (taxonomie, media, interne links).
  • Event-driven invalidatie bij publicatie of update.

3. Multi-site publishing in Laravel

3.1 Site- en kanaalmodel

Voor multi site publishing in Laravel heb je een expliciet Site-model nodig. Een Site kan een merk, land, taalvariant of microsite zijn. Minimale velden:

  • id, name, code (bijv. brand_a_nl).
  • primary_locale en ondersteunde locales.
  • domain of path_prefix.
  • SEO- en trackingconfiguratie.

Contentitems koppel je aan een of meerdere sites via:

  • Een directe site_id (1-op-1).
  • Een pivot-tabel content_item_site voor hergebruik over sites.

Daarnaast kun je een Channel-model introduceren voor non-web kanalen (app, e-mail, in-product help). Zo blijft je contentkernel kanaal-agnostisch.

3.2 Hergebruik en varianten

Multi-site wordt complex zodra content deels gedeeld en deels verschillend is. Een patroon dat goed werkt:

  • Global master: een bronitem zonder site_id (of met een "global" site).
  • Site-variant: een item dat verwijst naar een master via master_id en alleen afwijkende velden overschrijft.

In de API kun je dan:

  • Eerst de site-variant ophalen.
  • Ontbrekende velden aanvullen vanuit de master.

Dit maakt het mogelijk om bijvoorbeeld productbeschrijvingen centraal te beheren, maar per land andere CTA’s, prijzen of juridische teksten te tonen.

3.3 Toegangscontrole per site

In een multi-site omgeving wil je strikte scheiding van rechten. Gebruik Laravel Policies en Gates om:

  • Rollen per site te definiëren (bijv. editor_brand_a, publisher_brand_b).
  • Toegang tot contentitems te beperken op basis van gekoppelde sites.
  • Publicatierechten te scheiden van schrijfrechten.

Een veelgebruikte aanpak is een role_user_site-tabel, zodat een gebruiker per site een andere rol kan hebben.

4. Laravel content workflow en AI-ondersteuning

4.1 Workflowmodel

Een volwassen Laravel content workflow gaat verder dan draft/published. Minimaal wil je:

  • Draft: auteur werkt aan content.
  • In review: redactie of legal controleert.
  • Ready for publish: inhoud is goedgekeurd, wacht op planning.
  • Published: live op geselecteerde sites/kanalen.
  • Archived: niet meer actief, maar nog wel raadpleegbaar.

Implementeer dit met een expliciete workflow_state-kolom en een ContentWorkflowTransition-model dat bijhoudt:

  • Van- en naarstatus.
  • Gebruiker die de overgang uitvoerde.
  • Timestamp en eventuele opmerking.

Laravel Events en Listeners zijn geschikt om bij statuswijzigingen notificaties, Slack-berichten of JIRA-tickets te triggeren.

4.2 Laravel AI content workflow

AI hoort in deze architectuur niet in de renderinglaag, maar in de workflowlaag. Een Laravel AI content workflow kan bijvoorbeeld:

  • Suggesties doen voor titels, intro’s en meta descriptions.
  • Samenvattingen genereren voor andere kanalen (nieuwsbrief, changelog).
  • SEO-checks uitvoeren (keyword density, interne links, leesbaarheid).

Technisch kun je dit modelleren als:

  • Een AiSuggestion-model gekoppeld aan ContentItem.
  • Queued Jobs die AI-calls uitvoeren (bijv. via een externe API).
  • Een expliciete "accepted"-vlag zodat redacteuren AI-output moeten bevestigen.

Belangrijk is dat AI nooit direct publiceert, maar altijd via de bestaande workflow gaat. Zo blijft je content governance intact.

5. SEO architectuur in Laravel

5.1 SEO-velden in het contentmodel

Voor een robuuste SEO architectuur in Laravel is het verstandig om SEO-velden niet ad hoc in templates te stoppen, maar centraal te modelleren. Denk aan:

  • seo_title, meta_description, meta_robots.
  • canonical_url en redirect_from-lijsten.
  • Open Graph- en Twitter Card-velden.
  • Structured data (JSON-LD) per contenttype.

Deze velden kunnen onderdeel zijn van het data-JSON, of in een aparte seo_meta-tabel voor hergebruik en rapportage.

5.2 Interne linking en content clusters

Voor topical authority wil je interne linking en content clusters expliciet modelleren. Mogelijke aanpak:

  • Een ContentCluster-model (bijv. "Laravel content platform").
  • Een pivot-tabel cluster_content_item om items te koppelen.
  • Een InternalLink-model voor handmatige of AI-gegenereerde links.

Je API kan dan per item een lijst van gerelateerde artikelen teruggeven, gebaseerd op cluster, taxonomie en interne links. Frontends kunnen dit gebruiken voor automatische blokken als "Gerelateerde artikelen".

5.3 URL-strategie en multi-site

In een multi-site context moet je URL-strategie consistent zijn. Typische patronen:

  • https://brand-a.com/nl/{slug} voor taal per domein.
  • https://brand.com/nl/{slug} met hreflang-tags voor varianten.
  • https://brand.com/{site-code}/{slug} als je veel microsites hebt.

De URL-generatie hoort in de content- of routinglaag van Laravel, niet in de frontend. Zo kun je URL’s centraal wijzigen zonder alle frontends aan te passen.

Praktische voorbeelden

Voorbeeld 1: Eén contentkernel, meerdere WordPress-frontends

Een agency beheert tien WordPress-sites voor verschillende merken. In plaats van content per site te beheren, bouwen ze een Laravel content platform als centrale headless laag.

Architectuur:

  • Laravel beheert alle contenttypes (blog, cases, productpagina’s) en workflow.
  • Elke WordPress-site fungeert als "dumb" frontend die via REST API content ophaalt.
  • Multi-site wordt gemodelleerd via het Site-model; WordPress kent alleen een site-specifieke API-key.

Resultaat:

  • Content kan tussen merken worden hergebruikt via master/variant-model.
  • SEO-velden worden centraal beheerd; WordPress-templates renderen alleen.
  • AI-suggesties voor titels en meta descriptions worden in Laravel gegenereerd en door redacteuren per site geaccepteerd.

Voorbeeld 2: SaaS-documentatie en in-product help

Een SaaS-bedrijf wil documentatie, marketingblog en in-product help uit één bron beheren.

Implementatie:

  • ContentTypes: doc_page, release_note, blog_post, help_snippet.
  • Sites: marketing_site, docs_site, in_app_help.
  • Channels: web, in-app widget, e-mail.

De Laravel API levert:

  • Volledige pagina’s voor de docs-site.
  • Korte samenvattingen (door AI gegenereerd) voor in-product tooltips.
  • Release notes voor changelog en e-mailnieuwsbrief.

Workflow:

  • Product owner maakt een draft van release notes.
  • AI genereert samenvattingen per kanaal.
  • Redactie keurt de tekst goed en plant publicatie.
  • Publicatie-event triggert cache-invalidatie voor alle betrokken sites en kanalen.

Voorbeeld 3: Meertalige content met gedeelde SEO-strategie

Een internationaal merk wil meertalige content met consistente SEO-strategie.

Setup:

  • Global master-artikelen in Engels.
  • Locale-varianten per land met vertaalde content, maar gedeelde canonical-strategie.
  • Clusters voor hoofdthema’s (bijv. "headless cms laravel", "laravel content workflow").

De Laravel-architectuur zorgt voor:

  • Automatische hreflang-sets op basis van beschikbare varianten.
  • Gedeelde structured data per cluster (bijv. FAQPage voor alle landen).
  • AI-ondersteuning voor eerste vertaalvoorstellen, met menselijke review in de workflow.

Conclusie

Een goed ontworpen Laravel content platform combineert headless contentbeheer, multi-site publishing en een expliciete workflowlaag in één consistente stack. Door contentkernel, experience layer en workflow te scheiden, voorkom je dat je architectuur vastgroeit aan één frontend of één merk.

Belangrijke ontwerpkeuzes zijn:

  • Een generiek maar uitbreidbaar contentmodel met duidelijke scheiding tussen types, items, taxonomie en SEO-meta.
  • Een expliciet Site- en eventueel Channel-model voor multi-site en multi-channel publicatie.
  • Een workflowlaag die statussen, rollen en AI-ondersteuning modelleert zonder governance te omzeilen.
  • Een SEO-architectuur in Laravel die URL’s, interne links, structured data en meta-informatie centraal beheert.

Met deze basis kun je stapsgewijs uitbreiden: eerst één site migreren naar de headless laag, daarna extra merken, talen en kanalen aansluiten. Zo groeit je Laravel-platform mee met je contentstrategie, zonder dat je bij elke nieuwe site opnieuw moet beginnen.

Wil je dieper inzoomen op specifieke onderdelen van deze architectuur, zoals contentclusters of workflowdesign, bekijk dan ook de gerelateerde artikelen hieronder.

Related reading: Related article 1 · Related article 3 · Related article 4 · Related article 5

Gegenereerd met PublishLayer

Bekijk product Bekijk prijzen