From monolith to headless: WordPress transformation for more efficient e-commerce applications

1. Introduction

The world of e-commerce is developing at a rapid pace, and users’ expectations regarding the speed and personalisation of websites are constantly growing. In this context, Headless architecture has gained recognition as one of the most modern approaches to website development, including WordPress-based sales platforms. In this article, we will look at how WordPress – known for its traditional, monolithic architecture – can be transformed into a Headless platform that allows the use of modern frameworks, such as Gatsby, to increase performance, scalability and flexibility.

What is headless architecture?

Headless architecture involves separating the backend (which handles content and data) from the frontend (the user interface). In the case of WordPress, which traditionally combines these two layers, the headless approach allows it to be used exclusively as a content management system (CMS). The data is then made available via an API (REST API or GraphQL), and the frontend is created using technologies such as React, Vue.js, Gatsby, etc.

Why consider Headless WordPress in e-commerce?

1. Page loading speed: Thanks to static site generation (SSG) possible in Gatsby, e-commerce websites can load faster, which translates into a better user experience and higher conversion rates.
2. Scalability: Headless allows you to handle more users and traffic without overloading the backend server.
3. Flexibility: Separating layers allows for full frontend customisation, which is crucial in modern online shops.
4. SEO: Static pages generated by Gatsby are optimised for search engines, which has a positive impact on product positioning.
5. Multilingualism: Solutions such as WPML and Polylang can be easily integrated with Headless WordPress, enabling support for global customers.

Gatsby as a modern frontend development tool

Gatsby is a React-based framework that enables the creation of super-fast websites thanks to Static Site Generation (SSG). Combined with WordPress as a headless CMS, Gatsby provides:

• The ability to generate static pages based on data retrieved from WordPress using GraphQL.
• Dynamic functionalities, such as shopping cart and payment support, thanks to the connection with the WooCommerce API.

Purpose of the article

The purpose of this article is to provide a step-by-step guide on how to transition from traditional WordPress architecture to a headless approach using Gatsby. We will also address issues related to WooCommerce and multilingual websites, as well as discuss the advantages, disadvantages, and challenges of this solution. This will give you the comprehensive knowledge you need to decide whether Headless WordPress is the right approach for your e-commerce project.

2. Traditional WordPress vs Headless WordPress with Gatsby

WordPress is one of the most popular content management systems (CMS) used in both small blogs and large online shops. In its traditional form, WordPress works as a monolith, which means that the backend (content management, database) and frontend (content display) are closely linked.

How does monolithic WordPress work?

1. The backend is responsible for content management, plugin configuration, and database handling (MySQL).
2. The frontend dynamically generates user pages based on PHP templates.
3. Plugins and themes integrate additional features, e.g. WooCommerce adds online shops.

Limitations of traditional architecture

1. Page loading speed: Dynamic page generation (on demand) can cause slowdowns, especially with high traffic.
2. Lack of flexibility: WordPress themes have limited options for customising and personalising the user interface.
3. Performance issues: With a large number of WooCommerce products, the database can become a bottleneck.
4. SEO: Dynamically generated pages are often not as search engine optimised as static pages.

Headless architecture in WordPress

Headless architecture separates the backend from the frontend, allowing WordPress to serve solely as a CMS, with data being served via REST API or GraphQL. The frontend is built using modern frameworks such as Gatsby, allowing for complete control over content display.

Advantages of the Headless approach

1. Speed and performance: Thanks to the generation of static pages in Gatsby, users receive pages faster, which improves the user experience (UX).
2. Flexibility: The ability to build any interface using technologies such as React.
3. Scalability: The WordPress backend is not burdened by the frontend, allowing it to handle more traffic.
4. SEO and optimisation: Static pages generated in Gatsby are optimised for search engines (e.g. better use of metadata and loading speed).

Gatsby in Headless WordPress

Gatsby is a React-based framework that enables the creation of fast, static websites. Thanks to its built-in GraphQL system, Gatsby can retrieve data from various sources, including WordPress as a headless CMS.

How does Gatsby integration with WordPress work?

1. Data source: WordPress provides content using GraphQL (e.g., WPGraphQL plugin).
2. Data retrieval: Gatsby retrieves content and generates static pages during the build process.
3. Page serving: The generated HTML and CSS files are served via CDN, ensuring fast loading times.

Example of Gatsby configuration with WordPress

1. 1. Install the WPGraphQL plugin in WordPress:
      1. In the WordPress panel, go to the “Plugins” section and install the WPGraphQL plugin.
      2. After installing the plugin, the GraphQL API will be available at:
         https://twojadomena.pl/graphql
         

• Configure Gatsby to work with WordPress:

1. 1. Install the appropriate Gatsby plugin in your project:
      npm install gatsby-source-wordpress
2. Add the configuration to the gatsby-config.js file:

module.exports = {

plugins: [{

resolve: `gatsby-source-wordpress`,

options: {

url: `https://twojadomena.pl/graphql`,

schema: {

timeout: 30000,

},

develop:

hardCacheMediaFiles: true,

},

},

}

]

};

• Example GraphQL query in Gatsby: Here is an example of fetching posts from WordPress:

module.exports = {

plugins: [

{

resolve: `gatsby-source-wordpress`,

options: {

url: `https://twojadomena.pl/graphql`

schema: {

timeout: 30000,

},

develop: {

hardCacheMediaFiles: true

},

},

},

},

};

• Creating pages in Gatsby using GraphQL: Add code to the gatsby-node.js file to dynamically generate pages for posts:

exports.createPages = async ({ graphql, actions }) => {

const { createPage } = actions;

const result = await graphql(`

query {

allWpPost {

nodes {

id

slug

}

}

}

);

 

result.data.allWpPost.nodes.forEach((post) => {

createPage({

path: `/blog/${post.slug}`,

component: require.resolve(`./src/templates/post.js`),

context: {

id: post.id,

},

});

});

};

 

Comparison: Traditional WordPress vs Headless WordPress with Gatsby

Criterion	Traditional WordPress	Headless WordPress with Gatsby
Performance	Dynamic pages, slower with high traffic.	Fast, static pages served by CDN.
Scalability	Limited by the backend and server.	Backend and frontend independence.
Flexibility	Limited by themes and plugins.	Complete freedom in frontend development.
SEO	May require additional optimisation.	Optimised for speed and HTML structure.
Technologies	PHP, MySQL	React, GraphQL, Node.js, etc.

3. REST API vs GraphQL in Headless WordPress

One of the key aspects of implementing Headless architecture in WordPress is choosing the right mechanism for transferring data between the backend and frontend. WordPress offers two main solutions: REST API and GraphQL (via the WPGraphQL plugin). Each has its advantages and limitations, which we will discuss in this section.

REST API in WordPress

REST API has been a default feature of WordPress since version 4.7 and allows access to content via HTTP queries. Data is returned in JSON format, making it easy to use in frontend applications such as Gatsby.

Advantages of REST API

1. Ease of use: REST API uses popular HTTP methods (GET, POST, PUT, DELETE), making it intuitive for most developers.
2. Versatility: REST API can be used with any frontend application, regardless of the programming language.
3. Built into WordPress by default: No additional plugins required.

Example of a REST API query

To retrieve a list of entries from WordPress, you can use the following request:
GET https://twojadomena.pl/wp-json/wp/v2/posts

Response:

[

{

“id”: 1,

“title”: { “rendered”: “Sample title” },

“content”: { “rendered”: “<p>Sample content</p>” },

“slug”: “example-title”

}

]

 

REST API limitations

1. Data redundancy: REST API returns all data, even if you only need part of it. This can cause excessive server load.
2. Scalability: For large websites, REST API may be less efficient due to the number of requests.
3. Lack of query flexibility: You cannot easily customise the data structure to suit your needs – you have to filter the results on the client side.

GraphQL with WPGraphQL

GraphQL is an alternative way of transferring data that offers greater flexibility. With the WPGraphQL plugin, WordPress can act as a GraphQL server, allowing the frontend to precisely define what data is needed.

Advantages of GraphQL

1. Flexibility: You can specify exactly what data you want to retrieve, which reduces the amount of information transferred.
2. Performance optimisation: With smaller API requests, GraphQL is more efficient in large projects.
3. Complex relationships: GraphQL allows you to retrieve related data (e.g., posts with their categories) in a single query.

Example of a GraphQL query

To retrieve a list of entries along with their categories:

query {

posts {

nodes {

id

title

slug

categories {

nodes {

name

}

}

 

}

}

 

Answer:

{

“data”: {

“posts”: {

“nodes”: [

{

“id”: “1”,

“title”: “Sample title”,

“slug”: “example-title”,

“categories”: {

“nodes”: [

{ “name”: “Category 1” },

{ “name”: “Category 2” }

]

}

}

]

}

}

}

GraphQL limitations

1. Plugin installation required: WPGraphQL must be installed and configured in WordPress.
2. Learning curve: For developers unfamiliar with GraphQL, understanding its principles may take time.
3. Plugin support: Not all WordPress plugins (e.g. WooCommerce) support WPGraphQL by default. Additional plugins or customisations may be necessary.

REST API vs GraphQL: When to choose which one?

Criterion	REST API	GraphQL
Flexibility	Limited	High – full control over queries
Performance	Less efficient for large projects	Optimal for large websites
Learning curve	Easier	Requires additional learning
Plugin support	Built-in support	Requires additional plugins
Implementation	Default in WordPress	Requires WPGraphQL installation

REST API and GraphQL integration with Gatsby

REST API with Gatsby

Adding REST API as a data source in Gatsby requires the use of the gatsby-source-rest-api plugin:
npm install gatsby-source-rest-api

Configuration in gatsby-config.js:

module.exports = {

plugins: [

{

resolve: “gatsby-source-rest-api”,

options: {

endpoints: [

“https://twojadomena.pl/wp-json/wp/v2/posts”

],

},

},

],

};

 

GraphQL with Gatsby

WPGraphQL can be configured with Gatsby using gatsby-source-wordpress:

module.exports = {

plugins: [

{

resolve: “gatsby-source-wordpress”,

options: {

url: “https://twojadomena.pl/graphql”,

},

},

],

};

 

Summary: Which approach should you choose?

• REST API will be suitable for smaller projects where data is simple and structured.
• GraphQL will work well for large websites with complex data relationships, such as e-commerce with WooCommerce.
• If you plan to use Gatsby, GraphQL will provide a smoother integration process thanks to its built-in query handling mechanism.

4. Headless WooCommerce: Technical aspects of implementation

WooCommerce, as one of the most popular WordPress-based e-commerce platforms, offers extensive capabilities for managing products, orders, and customers. However, in a traditional, monolithic architecture, it can become a limitation for large online shops. Integrating WooCommerce into a headless environment with Gatsby allows for improved platform performance and flexibility. In this section, we will discuss in detail how to implement WooCommerce in a headless environment.

Advantages of integrating WooCommerce into Headless WordPress

1. Improved performance:
   • Static generation of product pages in Gatsby reduces loading time, which translates into higher conversion rates.
   • The frontend, relieved of the WordPress backend, runs faster, especially with high traffic.
2. Better user experience (UX):
   • The ability to build modern user interfaces using React and Gatsby.
   • Dynamic functionalities, such as shopping carts and payments, can be handled independently by the API.
3. Scalability:
   • Separating the backend and frontend allows for easier scaling in response to growing user needs.
4. SEO:
   • Generating optimised static pages improves search engine rankings.

How to implement Headless WooCommerce?

1. Preparing the WordPress backend

For WooCommerce to work in a Headless environment, you need to configure the WordPress backend to share data using REST API or GraphQL.

1. a) WooCommerce REST API
   WooCommerce supports REST API by default. To access product, order, and customer data, you need to create API keys in WooCommerce:

• Go to WooCommerce > Settings > Advanced > REST API and create the keys.
• Use the following request to retrieve a list of products:

GET: https://twojadomena.pl/wp-json/wc/v3/products?consumer_key=TWÓJ_KLUCZ&consumer_secret=TWÓJ_SEKRET

Sample response:

[

{

“id”: 1,

“name”: “Product 1”,

“price”: “99.99”,

“stock_quantity”: 10,

“slug”: “product-1”

}

]

 

1. b) WPGraphQL for WooCommerce
   To use GraphQL, you need to install the WPGraphQL for WooCommerce plugin:

• Download and activate the plugin.
• After installation, the GraphQL API for WooCommerce will be available at /graphql.

Example GraphQL query retrieving products:

query {

products {

nodes {

id

name

price

stockQuantity

slug

}

}

}

2. Integrating Gatsby with WooCommerce

After preparing the WordPress backend, we configure Gatsby as the frontend for WooCommerce.

1. a) Installing Gatsby plugins
   Install gatsby-source-wordpress for GraphQL integration:
   npm install gatsby-source-wordpress

 

1. b) Configuring the data source in gatsby-config.js:

plugins: [

{

resolve: “gatsby-source-wordpress”,

options: {

url: “https://twojadomena.pl/graphql”,

},

},

]

1. c) Creating product pages in Gatsby:

Add a function to gatsby-node.js to dynamically generate product pages:

exports.createPages = async ({ graphql, actions }) => {

const { createPage } = actions;

const result = await graphql(`

query {

products {

nodes {

id

slug

}

}

}

);

result.data.products.nodes.forEach((product) => {

createPage({

path: `/product/${product.slug}`,

component: require.resolve(`./src/templates/product.js`),

context: {

id: product.id,

},

});

});

};

 

1. d) Displaying product details in Gatsby:

Example of a React component that fetches product data:

import React from “react”;

 

import { graphql } from “gatsby”;

 

export const query = graphql`

query($id: ID!) {

product(id: $id) {

name

description

price

stockQuantity

}

}

`;

 

const ProductTemplate = ({ data }) => {

const { name, description, price, stockQuantity } = data.product;

 

return (

<div>

<h1>{name}</h1>

<p>{description}</p>

<p>Price: {price} PLN</p>

<p>Availability: {stockQuantity} items</p>

</div>

);

};

 

export default ProductTemplate;

Problems and challenges in Headless WooCommerce

1. Shopping cart and payments:
   • Gatsby generates static pages, but features such as shopping cart and payments must be handled dynamically.
   • Solution: Use dynamic server functions (e.g. Netlify Functions, AWS Lambda) or the WooCommerce API.
2. Plugin compatibility:
   • Not all WooCommerce plugins are compatible with WPGraphQL or REST API.
   • Solution: Check for alternative plugins or customise the API.
3. API security:
   • Exposing the API publicly can lead to abuse.
   • Solution: Restrict access to the API using keys, IP restrictions, or middleware.

Summary: Why choose Headless WooCommerce?

Headless WooCommerce with Gatsby is a solution for e-commerce shops that want to achieve better performance, flexibility, and scalability. By integrating the WooCommerce API with a modern frontend, shop owners can offer users fast, optimised product pages while taking advantage of the advanced features of the WordPress backend.

5. Multilingual websites with Headless WordPress

In the era of globalisation, more and more e-commerce stores need to serve users from different countries and in different languages. WordPress, as a CMS, offers two popular solutions for multilingual support: WPML and Polylang. In a headless environment, integrating these plugins with REST API or GraphQL and the Gatsby framework requires additional steps. In this section of the article, we will discuss how to effectively manage multilingual websites in a headless architecture.

WPML and Polylang in traditional WordPress

WPML

WPML (WordPress Multilingual Plugin) is one of the oldest and most widely used plugins for multilingual support in WordPress.

• Advantages:
  • Intuitive translation management interface.
  • Full compatibility with WooCommerce.
  • SEO support, including dynamic XML sitemaps in multiple languages.
• Limitations:
  • High database load for multilingual websites.
  • Requires separate configuration for each language in a headless environment.

Polylang

Polylang is a lighter alternative to WPML that provides basic multilingual support.

• Advantages:
  • Free version available for basic features.
  • Easier to configure for smaller websites.
• Limitations:
  • Less advanced features compared to WPML (e.g. no built-in WooCommerce translation).

Integration of WPML and Polylang in a headless environment

When switching to Headless WordPress, both WPML and Polylang must be properly configured to share data in different languages via API.

Configuring WPML with REST API and GraphQL

1. REST API: WPML automatically adds language parameters to REST API queries. Example REST API request:
   GET https://twojadomena.pl/wp-json/wp/v2/posts?lang=plResponse:

[

{

id: 1,

title: { rendered: “Example title” },

slug: “example-title”,

lang: “en”,

},

];

 

1. GraphQL: WPGraphQL for WPML is a plugin that extends the functionality of WPGraphQL with language support.
   Example GraphQL query:

query {

posts(where: { language: EN }) {

nodes {

id

title

slug

language {

code

}

}

}

}

 

Answer:

{

“data”: {

“posts”: {

“nodes”: [

{

“id”: “1”,

“title”: “Sample title”,

“slug”: “example-title”,

“language”: {

“code”: “EN”

}

}

]

}

}

}

 

Polylang configuration with REST API and GraphQL

1. REST API: Polylang supports languages by adding the lang parameter to REST API queries. Example query:
   GET https://twojadomena.pl/wp-json/wp/v2/posts?lang=enResponse:

[

{

“id”: 2,

“title”: { “rendered”: “Example title” },

“slug”: “example-title”,

“lang”: “en”

}

]

 

1. GraphQL: Polylang requires additional plugins or customisations to work in a GraphQL environment. In practice, dedicated solutions or migration to WPML are often used in more advanced projects.

 

Gatsby configuration for multilingual websites

1. Multi-language support in gatsby-config.js

Adding data sources for different languages in Gatsby:

module.exports = {

plugins: [

{

resolve: “gatsby-source-wordpress”,

options: {

url: “https://twojadomena.pl/graphql”,

schema: {

requestConcurrency: 5,

},

develop: {

hardCacheMediaFiles: true,

},

debug: {

graphql: false,

},

},

},

],

};

 

2. Creating dynamic language paths

Add code to gatsby-node.js to dynamically generate pages in different languages:

exports.createPages = async ({ graphql, actions }) => {

const { createPage } = actions;

const result = await graphql(`

query {

allWpPost {

nodes {

id

slug

language {

code

}

}

}

}

);

result.data.allWpPost.nodes.forEach((post) => {

createPage({

path: `/${post.language.code}/blog/${post.slug}`,

component: require.resolve(`./src/templates/post.js`),

context: {

id: post.id,

language: post.language.code,

},

});

});

};

 

3. Language switch support

Add a language switcher to the frontend, e.g. in React:

import React from “react”;

import { Link } from “gatsby”;

 

const LanguageSwitcher = ({ currentLang, slug }) => {

 

const languages = [“en”, “pl”, “de”]; // List of available languages

 

return (

<div>

{languages.map((lang) => (

<Link key={lang} to={`/${lang}/${slug}`}>

{lang.toUpperCase()}

</Link>

))}

</div>

);

};

 

export default LanguageSwitcher;

 

Problems and challenges in multilingual websites

1. Support for dynamic language paths:
   • Requires advanced configuration in both the backend and frontend.
2. Translation synchronisation:
   • WPML and Polylang may require manual synchronisation of content in different languages.
3. SEO for multiple languages:
   • Requires generating dynamic XML sitemaps for each language.
   • Implementation of hreflang tags in generated pages.

 

Summary: WPML or Polylang in Headless?

Criterion	WPML	Polylang
WooCommerce support	Fully supported	Requires additional plugins
Advanced features	Extensive capabilities	Basic functionality
Integration with GraphQL	WPGraphQL for WPML	Requires customisation
Price	Paid version	Free basic option

 

Benefits of multilingualism in Headless WordPress

1. The ability to reach global markets.
2. Better SEO positioning in different regions.
3. Personalisation of content for users from different countries.

 

6. Practical implementation example: Case Study

In this section, we will present a step-by-step guide on how to implement Headless WordPress with WooCommerce, Gatsby, and multilingual support. We will look at backend configuration, API integration, and creating dynamic pages in different languages on the front end.

 

Project description

Our goal is to create a multilingual e-commerce shop based on WordPress (backend), WooCommerce (product and order management), Gatsby (frontend) and WPGraphQL (API interface). The website will:

1. Support dynamic data such as shopping cart and payments.
2. Display content in three languages (English, Polish, and German).
3. Generate optimised static pages for better SEO.

 

1. Preparing the WordPress backend

WordPress and WooCommerce configuration

1. 1. WooCommerce installation:
      • Install and activate the WooCommerce plugin.
      • Configure products, categories, and payment settings.
   2. Adding WPGraphQL and WPGraphQL for WooCommerce:
      • Download and activate the WPGraphQL and WPGraphQL for WooCommerce plugins.
      • Ensure that the GraphQL API is working correctly by visiting:
        https://twojadomena.pl/graphql

• Adding WPML or Polylang:

1. • Install your chosen multilingual plugin.
   • Configure languages, product translations, and categories.
   • For WPGraphQL for WPML, ensure that translations are available in the API.

 

2. Configuring Gatsby as a frontend

Installing Gatsby and plugins

Install Gatsby and the required plugins:
npm install gatsby gatsby-source-wordpress gatsby-plugin-react-i18next

 

Configuring gatsby-config.js

Add the GraphQL data source:

module.exports = {

plugins: [

{

resolve: “gatsby-source-wordpress”,

options: {

url: “https://twojadomena.pl/graphql”,

schema: {

timeout: 30000,

},

develop: {

hardCacheMediaFiles: true,

},

},

},

{

resolve: “gatsby-plugin-react-i18next”,

options: {

languages: [“en”, “pl”, “de”],

defaultLanguage: “en”,

i18nextOptions: {

interpolation: {

escapeValue: false,

},

},

},

},

],

};

 

3. Generating product pages and translations

Creating dynamic product pages

Add code to gatsby-node.js to generate pages for products in different languages:

exports.createPages = async ({ graphql, actions }) => {

const { createPage } = actions;

const result = await graphql(`

query {

products {

nodes {

id

slug

language {

code

}

}

}

}

);

 

result.data.products.nodes.forEach((product) => {

createPage({

path: `/${product.language.code}/product/${product.slug}`,

component: require.resolve(`./src/templates/product.js`),

context: {

id: product.id,

language: product.language.code,

},

});

});

};

 

Sample product template

We create the src/templates/product.js file:

import React from “react”;

import { graphql } from “gatsby”;

 

export const query = graphql`

query($id: ID!, $lang: String!) {

product(id: $id) {

name

description

price

}

}

`;

 

const ProductTemplate = ({ data }) => {

const { name, description, price } = data.product;

 

return (

<div>

<h1>{name}</h1>

<p>{description}</p>

<p>Price: {price} USD</p>

</div>

);

};

 

export default ProductTemplate;

 

4. Shopping cart and payment handling

WooCommerce offers a dynamic API for shopping cart and payments. In the Gatsby environment, you can use server functions (e.g. Netlify Functions) to handle requests.

Dynamic shopping cart using REST API

Add a function to handle adding products to the shopping cart:

export const addToCart = async (productId, quantity) => {

const response = await fetch(

https://twojadomena.pl/wp-json/wc/v3/cart/add,

{

method: “POST”,

headers: {

“Content-Type”: “application/json”,

},

body: JSON.stringify({

id: productId,

quantity: quantity,

}),

}

);

return response.json();

};

 

5. SEO optimisation

Dynamic XML sitemaps

Configure WPML or Polylang to generate XML sitemaps for each language:

• WPML: Enable dynamic sitemaps in the SEO settings.
• Polylang: Use the Yoast SEO plugin with the Polylang add-on.

Hreflang tags in Gatsby

Add hreflang tags to each page:

import React from “react”;

import { Helmet } from “react-helmet”;

 

const SEO = ({ lang, url }) => (

<Helmet>

<link rel=”alternate” hrefLang={lang} href={url} />

</Helmet>

);

 

export default SEO;

 

6. Results and conclusions

After implementing Headless WordPress with WooCommerce, Gatsby, and multilingual support, we achieved:

1. Better performance: Page load times reduced by 50%.
2. Higher SEO: Search engine rankings increased thanks to speed optimisation and hreflang tags.
3. Flexibility: Easy content management and dynamic page generation in three languages.

 

7. Benefits and challenges of the headless approach

While headless architecture offers many advantages, it also comes with certain challenges that may influence the decision to implement it. In this section, we will analyse the key benefits and potential difficulties associated with the headless approach in WordPress, particularly in combination with WooCommerce and Gatsby.

Benefits of Headless Architecture

1. Higher performance

• By generating static pages in Gatsby, website loading times are significantly reduced. Speed improves user experience (UX) and conversion rates in e-commerce.
• Example: A product page in WooCommerce can be generated statically, while the shopping cart and payments can be handled dynamically using an API.

2. Scalability

• Separating the backend (WordPress) and frontend (Gatsby) allows for easier scaling of both layers independently. The WordPress backend can handle millions of API requests, while the frontend is served as static files via CDN.

3. Technological flexibility

• Headless allows for full control over the appearance and functionality of the frontend. Thanks to the Gatsby framework, you can create modern user interfaces in React, with the ability to easily implement interactive features.

4. Improved SEO

• Static pages generated by Gatsby are optimised for SEO, allowing for better positioning in search results.
• Additional benefits include the ability to easily manage hreflang tags on multilingual websites and faster loading times, which are taken into account by search engine algorithms.

5. Hassle-free multilingual support

• WPML and Polylang, combined with GraphQL, allow for easy management of content in multiple languages while maintaining an optimised API structure for the frontend.

6. Security

• In the headless approach, the frontend and backend are separated from each other, which reduces the risk of attacks on the presentation layer, such as XSS attacks.

 

Challenges of headless architecture

1. Implementation costs

• The transition to Headless requires an investment of time and resources, especially for WooCommerce and multilingual configurations.
• The costs include:
  • Building and maintaining API infrastructure.
  • Creating a custom frontend.

2. Project complexity

• Headless architecture requires greater technical expertise, including knowledge of GraphQL, REST API, React, and Gatsby.
• Managing dynamic functionalities such as shopping carts and payments requires the use of solutions such as Netlify Functions or AWS Lambda.

3. WordPress plugin compatibility

• Not all plugins are compatible with WPGraphQL or REST API. For example, some WooCommerce plugins may need to be customised to work in a headless environment.

4. Support for dynamic functions

• Features such as shopping carts, payments, and user logins cannot be generated statically and must be handled dynamically.
• Solution: Dynamic API or serverless functions.

5. SEO management in multilingual websites

• Requires advanced configuration to correctly handle hreflang tags, dynamic XML sitemaps, and other SEO elements for different languages.

 

Practical comparison: Monolith vs Headless

Criterion	Monolithic WordPress	Headless WordPress
Performance	Dynamic page generation, slower with high traffic.	Static pages served from CDN.
Flexibility	Limited by themes and plugins.	Full control over the frontend.
Implementation costs	Lower	Higher – requires an experienced team.
Support for dynamic functions	Built-in	Requires API and dynamic solutions.
SEO	Good, but dependent on server speed.	Optimised for performance.

 

Summary: When is it worth choosing Headless?

Headless will be suitable for:

1. Large e-commerce stores that require high performance and scalability.
2. Projects where flexibility and frontend customisation are key.
3. Multilingual websites where optimised content management in multiple languages is important.
4. Organisations that have a technical team with the right skills.

Headless will not be optimal for:

1. Small projects with limited budgets.
2. Websites that do not require major frontend customisation.
3. Users with no experience in programming and API management.

 

8. Disadvantages and challenges of headless architecture

Headless architecture has gained popularity due to its flexibility, scalability, and performance, but like any technological solution, it also has its drawbacks. In this section, we will discuss in detail the challenges that may arise when implementing Headless WordPress and analyse when this approach may not be optimal.

 

1. Implementation and maintenance costs

Challenges:

• Higher initial costs: The transition from traditional architecture to Headless requires investment in:
  • A team of developers with experience in Gatsby, GraphQL, and APIs.
  • Infrastructure for managing dynamic features such as shopping carts and payments in e-commerce.
• Maintenance: Managing a separate frontend and backend requires maintaining two separate layers, which increases maintenance costs.

Example of costs in e-commerce:

• A small WooCommerce shop can spend around PLN 5,000–10,000 on implementing traditional WordPress.
• With Headless, these costs can rise to £4,500–£4,500 depending on the complexity of the project.

2. Technical complexity

Challenges:

• Technical skills required: Implementing Headless requires advanced programming knowledge, especially in the areas of GraphQL, React, and API integration.
• Greater configuration complexity: The need to adapt the WordPress backend to work as an API, configure Gatsby, and implement dynamic functions (e.g., shopping cart) increases the complexity of the project.

Solution:

• For smaller projects, consider simplifying the architecture by sticking with traditional WordPress.
• Invest in team training or collaborate with a company specialising in Headless.

3. Support for dynamic features

Challenges:

• Static page generation in Gatsby works great for informational pages, but dynamic features such as shopping carts, user logins, and payments require separate solutions.
• These functionalities must be supported by real-time APIs, which requires additional server resources or serverless functions.

Example solution:

• WooCommerce shopping cart:
  Use serverless functions (e.g. Netlify Functions) to handle dynamic product additions to the shopping cart:

export const addToCart = async (productId, quantity) => {

const response = await fetch(

“https://twojadomena.pl/wp-json/wc/v3/cart/add”,

{

method: “POST”,

headers: {

“Content-Type”: “application/json”,

},

body: JSON.stringify({ id: productId, quantity }),

});

 

return response.json();

};

 

4. WordPress plugin compatibility

Challenges:

• Not all WordPress plugins are compatible with WPGraphQL or REST API. For example, plugins that add custom functionality to WooCommerce may not work in Headless.
• Incompatibility may require custom API customisation or sacrificing some features.

Solution:

• Check which plugins have full support for WPGraphQL or REST API before implementation.
• Alternatively, consider building custom API solutions in the WordPress backend.

 

5. SEO challenges in multilingual websites

Challenges:

• Hreflang tags: For multilingual websites, it is necessary to implement hreflang tags correctly, which requires additional configuration in Gatsby.
• XML sitemaps: WordPress generates dynamic sitemaps by default, which requires additional work in Headless.

Example of hreflang implementation in Gatsby:

import React from “react”;

 

import { Helmet } from “react-helmet”;

 

const SEO = ({ lang, url }) => (

<Helmet>

<link rel=”alternate” hrefLang={lang} href={url} />

</Helmet>

);

export default SEO;

Solution:

• For WPML and Polylang, you can use their native functions to generate XML sitemaps and integrate with the API.

 

6. Longer implementation time

Challenges:

• Headless development requires more time for backend configuration, API integration, and frontend development in Gatsby.
• For complex projects (e.g., e-commerce shops), implementation time can be 30–50% longer compared to traditional WordPress.

Solution:

• Using an iterative approach (e.g., MVP – Minimum Viable Product) allows you to launch the basic version of the website earlier and gradually add features.

 

Summary: When is Headless a challenge?

1. Small and medium-sized websites: Headless implementation may not be cost-effective for smaller projects that do not require advanced personalisation or scalability.
2. Lack of technical resources: Organisations without the right technical team may encounter difficulties in implementing and maintaining such an architecture.
3. Large number of custom features: E-commerce shops that use many custom plugins may have trouble fully integrating into a Headless environment.

 

Is Headless for everyone?

Headless architecture is not a one-size-fits-all solution and requires a thorough analysis of project needs. Its implementation brings enormous benefits to large, dynamic websites, but it also involves higher costs and greater complexity. Before deciding to switch to Headless, it is worth assessing your budget, technical resources and business requirements.

 

9. Summary

The transition from monolithic WordPress architecture to a headless approach is a step that can significantly increase the performance and flexibility of websites, especially for e-commerce projects. In this article, we have presented a comprehensive migration process and discussed both the benefits and challenges of this approach.

 

The main benefits of Headless WordPress

1. Higher performance:
   • By using Gatsby as a framework for generating static pages, loading times are shorter, which improves user experience (UX) and SEO.
   • The CDN stores static pages, eliminating backend server overload.
2. Flexibility:
   • The ability to create modern, interactive interfaces in React opens up new possibilities in e-commerce website design.
   • Full control over the frontend, independence from the limitations of traditional WordPress themes.
3. Scalability:
   • Separating the backend from the frontend allows both layers to be scaled independently, which is particularly important for large websites with a high number of users.
4. SEO and optimisation:
   • Static pages are optimised for search engines, which results in higher rankings in search results.
   • Support for hreflang tags and dynamic XML sitemaps supports multilingual websites.
5. Multilingual support:
   • Thanks to the integration of WPML or Polylang with GraphQL, managing content in multiple languages is simple and effective.

Biggest challenges and limitations

1. Costs and complexity of implementation:
   • Headless requires a larger budget and a team with advanced technical knowledge. This approach is not optimal for small projects with limited budgets.
2. Plugin compatibility:
   • Not all WordPress plugins, especially those related to WooCommerce, are fully compatible with WPGraphQL or REST API, which may require additional programming work.
3. Support for dynamic features:
   • The shopping cart, payments, and user login must be handled using dynamic solutions such as Netlify Functions, which increases the complexity of the project.
4. SEO management:
   • Implementing hreflang tags, generating XML sitemaps, and managing multiple languages requires additional effort.

 

When to choose a headless architecture?

Headless WordPress is ideal for:

• Large e-commerce shops: Which require high performance and the ability to handle high traffic.
• Global websites: With multi-language support and advanced SEO requirements.
• Projects with custom front-end: Where flexibility in design and interface construction is key.

When to stick with traditional WordPress?

• Small projects: Websites with limited budgets and technical requirements.
• Lack of technical resources: Organisations without access to a technical team with experience in Headless.

 

Practical recommendations

1. Start by analysing your project’s needs:
   • Assess whether your website requires the scalability, flexibility, and performance that Headless offers.
2. Choose the right tools:
   • Gatsby: For websites where speed and SEO are a priority.
   • WPGraphQL: For projects that require advanced control over data structure.
   • WPML or Polylang: For multilingual websites.
3. Plan iterative implementation:
   • Instead of implementing full headless right away, start with a Minimum Viable Product (MVP) and gradually develop the website.
4. Ensure security:
   • Restrict access to the API with keys and authorisation.
   • Regularly monitor the backend and frontend for potential threats.

 

Final summary

Headless architecture is the future of WordPress, offering unprecedented flexibility and performance. While it is not a solution for every project, for large e-commerce sites and global multilingual services, it can be the key to success. Needs analysis, appropriate tool selection, and iterative implementation will minimise risk and maximise benefits.

 

10. Add-ons

 

1. Frameworks and plugins

• Gatsby
  A React-based framework for generating static pages.
  • Documentation: gatsbyjs.com
• WPGraphQL
  A plugin that enables the use of GraphQL in WordPress.
  • Documentation: wpgraphql.com
• WPGraphQL for WooCommerce
  A WPGraphQL extension that allows access to WooCommerce data.
  • Documentation: WPGraphQL for WooCommerce
• WPML and Polylang
  Plugins supporting multilingualism in WordPress.
  • WPML: wpml.org
  • Polylang: polylang.pro

2. Tools supporting development

• Postman
  A tool for testing APIs (REST and GraphQL).
  • postman.com
• GraphiQL
  Interactive GraphQL query explorer.
  • graphiql-online.com

 

Links to documentation and resources

1. Gatsby
   • Official documentation: Gatsby Docs
   • WordPress integration guide: Gatsby + WordPress
2. WPGraphQL
   • Configuration basics: WPGraphQL Docs
   • GraphQL query examples: GraphQL Examples
3. WooCommerce REST API
   • Documentation: WooCommerce REST API
   • Code examples: REST API Examples
4. WPML and Polylang
   • WPML: WPML Documentation
   • Polylang: Polylang Documentation

 

Example of a complete project configuration

To summarise the previous steps, here is a diagram of the full configuration of a Headless WordPress project with Gatsby:

1. WordPress backend:
   • Install WordPress, WooCommerce, WPGraphQL, and multilingual plugins (WPML/Polylang).
   • Configure the GraphQL or REST API.
2. Gatsby frontend:
   • Install gatsby-source-wordpress and gatsby-plugin-react-i18next.
   • Configure gatsby-config.js to connect the API to WordPress.
   • Build dynamic product pages and language support.
3. SEO and optimisation:
   • Enable hreflang tags on multilingual websites.
   • Integrate dynamic XML sitemaps (e.g. via WPML or Yoast SEO).

 

Why implement Headless WordPress?

Headless architecture offers unlimited possibilities for personalisation and improving website performance. For large e-commerce projects, as well as global multilingual websites, this approach is the future. However, implementation requires proper planning, technical resources and tools to maximise benefits and minimise risks.