Running a WordPress Blog Inside Magento 2 on One Domain

You can serve a WordPress blog at yourstore.com/blog with Magento 2 running the rest of the site, and there are three ways to do it: host WordPress on a subdomain, reverse-proxy a subdirectory to a separate WordPress install, or render WordPress content inside the Magento storefront itself. That third approach is what our OrangeCollar WordPress Integration module does; it fetches posts over the WordPress REST API and serves them through your Magento theme, with no shared database between the two systems. We build the module, so read the comparison knowing that.

This post is about combining the two platforms. If you are earlier in the decision and still choosing between them, start with Magento vs WordPress.

Why put the blog on the same domain as the store?

Google's public position is that subdomains and subdirectories are both fine, and plenty of SEOs have watched rankings move anyway when a blog migrated from blog.example.com to example.com/blog. We are not going to settle that argument here. The case for one domain stands on things that are not debated:

• Internal links stay internal. A buying guide that links to three product pages, and a product page that links back to the guide, all within one host. Your content and your catalog reinforce each other inside a single site structure.
• One brand shell. Same header, same navigation, same mini-cart. A reader who arrives on a blog post is already inside the store, not one click and a visual context switch away from it.
• One session. On a subdomain setup, the cart and login state do not naturally follow the shopper between blog and store. On one domain they just work.
• One analytics property, one Search Console view, and no cross-domain measurement gymnastics.

Merchants rarely regret consolidating onto one domain. The engineering question is how to get there without gluing two PHP applications together badly.

What are the three ways to combine WordPress and Magento 2?

Option 1: WordPress on a subdomain. Spin up WordPress at blog.yourstore.com and link to it from the store nav. This is the easiest to operate, and it is the right call when the blog team wants full WordPress theming freedom and nobody is optimizing for the same-domain benefits above. The costs: two themes to keep visually aligned by hand, no shared session, and you are on the subdomain side of the SEO debate.

Option 2: reverse proxy a subdirectory. Nginx (or Varnish, or your CDN) routes /blog/* to a separate WordPress origin while Magento serves everything else. Same domain achieved. But now the seams are your problem: WordPress generates absolute URLs that must match the proxied path, cookies from two applications share a domain and must not fight, caches layer across both, and the blog still renders WordPress's theme, so the "one brand shell" benefit means rebuilding your storefront design a second time in WordPress and maintaining the twins forever. Doable, and we have done it, but it is permanent operational overhead disguised as a config file.

Option 3: render WordPress content in the Magento storefront. WordPress keeps the job it is best at, being the editorial backend your content team already knows, and Magento serves the blog pages inside its own theme. One domain, one design, one session, no proxy seams. This is the architecture our module implements, so the rest of this post describes that approach concretely.

How does the integration module approach work?

The OrangeCollar WordPress Integration module has two halves:

1. A Magento module that registers a router for your blog path (default /blog, configurable to news, articles, whatever fits), fetches content from WordPress over the REST API, caches it in Magento's cache backend, and renders it through Magento layout and templates.
2. A WordPress plugin (oc-magento-bridge) that adds authenticated REST endpoints for the data core WordPress does not expose cleanly, and pings Magento with a cache-purge webhook whenever content changes.

There is no shared database and no PHP-level embedding. WordPress can live on any host, including one that is not publicly advertised; Magento is the only thing your visitors talk to.

What renders on the storefront: the post listing with pagination, single posts with featured image, author, categories and tags, category, tag and author archives, search results, and optionally WordPress navigation menus. Because output goes through Magento templates, blog pages wear your storefront theme automatically, and there is a companion package for Hyva stores that swaps in Tailwind and Alpine.js templates.

Two details matter for production use:

Caching is event-driven, not hope-driven. API responses are cached (30 minutes for posts, 24 hours for categories and tags by default), and when an editor updates a post, the WordPress plugin fires a webhook that Magento verifies with an HMAC-SHA256 signature and then purges just the affected cache entries. Editors see their changes live without anyone flushing caches, and WordPress being briefly unreachable does not take your blog down, since Magento keeps serving from cache.

SEO metadata carries over. With the SEO setting enabled, the module pulls meta title, description, robots directives, Open Graph and Twitter Card tags, and JSON-LD Article schema from Yoast SEO or RankMath (falling back to WordPress core fields) and applies them to the Magento-rendered page. Your content team keeps optimizing in the WordPress tools they know, and the output lands on the storefront URLs that actually rank.

How do you set it up?

The short version, from the docs:

composer require orangecollar/module-wordpress-integration
bin/magento module:enable OrangeCollar_WordPressIntegration
bin/magento setup:upgrade
bin/magento cache:flush

Then:

1. Install and activate the oc-magento-bridge plugin on the WordPress side, and copy the API key it generates under Settings > OC Magento Bridge.
2. In the Magento admin, go to Stores > Configuration > Orange Collar > WordPress Integration, enter the WordPress URL and the API key, and click Test Connection. The key travels as a request header on every call and is stored encrypted in Magento. Connection setup covers the failure cases; the usual one is that WordPress must be reachable from the Magento server, not just from your browser.
3. Save, flush the cache, and visit yourstore.com/blog. Your WordPress posts render in your Magento theme.

Requirements: Magento 2.4.8 or higher, PHP 8.1 or higher, WordPress 6.0 or higher. Connection settings are store-view scoped, so a multi-store setup can point a French store view at a French WordPress site and an English one at another.

What are the tradeoffs?

Being the vendor does not make these disappear:

• You still run WordPress. Hosting, updates, plugin hygiene, all of it. The module moves rendering, not maintenance. The consolation is that WordPress no longer needs to be public-facing or themed.
• Magento templates control the markup. Your blog inherits the storefront design, which is the point, but it also means heavy WordPress page-builder layouts will not carry their front-end over. This approach fits content-shaped blogs: posts, categories, authors.
• Freshness depends on the webhook loop. The cache-purge webhook keeps content current; if the bridge plugin is misconfigured, edits wait out the cache lifetime before appearing.

If the blog team demands full WordPress theming autonomy, take the subdomain and its tradeoffs with open eyes. If you want the store and the content operation to read as one site on one domain, rendering WordPress content inside Magento is the cleanest architecture we know, and we know it well enough to have built it. The full documentation, including developer references for routing, caching, and the bridge plugin's endpoints, is on the module docs site, and the rest of our catalog is on the Magento extensions page.