THE solution for integrating WordPress on Shopify

Updated on 29 October 2024

Would you like to enjoy all the advantages of Shopify for your business while having a robust editorial section on WordPress? All on the same domain? with the blog as a subdirectory? without a complex synchronisation system?
👉 Then you’ve come to the right place.

The solution I’m going to tell you about is perfectly functional, in production for over 2 years, with 0 additional maintenance time (on the infrastructure side) and validated with Shopify support.

If your Shopify e-commerce site is on the https://exemple.com domain, you can have your WordPress blog on https://exemple.com/blog (or any other blog name).

🚩 The solution requires some technical devops knowledge, but you don’t need to be an expert in Shopify or WordPress. There is more configuration to read and understand than to actually set up, because once the system is configured, everything is relatively straightforward.

When to use WordPress and Shopify together

A great deal of research and experimentation went into arriving at the solution I describe below. Even if it is perfectly viable and functional, it requires a good understanding of a few proxy / routing / DNS concepts to be implemented with peace of mind.

💭 Before you set about configuring it, ask yourself whether there is any real point in having both WordPress and Shopify, or whether one or other of these solutions can meet your needs. You’ll need to manage 2 themes (the Shopify theme and the WordPress theme) and have consistent navigation between the two, and of course maintain your WordPress installation.

For my part, I decided on this solution in response to a client situation where there was a real interest in migrating to Shopify for business and marketing reasons (which paid off) and also in keeping WordPress for the blog part in order to retain the SEO legacy of content/meshing/structure that had been worked on for several years (again, this paid off).

Steps for integrating WordPress into Shopify

Shopify + Cloudflare + WordPress, a quick explanation for the less tech-savvy

Shopify uses Cloudflare as a proxy to manage a large part of its optimisations. In simple terms, it’s an intermediary between the visitor and Shopify, which carries out optimisations on the fly.
So we’re going to use Cloudflare to send the blog’s requests, i.e. every URL containing https://exemple.com/blog, to our own WordPress server.

This will allow a completely transparent installation for the user, while having a real Shopify and a real WordPress, without having to manage synchronisations via modules or alter one or the other.

The rest of the article is more technical, but less tech-savvy readers will be able to grasp the concepts and get an idea of the solution and what it requires.

Configuring Cloudflare on your Shopify domain

Shopify uses Cloudflare to manage many of its optimisations as a proxy. And for just over 2 years it has been possible to use Cloudflare’s O2O mode, which allows you to combine both Shopify’s configuration, which uses it for its platform, and your own, which you can set up for your domain.

O2O mode is normally active by default, but you can request support to activate it.

The first step is to set up Cloudflare in the usual way on your domain where Shopify is installed. To do this, you’ll need to tell your registrar (where you buy your domain) that the DNS are managed by Cloudflare. Cloudflare will then retrieve the existing configuration and point the site to the Shopify platform.

🚩 If you are not comfortable with this first stage, I recommend that you hire a service provider with devops-oriented skills, bearing in mind that the following stages are more complex.

Installing WordPress in a subdirectory

The second step is to configure WordPress and make it accessible from 2 addresses: Both from blog.example.com and from example.com/blog.

To do this you will need to point (DNS level) blog.example.com to your server where WordPress is installed. Then create the /var/www/blog directory on your server, this is where WordPress will be installed.
Finally, you’ll need to configure the vhost so that the addresses blog.example.com and example.com point to the physical /var/www folder on your server.

For blog.example.com DNS level on Cloudflare, it should be set to DNS only (this will detect direct access or access via the worker).

Here’s a quick explanation: Even if example.com doesn’t point to your server at DNS level, it will be useful for us later, because example.com/blog will point to the WordPress server thanks to the Cloudflare proxy, and via this vhost, the mapping to /var/www/blog will be done correctly.

Lastly, to prevent WordPress from being accessible from 2 urls (and therefore risking duplicate content), you can add these instructions to the .htaccess file :

RewriteEngine On
RewriteCond %{HTTP:CF-Connecting-IP} ^$
RewriteRule ^(.*)$ https://exemple.com/$1 [L,R=301]

We will also add in the wp-config.php file in the edit zone :

define('ADMIN_SITEURL', 'https://exemple.com/blog/');
$_SERVER['HTTP_HOST'] = 'exemple.com';

This will allow you to force the domain so that WordPress considers that it is on example.com/blog and not blog.example.com/blog.

🚩 Note for later: once the worker configuration is in place, you will need to return to WordPress to replace the urls in the Settings/General section with the value https://exemple.com/blog.

Configuring the worker on Cloudflare

From there, you can set up a Cloudflare worker, a small application that acts as an intermediary and in which you can do many things, such as route the request to another server.

To use workers, you'll need to subscribe to a package based on your volume of requests (which depends on traffic, content and site optimization).

The free offer includes 100,000 requests per day, and the $5/month offer includes 10M requests per month, then $0.30 per million additional requests. As an example, the $5 offer is more than sufficient for over 500K page views per month on an optimized site.

To do this, go to the Workers and pages section of your domain’s Cloudflare configuration. Create a new empty worker, and add the following code:

addEventListener('fetch', function (event) {
  event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
  // Récupérer l'URL originale
  let originalURL = new URL(request.url)
  // Définir la nouvelle URL
    const { pathname,search } = new URL(request.url)

  let newURL = new URL(`https://blog.exemple.com${pathname}${search}`)
  // Copier les paramètres de l'URL originale vers la nouvelle URL
  newURL.search = originalURL.search
  let newHeaders = request.headers
  let newRequest = request.clone()
  newRequest.url = newURL
  // Renvoyer la réponse de la nouvelle requête
  return await fetch(newURL, newRequest)
}

function MethodNotAllowed(request) {
  return new Response(`Method ${request.method} not allowed.`, {
    status: 405,
    headers: {
      Allow: 'GET',
    },
  });
}

This code will enable you to intercept requests from Shopify to the blog directory and route them transparently to your WordPress installation.

➡️ Now you can save your worker, and go to Settings / Domains and routes to associate your worker with the zone that corresponds to your domain configured on Cloudflare, i.e. “example.com”, and the desired route, “example.com/blog*”, so that it only applies when you call example.com/blog.

You can deploy it for testing.

Optimize blog caching (optional)

In theory, if your editorial zone is essentially static, you can set up a strong caching system on Cloudflare to limit the number of times the worker will have to intervene, which drastically reduces the cost and beyond that gives you very good performance.

To do this, we’re going to create some cache rules, so go to “Cache rules”, then create a new rule in which you can define the following expression:

(http.request.uri.path contains "/blog" and not http.request.uri.path contains "wp-admin" and not http.request.uri.path contains "wp-login" and not http.request.uri.path contains "wp-cron" and not http.request.full_uri contains "preview" and not http.request.full_uri contains "ajax" and not ends_with(http.request.full_uri, ".xml") and not http.request.full_uri contains "wp-json")

Then set the following parameters:

• Cache eligibility: check cache eligibility
• TTL Edge: depending on your configuration, either set to “Use the cache control header if present; otherwise, cache the request with Cloudflare’s default TTL for response state.” if you manage your headers well, otherwise “Ignore the cache control header and use this TTL timeout.” and set a caching duration. The longer this time, the longer Cloudflare will keep the request (page, image, script…) in memory. However, you can clear the cloudflare cache at any time, either specifically or globally.
• Browser TTL: this is the caching time on the user’s browser, the same as the previous parameter, but if you set the time, choose a time that’s appropriate for the resources, as you won’t be able to empty the cache on the user’s computer (1 day, for example).

You can repeat the operation by creating a second rule with this expression:

(http.request.full_uri contains "wp-content/uploads") or (http.request.full_uri eq "wp-content/themes/nomdutheme")

This will allow you to specifically target resources such as scripts, images and other media in the theme and uploads folder with their own caching rules as seen above. Nothing prevents you from making a finer segmentation to dissociate images from the rest, for example…

Are you still here? Well done 😀

It may seem stodgy at first, but in reality, once set up, it’s easy to understand and maintenance-free. Shopify remains unchanged and WordPress, despite a few routing tricks, remains in a classic installation, making it fully functional and compatible with all plugins and other usual functionalities.

So you can keep the best of both worlds if it suits your needs.

In a future article, I’ll give you some examples of how to integrate Shopify products into WordPress using the API. Don’t hesitate to subscribe on Linkedin to follow the topic.

Would you like to discuss the subject?