Content and commerce: running a fast blog next to your store
How a static content site and a Shopify store share a domain, a design and a product feed, and why the split makes both faster.
The short answer
A store and a content site do different jobs and are built differently. The store handles products, cart and checkout and is optimised for transactions. The content site handles articles, buying guides and topic hubs and is optimised for reading, structure and search. Running them as two systems on one domain, sharing design tokens, navigation and a product feed, makes both better: the content site is a fast static build with proper structure, the store carries no content weight, and articles still sell because they render live product cards from the store’s API. The store keeps its theme; only content moves. It is the lightest version of the split and often the first step towards a headless storefront.
How the pieces fit
| Piece | System | Notes |
|---|---|---|
| Products, collections, cart, checkout | Store | Theme or headless; unchanged by the split |
| Articles, guides, hubs, glossary | Static content site | Content collections; fast; structured data |
| Domain | Shared | Content at a path or subdomain; routed by DNS and the network layer |
| Design | Shared tokens and mirrored components | One brand across both |
| Navigation and footer | Mirrored | Visitors move between systems without a seam |
| Product data in articles | Store’s API | Live cards with price and availability; link to product or add-to-cart |
| Search equity | Consolidated | Same domain; redirects from any old blog addresses |
| Analytics | Shared configuration | One view of the journey from article to order |
Setting it up
- Decide the address: a path on the main domain where routing allows it, otherwise a subdomain.
- Build the content site on a static stack with content collections, mirroring the store’s tokens, navigation and footer.
- Connect the storefront API with a public token scoped to reading products and collections.
- Build the product card component and a way for authors to place products in articles by handle.
- Route the domain: DNS and network layer send content paths to the static host and everything else to the store.
- Migrate any existing blog with redirects and retire the theme blog.
- Link both ways and measure organic traffic and assisted revenue from content.
Why both get faster
The theme blog adds content pages that carry the store’s full script and app weight; removing it lightens the store and removes a set of pages that scored badly. The content site is static, cached at the edge, and ships almost no JavaScript, so articles load in a fraction of the time and rank on structure and speed. Each system does one job with the tools built for it, which is why the split is a speed improvement for both rather than a compromise.
What this means for you
Keep the store for transactions and give content a fast static home on the same domain, sharing design and a live product feed. Articles sell through product cards; the store sheds its content weight; search equity stays together. It is the lightest way to run content and commerce as one site, and it lays the foundations for a headless storefront if the store ever outgrows its theme.
Frequently asked questions
How do the two systems share one domain?
The content site is served at a path or a subdomain of the store's domain, with DNS and a network layer routing requests to the right system. Navigation, footer and design tokens are mirrored so visitors move between articles and products without noticing a boundary. Same domain is what keeps search authority consolidated.
How do articles show products?
The content site reads product data from the store's storefront API at build time or on request: name, image, price, availability. A product card component renders it in the article with a link to the product page or straight to add-to-cart. When the price changes in the store, the card follows; the article never holds a stale price.
Does this need a headless storefront?
No. The store can keep its theme for products and checkout; only the content moves to the static site. It is the lightest version of the content-and-commerce split, and it is often the first step towards a fully headless storefront later, because the design system and the API connection already exist.
Sources
- Shopify developer documentation: Storefront API (accessed 2026-09-12)