Embedding a WordPress blog inside Shopify: 3 approaches I've actually shipped

If you've worked on a Shopify storefront for any merchant who takes content seriously, you've hit this wall. The merchant runs a WordPress blog (because Yoast, Rank Math, ACF, and the editor experience are still better than Shopify Blogs in 2026), but the marketing team wants the posts to render inside the storefront, on store.com/blog, in the same theme, with the same nav, the same footer, the same cart drawer.

The naive options all break something. Migrate everything to Shopify and you lose the WP plugin ecosystem and bleed redirect equity for months. Drop an <iframe> and Google won't index it, the layout breaks on mobile, and your Core Web Vitals tank. Copy-paste posts manually and you're maintaining two CMSs by hand.

I've shipped all three of the patterns below for client stores and for my own apps. Here's what each one actually involves, what breaks, and when to pick which.

Approach 1: Migrate WordPress content to Shopify Blogs

The "just consolidate" play. You export WP posts, import them as Shopify articles, set up 1:1 redirects, and decommission WP.

What it actually involves:

1. Export WP posts via WP REST API or WXR. The Shopify Articles API accepts HTML body, author, tags, image, published_at, so you can script the import in a few hundred lines of Node.
2. Build a redirect map. Every wordpress.example.com/2024/03/slug/ or example.com/blog/slug/ needs a 301 to example.com/blogs/news/slug. Shopify's Redirects API caps at 100k entries which is fine for most blogs, but you'll batch in 250s.
3. Resubmit the new sitemap to Search Console and request indexing on the top 50 URLs.
4. Rewrite internal anchors. Old posts linked to other old posts; if you don't rewrite those anchors during import, every internal link is now a 301 hop.

// redirect map sample (Node, Shopify Admin GraphQL)
const redirects = wpPosts.map(p => ({
  path: new URL(p.link).pathname,           // /2024/03/some-slug/
  target: `/blogs/news/${p.slug}`,
}));

for (const batch of chunk(redirects, 250)) {
  await admin.graphql(URL_REDIRECT_BULK_CREATE, { input: batch });
}

Pros: one CMS, one domain, no third-party dependency, no proxy to maintain. Editors stop asking "which login do I use again?"

Cons: you lose the WP plugin ecosystem (Yoast schema, ACF flexible content, custom post types). The Shopify article editor is genuinely worse for long-form. Redirect chains accumulate if the blog has ever moved before. Duplicate-content risk lingers for weeks while Google reconciles the old WP URLs that are still cached.

Pick this when: the blog is small (under ~200 posts), the team is already tired of maintaining WP, and the content is mostly product-adjacent (buying guides, how-tos) rather than long-form journalism that depends on WP-specific plugins.

Approach 2: Reverse proxy WordPress at /blog

Keep WP exactly where it is. Serve it under the Shopify domain via a reverse proxy so store.com/blog/* is actually WordPress, while everything else is Shopify.

The cleanest way I've shipped this is a Cloudflare Worker sitting in front of the apex domain.

// Cloudflare Worker: route /blog/* to WP, everything else to Shopify
export default {
  async fetch(request) {
    const url = new URL(request.url);

    if (url.pathname.startsWith('/blog')) {
      const wpUrl = new URL(url.pathname + url.search, 'https://wp-origin.example.com');
      const wpRes = await fetch(wpUrl, {
        method: request.method,
        headers: request.headers,
        body: request.body,
      });
      // rewrite absolute WP origin URLs in the response body
      const html = await wpRes.text();
      const rewritten = html.replaceAll('https://wp-origin.example.com', 'https://store.example.com');
      return new Response(rewritten, {
        status: wpRes.status,
        headers: wpRes.headers,
      });
    }

    return fetch(`https://store.example.com${url.pathname}${url.search}`, request);
  },
};

Pros: the cleanest SEO story by far. Canonicals stay on WP, all the schema and meta tags Yoast generates are preserved, no migration, no duplicate content. From Google's perspective store.com/blog/post-slug is one URL with one canonical. Nothing has moved.

Cons: two systems to keep alive forever. You need to match the WP theme's header/footer to the Shopify theme manually (or pull the Shopify header HTML into a WP template). The Worker is a paid hop on every blog request. Some Shopify Plus reverse-proxy patterns exist as alternatives but they're locked behind the Plus plan. You'll also debug "why is this asset 404ing" more than you'd like.

Pick this when: organic traffic to the blog dwarfs everything else and migrating risks real revenue. Big content sites with hundreds of ranking posts. Or when the editorial team is non-negotiable about WordPress.

Approach 3: Embed posts via the WP REST API (the WP Feed pattern)

Don't migrate, don't proxy. Just fetch posts from wp.example.com/wp-json/wp/v2/posts and render them inside Shopify Liquid sections. Both CMSs stay independent. The Shopify storefront pulls a feed when needed.

Here's the DIY path. A Liquid section that fetches on the client and renders into the page:

{% comment %} sections/wp-feed.liquid {% endcomment %}
<div id="wp-feed" data-wp-endpoint="https://wp.example.com/wp-json/wp/v2/posts?_embed&per_page=6">
  <h2>{{ section.settings.heading }}</h2>
  <ul class="wp-feed__list"></ul>
</div>

<script>
  (async () => {
    const root = document.getElementById('wp-feed');
    const res = await fetch(root.dataset.wpEndpoint);
    const posts = await res.json();
    const list = root.querySelector('.wp-feed__list');
    list.innerHTML = posts.map(p => `
      <li>
        <a href="${p.link}">
          <img src="${p._embedded?.['wp:featuredmedia']?.[0]?.source_url ?? ''}" alt="" loading="lazy">
          <h3>${p.title.rendered}</h3>
          <p>${p.excerpt.rendered}</p>
        </a>
      </li>
    `).join('');
  })();
</script>

That works. Six posts render. You can ship it in an afternoon.

What it doesn't give you: caching (every storefront visitor hits your WP origin, which will fall over on a sale day), JSON-LD BlogPosting schema for the embedded posts, tag/category filtering, fallback for when WP is down, or a way to render posts on a static-rendered page that gets indexed properly. Each of those is a half-day of work and a thing to maintain.

I made WP Feed (a Shopify app for this exact pattern), so I'm biased. Sharing the technical reasoning anyway because the architecture works whether you use my app or build your own. The productized version handles the caching layer, emits JSON-LD per post, supports filtering by tag or category or slug, and degrades gracefully when WP is down. The DIY snippet above is fine for a single section on a single page; once you want it across a storefront with proper SEO you start rebuilding what's already there.

One thing worth getting right either way: if you embed WP post content (not just titles and excerpts) inline on a Shopify URL, set <link rel="canonical"> on the rendering page back to the WP post. Otherwise you're competing with yourself in search.

Pros: zero migration, fast to ship, both CMSs stay independent, no proxy infrastructure, editors keep using WP normally.

Cons: dependency on WP origin uptime (cache aggressively), canonical setup matters or you'll cannibalize your own rankings, third-party app if you go productized.

Pick this when: you want a few recent posts on the homepage, a blog landing section, or a "related reads" block on product pages, but you're not trying to make store.com/blog itself become WordPress.

Decision matrix

If the blog is the SEO engine, don't move it. If the blog is a content surface that supports the store, embed it. Migration is the right answer less often than people assume, but when it's right it's very right.

What's not in scope

Full headless setups (Hydrogen, Next.js Commerce) where Shopify is the data source and a JS framework is the renderer are a different conversation. So is using a third-party CMS like Contentful or Sanity as the source of truth and dual-publishing to both Shopify and WP. Both are valid, both are bigger commitments than what's above.

Questions on any of the three patterns, or edge cases I missed, drop them in the comments.

Peter Hållander makes Shopify apps at Stackedboost. WP Feed, Better Related Blog Posts, Eye Catching, Prefetch.