That's global mutable state, shipped to production as a content system.

Disclosure... I run a small studio, Everther Studio, and the client projects below are ours. The pattern shows up well beyond Kajabi, so here's where a clean build still leaks revenue, with numbers.

The shared-template problem

The client, a UK choir mentorship platform, had built their first paywalled newsletter in Kajabi's default newsletter area. Every design change overrode every issue. Issue 4 couldn't look different from Issue 3 without touching Issue 3.

We rebuilt it across three Kajabi systems. A landing page per issue, each with its own unguessable URL and SEO disabled. A course product as the members-only archive. A membership offer handling £12/month billing with two free issues. Drip runs off enrolment date, so every subscriber gets Issue 1 on day 0, Issue 2 on day 30, Issue 3 on day 60, whenever they joined.

Each issue became an independent unit, which it should have been from the start. Shared state works until the first time 2 things need to differ.

Lab scores don't pay anyone

Lighthouse runs on your machine, your network, your warm cache. Your customers are on a mid-range phone and mobile data. Google's "good" thresholds are LCP under 2.5s, INP under 200ms and CLS under 0.1, and the number that matters is the one real users hit.

Renault did this properly. They used the web-vitals library to send real-user metrics into Google Analytics, then analysed 10 million landing page visits. A one-second LCP improvement tracked with 13% more conversions and a 14-point lower bounce rate. Rakuten 24 went further with an A/B test: same visuals, same functionality, Core Web Vitals work only. Conversion rate rose 33.13% and revenue per visitor 53.37%.

Both are large retailers, so don't copy the numbers. Copy the method-

Then segment by page template and device. Say a product page sits at a 4s LCP and a blog post at 1.2s. Those need different fixes, and a single site-wide score hides it.

Instrument the funnel, not the page

A page score can't tell you where people leave. GA4's recommended ecommerce events can: view_item, add_to_cart, begin_checkout, add_payment_info, purchase. Fire all five and you get drop-off at every step.

That's the unglamorous part of a Shopify store we worked on. Shopping ads were blocked by a Merchant Center suspension, and the campaigns still running returned 1.87 ROAS against a 4X goal. My role was ads, not frontend. We fixed the feeds, set up GA4 with custom conversions, and restructured the campaigns. 2 months later: 4.5X ROAS, over $20,000 a month.

The work wasn't frontend work. Measurement is what moved it.

Forms are code too

Baymard's data puts average cart abandonment at 70.22% across 50 studies, with 42% of US shoppers citing "just browsing". The remainder is where devs have real influence. Their testing says an ideal checkout can be as short as 12 to 14 form elements. Strict password rules caused up to 19% abandonment among returning users who struggled to sign in. They estimate the average large ecommerce site could gain 35.26% in conversion from checkout design. Large sites again, so treat it as direction.

What you control:

1- Correct autocomplete tokens (email, postal-code, cc-number) so browsers can fill fields
2- Matching type and inputmode so the mobile keyboard fits the field
3- Guest checkout as the visible default, not a hidden link
4- Password rules that don't punish returning users
5- Validation that explains the error next to the field

Put a number on it

Illustrative inputs: 3,000 visits a month, £70 average order. At 1% conversion that's £2,100 a month, at 2% it's £4,200. The gap is £25,200 a year, just over five times a £5,000 build. Use your own inputs.

Passing Lighthouse is the minimum. The build is done when you can say which step loses people and what that step costs.

----

If you've hit this, leave a comment. Curious what your setup looks like.

What AI engines extract and why structure matters

Answer engine optimisation is the practice of structuring and writing content so that AI-powered platforms — ChatGPT, Google AI Overviews, Perplexity, and voice assistants — can easily find it, understand it, and use it as the source of their answers.

AI engines don't read the way humans do. They scan for heading-level signals, extract content from structured markup, and prioritise pages with clear semantic relationships between questions and answers.

A page with a wall of paragraph text about "our expertise and passion" gives an extraction engine nothing to work with. A page with a clear H2 question, a direct two-sentence answer immediately below it, and FAQ schema in the <head> gives it exactly what it needs.

Smaller sites can enter answer engines faster than they climb Google because niche authority and clear, extractable answers on long-tail questions matter more than overall domain strength. That's genuinely good news for small studios and independent developers.

The structural changes that move the needle

1- Rewrite service page H1s and opening paragraphs

Stop: "We're a passionate team of digital experts helping businesses grow." Start: "We develop Shopify stores for ecommerce brands doing £50K–£500K/year. Projects typically complete in 2–4 weeks."

The second version answers the implicit question: "who do you work with and how long does it take." AI engines can extract that. The first gives them nothing.

2- Add FAQ sections with FAQPage schema

Every service page needs a FAQ section. Real questions — not generic ones. Answer each in 2 to 3 sentences. Mark it up with FAQPage JSON-LD schema in the document head.

This is the single fastest AEO win for any service page. AI engines parse JSON-LD directly.

3- Structure blog posts for extraction

Every blog post should target one question. That question goes in the H1. A direct, complete answer goes in the first paragraph — before any context or background. Subheadings should be questions or direct statements, not clever titles.

The pattern: Question H1 → Direct answer paragraph → Evidence and context → Supporting sections.

4- Add Organisation schema to the homepage

The sameAs array matters. AI engines use it to verify brand identity across the web. More confirmed matches across authoritative sources increases citation likelihood.

5- Build citation authority off-site

The brands getting cited are the ones that structure their content to be extracted — and that authority is built both on-site and through references from trusted external sources.

HARO placements, guest articles on industry publications, directory listings with accurate and consistent NAP data — all of it signals to AI engines that your brand is trusted by other trusted sources. Technical schema alone isn't enough without this off-site authority layer.

What to measure

Standard Google Search Console data won't tell you your AEO performance. Start checking manually — ask ChatGPT, Perplexity, and Gemini the questions your clients would ask. Screenshot what comes up. Do it monthly.

Tools like Profound, Goodie, and AI Rank Tracker are building AI visibility tracking — worth watching as they mature through the rest of 2026.

A dedicated AEO programme documented by Maximus Labs delivered 14:1 ROI with $340,000 in attributed revenue, with customer acquisition cost dropping 34% compared to Google organic. The measurement category is early but the impact is trackable.

The implementation is not complicated. It's structural. Most of what needs changing can be done in a CMS without touching the codebase — which is exactly why the studios and founders who understand this will move faster than the ones waiting for a plugin to solve it.

If you've hit this on a client project — leave a comment & visit us. Curious what your setup looks like.