Rebuilding the SlimFast Content Engine: +47% Organic Sessions, 2.1× Content-to-Shop Clicks

Content brands run into a strange problem: they have published so much over the years that the most useful pages get buried, while the homepage tries to be everything to everyone. SlimFast had a version of that, plus four others.

1. Stale content architecture. Years of recipes, plan content, product info and blog posts sat in one flat structure. The pages that mattered most — the SlimFast Plan, How It Works — were competing for attention with old promotional content that should have been retired years earlier.
2. Slow on mobile. Heavy hero modules, third-party scripts and unoptimised images pushed Core Web Vitals into the red on every key landing page. On a site whose job is to capture search traffic, that is a compounding problem: slow pages rank worse, and worse rankings mean the slow pages get less traffic to justify fixing.
3. A disconnect between content and shop. Recipes and plan pages carried vague "shop" buttons that dumped users on the Shopify homepage rather than the relevant product. A reader who has just decided they want the specific shake in the recipe they are reading should not have to go find it.
4. Search performance had drifted. High-volume terms — meal replacement shake, how to use SlimFast, SlimFast keto — were ranking below where a brand of this size should sit.
5. Editorial workflow was clunky. Marketing wanted to publish recipes, success stories and plan updates without filing an engineering ticket every time. A publishing team that has to queue for developer time publishes less, and a content site that publishes less decays.

• We started with an audit, not a design. Ten years of pages scored on traffic, conversions to shop, and topical relevance. Roughly 30% of URLs were doing 80% of the work — those got upgraded. Another 30% were merged or redirected. The rest were left alone with a follow-up cleanup planned. This is the unglamorous half of the project and it determines whether everything after it works.
• A Gutenberg-first theme rebuild. The site was already on WordPress, which made the rebuild considerably more straightforward. We hand-built a custom theme on native Gutenberg blocks and wrote about a dozen brand-specific ones — recipe cards, plan-step blocks, before/after stories, FAQ blocks, and product cards pulling live from the Shopify catalog API — then locked them down so layouts stay consistent no matter who is composing a page. This is where CMS development earns its keep: the marketing team composes new pages without engineering involvement, and the design system holds anyway.
• Performance, treated as a feature. Heavy hero videos were replaced with poster-image-first patterns and click-to-play. Third-party scripts moved to deferred loading. Images were reprocessed into WebP and AVIF through an automated pipeline. Core Web Vitals moved from Poor to Good on the most-trafficked pages within a single release cycle. Standard web development discipline, applied ruthlessly rather than partially.
• Hub-and-spoke SEO for the plan content. A definitive SlimFast Plan pillar page, with topic spokes for keto, high-protein and intermittent fasting variations, plus a separate spoke set for "how to use" content. Internal linking was rewritten by hand across the top 200 pages — not generated, not plugin-automated, written. That is slow work and it is the reason the plan queries recovered.
• A live bridge between WordPress and Shopify. We built a lightweight integration pulling product data from the Shopify Storefront API into WordPress, so an author drops a product card by SKU and price, image and stock state stay in sync automatically. The CTA links straight to that product's PDP with UTM parameters attached. Content teams stop maintaining stale product references by hand, and marketing gets clean attribution. Connecting a content platform to a commerce platform without merging them is a recurring problem in enterprise ecommerce, and the answer is almost always a thin, well-defined bridge rather than a migration.
• Attribution that survives contact with a finance team. Every shop CTA carries UTM parameters and an ID, with Segment and GA4 running server-side and client-side. Content-driven revenue becomes measurable instead of assumed — the difference between a content site being treated as a cost centre and being funded properly. Getting the analytics and reporting layer right at rebuild time is far cheaper than retrofitting it after someone asks what the content is actually worth.
• Editorial workflow inside WP admin: roles, drafts, scheduled publishing and an approval flow, so the marketing team ships without a ticket queue.
• Process and data handling. The release gates, code review and defect handling on this build follow the documented process set by our ISO 9001:2015 quality management certification, and the analytics and visitor-data work sat inside our ISO 27001:2022 information security controls covering access management, encryption and vendor review. Both are independently audited rather than self-declared. On a marketing site the security surface is smaller than on a payments platform — but attribution data is still visitor data, and it deserves the same handling.

• Measured over the first six months post-launch.
• +47% organic sessions. Driven by recovery on plan-related queries and the new recipe schema. This is the headline number and it is the one to lead with.
• +2.1× content-to-shop click rate. Visitors moving from a content page to a specific product PDP rather than the shop homepage. This is the metric the whole rebuild was aimed at — the others support it.
• +60% recipe page traffic. Schema implementation surfaced recipes in Google's rich-result carousel, which is a step change in visibility rather than an incremental ranking gain.
• −33% bounce rate on plan pages. Cleaner information architecture and hand-written internal linking kept readers moving through the site instead of leaving from the entry page.
• Core Web Vitals: Good across all major templates, on both mobile and desktop, up from Poor at the start.
• ~12 custom Gutenberg blocks shipped and locked down, giving the marketing team a composable page system that cannot drift off-brand.
• Top 200 pages re-linked by hand, with roughly 30% of the URL inventory upgraded and another 30% merged or redirected.
• Publishing independence. Recipes, stories and plan updates now ship without engineering involvement — which is the result that keeps paying after the engagement ends.

Ten years of pages, scored on traffic, conversions and topical relevance. Roughly 30% of URLs were doing 80% of the work; another 30% were merged or redirected. Nobody wants to pay for this phase and it is the phase that determines whether the rebuild works. Redesigning on top of an unaudited content estate means carrying every legacy problem into a new theme and being surprised when rankings do not move. If you are staring down a similar overhaul, hire WordPress developers who will do the boring audit work first — that is where the value lives.

SlimFast's content runs on WordPress and its shop runs on Shopify, and the right answer was to keep it that way. We built a thin bridge over the Shopify Storefront API so authors drop a product card by SKU and price, image and stock stay in sync, with the CTA deep-linking to the specific PDP plus UTM parameters. No migration, no duplicated catalog, no stale product data maintained by hand. Teams facing this usually assume they need to consolidate platforms; far more often they need a well-defined integration, which is cheaper, faster and reversible. It typically needs Shopify developers and PHP developers working on the same team rather than across a vendor boundary — the failure mode on these projects is almost always the handoff, not the code.

Poor CWV on a content site is a compounding problem: slow pages rank worse, worse rankings starve those pages of the traffic that would justify fixing them. We attacked it as part of the SEO workstream rather than a separate performance ticket — poster-image-first heroes with click-to-play, deferred third-party scripts, an automated WebP and AVIF pipeline, and prioritised LCP elements. All major templates moved from Poor to Good within one release cycle. The same software development services discipline applies whether the target is a page-speed budget or an API latency budget: measure, fix the largest contributor, re-measure.

Emizentech holds ISO 27001:2022 for information security — access control, encryption, vendor review and incident response — and ISO 9001:2015 for quality management, covering release gates, code review and defect handling across every engagement. Both are independently audited rather than self-declared. On a content and marketing build the security surface is narrower than on a payments platform, and it is worth being precise about that: what mattered here was disciplined handling of analytics, attribution and visitor data across Segment and GA4, plus a documented release process on a site where a bad deploy is visible to the brand's entire audience. Ask any prospective partner for the certificate rather than the claim.