Laravel Content Platform Architecture: Headless, Multi-Site, and Workflow in One Stack

Many organizations outgrow their classic WordPress or monolithic CMS setup. You want to serve multiple brands, languages, and channels without reinventing your content model each time. At the same time, you want to leverage AI in your editorial workflow without overhauling your entire stack.

In this context, a Laravel content platform is a logical choice: a central, headless content layer with multi-site publishing and an explicit workflow layer. In this article, we outline a concrete architecture you can use as a technical foundation.

We focus on:

• How to structure a headless CMS in Laravel (content model, API, permissions).
• How to solve multi-site publishing in Laravel without copy-pasting content.
• How to model a Laravel content workflow and AI support.
• How to account for SEO architecture in Laravel from day one.

Main Section: Architecture of a Laravel Content Platform

1. Core Principles of a Laravel Content Platform

A mature Laravel content platform revolves around three layers:

• Content kernel: generic content model, taxonomy, metadata, media.
• Experience layer: sites, channels, presentation logic, theming (outside Laravel or in separate frontends).
• Workflow & governance: roles, statuses, review flows, AI assistance, logging.

Laravel is suitable here because you can:

• Set up a strict domain model (Eloquent + custom repositories).
• Work API-first (Laravel API Resources, Sanctum/Passport).
• Enforce complex workflows and policies (Policies, Gates, Events, Jobs).

2. Headless CMS in Laravel: Content Kernel and API

2.1 Content Model and Entities

The foundation of a headless CMS in Laravel is a generic yet extensible content model. Typical core entities:

• ContentType: defines the schema (fields, validation, display).
• ContentItem: the actual content instance (JSON payload + relational fields).
• Taxonomy and Term: categories, tags, thematic clusters.
• MediaAsset: images, documents, videos with variants and permissions.

A practical approach is to store the main content in a content_items table with:

• content_type_id
• site_id (or null for global content)
• locale
• slug
• data (JSON with fields)
• status (draft, in_review, published, archived)
• published_at, unpublished_at

On top of that, you define a JSON schema or custom field definition per ContentType, so you remain flexible without having to create a separate table for each type.

2.2 API Layer and Contracts

A headless Laravel content platform stands or falls with a stable API contract. Recommended choices:

• REST API for most frontends, using Laravel API Resources for consistent output.
• GraphQL if you have many different frontends and complex queries.
• Versioning via URL (/api/v1/...) or headers.

Important endpoints:

• GET /content/{type} with filters on site, locale, status, taxonomy.
• GET /content/{type}/{slug} for detail view.
• GET /navigation/{site} for menus and sitemaps.
• GET /search for full-text or external search integration.

For performance, combine:

• Response caching (e.g., via Laravel cache tags per site/locale).
• Eager loading of relations (taxonomy, media, internal links).
• Event-driven invalidation on publish or update.

3. Multi-Site Publishing in Laravel

3.1 Site and Channel Model

For multi-site publishing in Laravel, you need an explicit Site model. A Site can be a brand, country, language variant, or microsite. Minimal fields:

• id, name, code (e.g., brand_a_nl).
• primary_locale and supported locales.
• domain or path_prefix.
• SEO and tracking configuration.

You link content items to one or more sites via:

• A direct site_id (1-to-1).
• A pivot table content_item_site for reuse across sites.

Additionally, you can introduce a Channel model for non-web channels (app, email, in-product help). This keeps your content kernel channel-agnostic.

3.2 Reuse and Variants

Multi-site gets complex when content is partly shared and partly different. A pattern that works well:

• Global master: a source item without site_id (or with a "global" site).
• Site variant: an item referencing a master via master_id and only overwriting differing fields.

In the API, you can then:

• First fetch the site variant.
• Fill in missing fields from the master.

This makes it possible, for example, to centrally manage product descriptions but show different CTAs, prices, or legal texts per country.

3.3 Access Control Per Site

In a multi-site environment, you want strict separation of rights. Use Laravel Policies and Gates to:

• Define roles per site (e.g., editor_brand_a, publisher_brand_b).
• Restrict access to content items based on linked sites.
• Separate publishing rights from writing rights.

A common approach is a role_user_site table so a user can have different roles per site.

4. Laravel Content Workflow and AI Support

4.1 Workflow Model

A mature Laravel content workflow goes beyond draft/published. At minimum, you want:

• Draft: author works on content.
• In review: editorial or legal review.
• Ready for publish: content approved, awaiting scheduling.
• Published: live on selected sites/channels.
• Archived: no longer active but still accessible.

Implement this with an explicit workflow_state column and a ContentWorkflowTransition model that tracks:

• From and to status.
• User who performed the transition.
• Timestamp and any comments.

Laravel Events and Listeners are suitable to trigger notifications, Slack messages, or JIRA tickets on status changes.

4.2 Laravel AI Content Workflow

AI belongs in this architecture not in the rendering layer but in the workflow layer. A Laravel AI content workflow can, for example:

• Make suggestions for titles, intros, and meta descriptions.
• Generate summaries for other channels (newsletter, changelog).
• Perform SEO checks (keyword density, internal links, readability).

Technically, you can model this as:

• An AiSuggestion model linked to ContentItem.
• Queued Jobs that perform AI calls (e.g., via an external API).
• An explicit "accepted" flag so editors must confirm AI output.

It is important that AI never publishes directly but always goes through the existing workflow. This keeps your content governance intact.

5. SEO Architecture in Laravel

5.1 SEO Fields in the Content Model

For a robust SEO architecture in Laravel, it is wise not to put SEO fields ad hoc in templates but to model them centrally. Think of:

• seo_title, meta_description, meta_robots.
• canonical_url and redirect_from lists.
• Open Graph and Twitter Card fields.
• Structured data (JSON-LD) per content type.

These fields can be part of the data JSON or in a separate seo_meta table for reuse and reporting.

5.2 Internal Linking and Content Clusters

For topical authority, you want to explicitly model internal linking and content clusters. Possible approach:

• A ContentCluster model (e.g., "Laravel content platform").
• A pivot table cluster_content_item to link items.
• An InternalLink model for manual or AI-generated links.

Your API can then return a list of related articles per item based on cluster, taxonomy, and internal links. Frontends can use this for automatic blocks like "Related Articles."

5.3 URL Strategy and Multi-Site

In a multi-site context, your URL strategy must be consistent. Typical patterns:

• https://brand-a.com/en/{slug} for language per domain.
• https://brand.com/en/{slug} with hreflang tags for variants.
• https://brand.com/{site-code}/{slug} if you have many microsites.

URL generation belongs in the content or routing layer of Laravel, not in the frontend. This way, you can change URLs centrally without adjusting all frontends.

Practical Examples

Example 1: One Content Kernel, Multiple WordPress Frontends

An agency manages ten WordPress sites for different brands. Instead of managing content per site, they build a Laravel content platform as a central headless layer.

Architecture:

• Laravel manages all content types (blog, cases, product pages) and workflow.
• Each WordPress site acts as a "dumb" frontend fetching content via REST API.
• Multi-site is modeled via the Site model; WordPress only knows a site-specific API key.

Result:

• Content can be reused between brands via master/variant model.
• SEO fields are managed centrally; WordPress templates only render.
• AI suggestions for titles and meta descriptions are generated in Laravel and accepted by editors per site.

Example 2: SaaS Documentation and In-Product Help

A SaaS company wants to manage documentation, marketing blog, and in-product help from one source.

Implementation:

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

The Laravel API delivers:

• Full pages for the docs site.
• Short summaries (AI-generated) for in-product tooltips.
• Release notes for changelog and email newsletter.

Workflow:

• Product owner creates a draft of release notes.
• AI generates summaries per channel.
• Editorial approves the text and schedules publication.
• Publish event triggers cache invalidation for all involved sites and channels.

Example 3: Multilingual Content with Shared SEO Strategy

An international brand wants multilingual content with a consistent SEO strategy.

Setup:

• Global master articles in English.
• Locale variants per country with translated content but shared canonical strategy.
• Clusters for main themes (e.g., "headless cms laravel", "laravel content workflow").

The Laravel architecture ensures:

• Automatic hreflang sets based on available variants.
• Shared structured data per cluster (e.g., FAQPage for all countries).
• AI support for initial translation proposals, with human review in the workflow.

Conclusion

A well-designed Laravel content platform combines headless content management, multi-site publishing, and an explicit workflow layer in one consistent stack. By separating content kernel, experience layer, and workflow, you prevent your architecture from being tied to one frontend or one brand.

Key design choices are:

• A generic but extensible content model with clear separation between types, items, taxonomy, and SEO meta.
• An explicit Site and optionally Channel model for multi-site and multi-channel publishing.
• A workflow layer that models statuses, roles, and AI support without bypassing governance.
• An SEO architecture in Laravel that centrally manages URLs, internal links, structured data, and meta information.

With this foundation, you can expand step-by-step: first migrate one site to the headless layer, then add more brands, languages, and channels. This way, your Laravel platform grows with your content strategy without having to start over with each new site.

If you want to dive deeper into specific parts of this architecture, such as content clusters or workflow design, also check out the related articles below.

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