# BrandingLab — Full Content for AI Engines
> Complete content of brandinglab.io as plain markdown, designed for ingestion by AI search engines (ChatGPT, Perplexity, Claude, Gemini, AI Overviews). Each section corresponds to one page or article on the live site. URLs are absolute and canonical.
---
## Site overview
**BrandingLab** is a B2B website and Answer Engine Optimization (AEO) studio for ambitious mid-market teams. We combine three capabilities: Webflow design and development, AI-native React applications, and custom AI products (copilots, RAG systems, agents). Our specialism is making B2B websites that get cited by AI search engines, not just ranked by Google.
- Website: https://www.brandinglab.io
- Founded: 2018
- Location: Israel (serving clients in IL, US, UK, EU, globally)
- Accreditation: Webflow Partner
---
## Page: Home
**URL:** https://www.brandinglab.io/
BrandingLab is a B2B website and Answer Engine Optimization (AEO) studio for ambitious mid-market teams. We design and build websites that get cited by AI search engines (ChatGPT, Perplexity, Claude, Gemini, Google AI Overviews) — not just ranked by Google.
We work across three stacks and pick the right one for the job:
- **Webflow** — for marketing sites where visual storytelling, CMS flexibility, and editorial independence matter most.
- **AI-native React (Lovable, Cursor)** — for sites and apps that need custom logic, integrations, or AI features built into the product.
- **Custom AI products** — copilots, RAG assistants, agents, and embedded AI features for B2B teams.
**Six signs you've outgrown your current site:**
1. Your site loads slowly and Core Web Vitals are red.
2. Your CMS requires a developer for routine content changes.
3. Your brand has evolved but the site still reflects an older positioning.
4. You're invisible in AI search results — ChatGPT and Perplexity don't cite you for your category.
5. Your design system is inconsistent across pages and the marketing team is patching as it goes.
6. You can't ship landing pages or campaign experiments without engineering bottlenecks.
If two or more of those resonate, we should talk.
---
## Page: About
**URL:** https://www.brandinglab.io/about
BrandingLab is a small senior team — strategists, designers, and engineers — who have been shipping B2B websites since 2018. We're a Webflow Partner, but we're not a Webflow agency. We're a website and AEO studio that uses Webflow when it's the right tool, and uses AI-native React or custom builds when it isn't.
**How we work:**
- Senior people, no juniors-as-billing-hours.
- Strategy and design lead; engineering follows. We don't open Figma until the positioning is clear.
- AEO is treated as a first-class requirement, not a post-launch add-on. Every site ships with structured data, semantic HTML, and content architected for AI citation.
- Fixed scope, fixed timeline, no surprises. Most projects ship in 6–12 weeks.
**Who we're for:**
Mid-market B2B companies — typically $5M–$200M revenue — where the website is a material part of how the business wins customers, and where design, performance, and AI visibility actually move the number.
---
## Page: Webflow Agency
**URL:** https://www.brandinglab.io/webflow-agency
We design and build Webflow sites for B2B teams who need a marketing site that looks senior, performs on Core Web Vitals, and gives the marketing team full editorial independence after launch.
**What's included in a typical Webflow engagement:**
- Discovery and content strategy — sitemap, messaging hierarchy, and CMS architecture before any design work.
- High-fidelity design in Figma — typography system, component library, page templates.
- Webflow build — pixel-perfect, responsive, accessible, and structured for editor independence.
- CMS architecture — collections for case studies, articles, team, jobs, and resource hubs.
- AEO foundations — JSON-LD schema, semantic HTML, FAQ patterns, llms.txt and llms-full.txt.
- Migration — from WordPress, HubSpot, Squarespace, or custom CMS, with full URL redirect mapping.
- Training and handover — your team owns the Webflow project after launch.
**Timelines:** 4–12 weeks depending on scope. **Ownership:** You own the Webflow project. **Support:** Optional retainers for content, iteration, and new pages.
---
## Page: AEO Services
**URL:** https://www.brandinglab.io/aeo-services
Answer Engine Optimization (AEO) is the discipline of making your website citable by AI search engines — ChatGPT, Perplexity, Claude, Gemini, and Google AI Overviews. It is not SEO. The unit of success is being the source the AI cites when a prospect asks a question, not being the tenth blue link on a search engine results page.
**What our AEO engagements typically include:**
- **Audit** — a full readout of how AI engines currently represent your brand, what schema you have, what citation gaps exist, and what to fix first.
- **Structured data** — Organization, Service, Article, FAQPage, BreadcrumbList, AggregateRating schemas in the initial HTML payload (not injected by JavaScript).
- **Content rewriting for AI citation** — clear definitions in the first paragraph, TL;DR boxes, comparison tables, numbered steps, FAQ sections at the bottom, quotable statistics with sources.
- **AI-native discovery files** — llms.txt and llms-full.txt for AI crawlers that prefer markdown over HTML.
- **Prerendering or SSR** — real semantic HTML in the body of every page so AI crawlers can read content without executing JavaScript.
- **Entity authority** — Wikidata entries, third-party citations, AggregateRating from Clutch/G2 to strengthen your brand entity in AI knowledge graphs.
- **Citation tracking** — monitoring which queries surface your brand across each AI engine and tracking changes over time.
The goal isn't to rank in Google. The goal is to be the answer.
---
## Page: AI Products
**URL:** https://www.brandinglab.io/ai-products
We design and build custom AI products for B2B teams — copilots, RAG assistants, agents, and embedded AI features — when an off-the-shelf chatbot won't cut it.
**Examples of what we build:**
- **Internal copilots** — domain-specific assistants trained on your documentation, sales playbooks, or product knowledge.
- **RAG systems** — retrieval-augmented generation over your own corpus (knowledge bases, product docs, contract libraries) with citation back to source.
- **Agents** — autonomous workflows that take action across your stack: triaging inbound leads, drafting outbound, summarising meetings, generating reports.
- **Embedded AI features** — AI capabilities built directly into your existing product (search, summarisation, generation, classification).
**Stack:** TypeScript, React, Node, Python, OpenAI/Anthropic/Google models, Pinecone/Supabase for vector storage, Lovable Cloud for backend. **Deliverables:** working product, source code, ownership transfer, optional ongoing support.
---
## Case studies
### Case study: Threadworks
_21 warehouse homes in Bethnal Green — Capri's design intent, translated one-to-one into a Webflow site the sales team can run._
**URL:** https://www.brandinglab.io/work/threadworks
**Industry:** Real Estate Development
**Stack:** Brand Launch, Real Estate, Webflow
**Timeline:** 2 weeks
**Challenge:** When a branding agency delivers a Figma, what you've received is brand equity in visual form. Every type choice, every image ratio and every hover state has been argued over for a reason. The moment that file hits a developer who doesn't care about the reasons, the whole thing starts leaking value. The site ships, it looks 'fine,' but the feel is gone — and no one can quite explain why the brand isn't landing the way it used to.
**Approach:** The fix is not hiring a bigger agency that tries to do both brand and build. It's choosing a developer who treats design intent as something to protect, not approximate. Pelumi led development for us on Threadworks and translated Capri's Figma one-to-one — every Crittall detail, every image rhythm, every breakpoint — then wired it into a Webflow CMS so the sales team could update the site without going back to a developer for every change.
**Results:**
- Homes marketed: 21
- Figma to live: 1:1 translation
- CMS: Sales-team managed
- Delivered for: VFUND
**FAQs:**
**Q: Why does the Figma-to-build handoff matter so much?**
A: A Figma file is brand equity in visual form. Every decision in it has been argued over for a reason. If the developer treats it as a rough reference rather than a spec, the site will look 'fine' but the feel will be gone — and the brand stops landing the way it used to.
**Q: How did you protect Capri's design intent on Threadworks?**
A: Pelumi led development and translated Capri's Figma one-to-one — every Crittall detail, image rhythm and breakpoint — rather than approximating it. That precision is what keeps the brand feel intact when the site goes live.
**Q: Can the sales team update the site themselves?**
A: Yes. The build is wired into a Webflow CMS the sales team can run themselves, so day-to-day edits and content updates don't require a developer each time.
**Q: What should I ask before commissioning my next site?**
A: Treat the Figma-to-build handoff like the transaction it is. Ask who specifically is building it. Ask for a side-by-side of a previous Figma and the live site they shipped from it. A good developer costs more; they also save you from rebuilding the site in eighteen months because the brand stopped working online.
---
### Case study: Gazette Search
_SA Government Gazette intelligence platform — 900,000+ notices searchable by ID number in seconds; bulk-screens 50,000 IDs in under 60 seconds._
**URL:** https://www.brandinglab.io/work/gazette-search
**Industry:** Legal & Financial Services — Collections
**Stack:** AI Product, SaaS
**Timeline:** 6+ months (in production)
**Challenge:** Large SA collection agencies and BPOs run hundreds of thousands of searches per month against the Government Gazette — verifying deceased estates, insolvencies, liquidations, sales in execution and name changes. Every existing access path was broken in a different way: the official government source rejects programmatic search, the popular community mirror had started returning broken files, and the legally-clean public archive was frozen at 2021. A false 'nothing found' isn't cosmetic here — it puts lawyers in courtrooms and collections analysts into recoveries that should never have been opened.
**Approach:** I led the build as one developer, one repo, a pragmatic stack — starting in Lovable for UI velocity, then moving to Claude for the repo-wide query and index work needed to hit sub-second search against millions of rows. Hundreds of prompts later — over several months — the system returned matches in seconds against a 2GB database from a single web instance. When a data audit surfaced a 29.6% silent gap in historical coverage, I backfilled from the authoritative public archive, wired a weekly fetch against the official source for everything from 2022 onward, and quietly created retroactive watchlists for 507 previously failed searches — no 'we're sorry' email, just the answer users originally came for.
**Results:**
- Gazette notices indexed, 25 years of coverage: 900,000+
- Bulk-screened in under 60 seconds: 50,000 IDs
- Search turnaround vs the manual baseline: Seconds vs 8 months
- Per-search pricing across the volume curve: R35 → R0.55
---
### Case study: Tabono
_20+ page industrial website built in 3 weeks for a conference launch_
**URL:** https://www.brandinglab.io/work/tabono
**Industry:** Mining & Industrial
**Stack:** Webflow, Industrial, Animation
**Timeline:** 3 weeks
**Challenge:** Three weeks. Twenty-plus pages. A conference date that wasn't moving. The site needed to balance African heritage with global credibility, deliver a genuine 'wow factor' for conference attendees, and perform on mobile devices over unreliable exhibition hall WiFi.
**Approach:** I led the project with parallel workflows replacing sequential design-build cycles: while a partner specialist was finalising later pages, development had already begun on core architecture. The visual system drew from African design principles — geometric precision, bold structural forms, earthy tones — without relying on decorative motifs. Hardware-accelerated CSS and GSAP animations were tested specifically for conference conditions.
**Results:**
- Pages Delivered: 20+
- Build Time: 3 weeks
- Conference Launch: On time
- Animation System: Custom GSAP
**FAQs:**
**Q: How did you deliver 20+ pages of Webflow in three weeks?**
A: I replaced sequential design-build cycles with parallel workflows — development began on the core architecture and reusable components while a partner specialist was still finalising later pages, compressing the critical path significantly.
**Q: How did you balance African heritage with global credibility?**
A: The visual system drew from African design principles — geometric precision, bold structural forms and earthy tones — without leaning on decorative motifs. The result reads as proudly African and globally serious at the same time.
**Q: How does the site perform on conference WiFi?**
A: Animations were built with hardware-accelerated CSS and GSAP and tested specifically for the conference environment, so the experience held up on mobile devices over unreliable exhibition hall connections.
---
### Case study: Protego Ventures
_Defense technology VC website built for authority and restraint_
**URL:** https://www.brandinglab.io/work/protego-ventures
**Industry:** Venture Capital — Defense Tech
**Stack:** Webflow, Finance, Brand Translation
**Timeline:** 4 weeks
**Challenge:** Most VC websites go too clinical or overcorrect into aggressive design. Protego needed authority through restraint — every element had to communicate precision, not noise. Three weeks of colour exploration alone were needed to get the exact beige that held the weight of CAPRI's design intent on screen.
**Approach:** I directed monochromatic photography of defense technology hardware and structured navigation around three distinct visitor mental models: founders, LPs, and due-diligence evaluators. My specialist network built a utility-first class architecture for independent content management, with SEO foundations built in from day one — structured heading hierarchy and clean URL structure.
**Results:**
- Prospect Prep: Pre-meeting understanding
- Build Time: 4 weeks
- Navigation Iterations: 7 versions
- Core Web Vitals: All green
**Client quote:** "Working with BrandingLab was like finding a partner who could read our minds. They understood that in our world, subtlety and precision matter more than flash." — Protego Ventures, Founding Team
**FAQs:**
**Q: Why did Protego need 'authority through restraint'?**
A: In defense-tech venture capital, credibility and discretion are non-negotiable. Most VC sites either go too clinical or overcorrect into aggressive design — Protego needed every element to signal precision rather than noise.
**Q: How did you translate CAPRI's brand into Webflow?**
A: I worked from CAPRI's existing visual identity and led the rebuild natively in Webflow — including three weeks of colour exploration to land on the exact beige that held the design intent on screen, and monochromatic hardware photography across the site.
**Q: How does the navigation handle different visitor types?**
A: I structured navigation around three distinct mental models — founders, LPs and due-diligence evaluators — and went through seven versions to make sure each audience reached the content they needed without friction.
**Q: Were SEO foundations built in from day one?**
A: Yes. Structured heading hierarchy, clean URL structure and Core Web Vitals were treated as first-class requirements — the launched site shipped with all Core Web Vitals green.
---
### Case study: CHRU
_Rebuilding South Africa's leading HIV research unit website_
**URL:** https://www.brandinglab.io/work/chru
**Industry:** Clinical Research & Healthcare
**Stack:** Webflow, Healthcare, CMS
**Timeline:** 6 months
**Challenge:** Three distinct audiences — anxious patients, evaluating researchers, and assessing funders — arriving at the same site with entirely different needs. Navigation assumed prior knowledge, visual inconsistencies undermined credibility, and authority signals were buried. Patient pathways were unclear and anxiety-inducing.
**Approach:** I spent weeks on information architecture mapping before any design work, then structured layered navigation around recognisable categories with each section serving its primary audience first. My specialist network built a Webflow design system of reusable components to ensure visual consistency structurally, with CMS collections for research, trials, team, and news giving the client's team full editorial independence.
**Results:**
- Audience Paths: 3 distinct journeys
- CMS Independence: Full editorial control
- Project Duration: 6 months
- Content Sections: Research, Trials, Patient Info
**FAQs:**
**Q: How do you serve patients, researchers and funders on one site?**
A: I mapped three distinct user journeys and structured layered navigation around recognisable categories, with each section serving its primary audience first — so patients aren't asked to read like researchers and vice versa.
**Q: Why did the rebuild take six months?**
A: Most of the early work was information architecture, not design. I spent weeks mapping content, audiences and patient pathways before opening a design tool, which is what made the launched site coherent rather than just refreshed.
**Q: Can the CHRU team manage content without a developer?**
A: Yes. My specialist network built CMS collections for research, trials, team and news inside a Webflow design system of reusable components — the client's team has full editorial independence while visual consistency is enforced structurally.
---
### Case study: Mind Ventures
_4-month Webflow build with custom GSAP animation system_
**URL:** https://www.brandinglab.io/work/mind-ventures
**Industry:** Value Creation & Investment
**Stack:** Webflow, Finance, GSAP
**Timeline:** 4 months
**Challenge:** Financial services websites converge on the same stock photography, abstract language, and navy palettes. Mind Ventures' sophisticated clients — high-net-worth individuals and experienced operators — pattern-match for genericness as a signal of undifferentiated thinking. Animation needed to serve authority, not undermine it.
**Approach:** I led the build of a custom GSAP animation system: scroll-driven text highlighting, staggered character entrance animations, subtle parallax, and crafted hover interactions. Typography mirrored the firm's intellectual approach — accessible at top level, progressively detailed deeper in. Animation hosted via GitHub/jsDelivr CDN with data-attribute targeting for CMS resilience.
**Results:**
- Discovery Phase: Multi-week
- Animation System: Custom GSAP
- Build Duration: 4 months
- Meeting Quality: Prospects pre-informed
**FAQs:**
**Q: Why did the Mind Ventures project take four months?**
A: The timeline reflected the depth of discovery required — understanding the firm's investment thesis, ideal client profile and competitive landscape thoroughly enough to design something that didn't pattern-match the rest of financial services.
**Q: How does the GSAP animation system serve authority rather than distract?**
A: Animations are restrained and purposeful: scroll-driven text highlighting, staggered character entrances, subtle parallax and crafted hover states. They reinforce the firm's intellectual rigour rather than performing for its own sake.
**Q: How is the animation kept resilient when content changes?**
A: Animation code is hosted on a GitHub/jsDelivr CDN and targets elements via data attributes, so editors can update copy and CMS items in Webflow without breaking the motion system.
---
### Case study: Voxeon Communications
_Turning a whispering PR brand into one that shouts_
**URL:** https://www.brandinglab.io/work/voxeon-communications
**Industry:** Public Relations
**Stack:** Webflow, PR, Brand Expression
**Timeline:** 4 weeks
**Challenge:** Voxeon's fractional PR model — their key differentiator — wasn't explained on the site. Prospects arrived at meetings confused about what they were buying. The 'good guys' positioning wasn't visible, and the visual identity had implementation issues: poor contrast ratios, overused accent colour, inconsistent typographic hierarchy.
**Approach:** I ran a forensic audit of the existing brand implementation, fixed contrast ratios throughout, and reserved the purple accent for specific functions only — CTAs, key data, selected emphasis — restoring its visual significance. I gave the fractional model prominent homepage placement with a plain-language explanation, and structured the CMS for easy content publishing.
**Results:**
- Meeting Quality: Prospects pre-informed
- Client Self-Selection: Right-fit inbound up
- Publishing Cadence: Monthly → Weekly
- Build Time: 4 weeks
**FAQs:**
**Q: What was wrong with Voxeon's previous site?**
A: The visual identity was strong on paper but poorly implemented — weak contrast, overused purple accent, inconsistent type hierarchy — and the messaging was cautious. For a PR agency, that quiet posture was actively losing business.
**Q: How did you make the fractional PR model clearer?**
A: We gave the fractional model prominent homepage placement with a plain-language explanation, so prospects arrive at the first meeting already understanding what they're buying instead of needing it spelled out.
**Q: How did you fix the brand implementation issues?**
A: I ran a forensic audit, fixed contrast ratios across the system and reserved the purple accent for CTAs, key data and selected emphasis only — which restored its visual significance instead of letting it go flat.
---
### Case study: Opsi Systems
_Enterprise transportation technology website — built for credibility, authority, and the B2B buyer._
**URL:** https://www.brandinglab.io/work/opsi-systems
**Industry:** Enterprise Transportation Technology
**Stack:** Webflow, Enterprise, AEO
**Timeline:** 4 weeks
**Challenge:** Enterprise software buyers evaluate risk as much as they evaluate features. Opsi needed a website that would earn the trust of logistics directors, CIOs, and procurement teams in the first scroll — without a generic SaaS template, without startup energy, and without simplifying the technical depth of the product. The challenge wasn't just design. It was communication architecture: how do you present GPU-powered route optimization, ISO 27001 compliance, multi-fleet TMS, and 25 years of domain expertise to four different global buyer audiences in one coherent digital experience?
**Approach:** I built opsisystems.com on a dark, authoritative visual foundation — a deliberate departure from the startup aesthetic. Every design and content decision was made around one question: what does an enterprise procurement team need to see to move forward? The content architecture was structured around buyer questions, not product features: Who is this company and how long have they been doing this? What does the platform actually do at enterprise scale? Can this handle our complexity — multi-fleet, multi-principal, global? Are they compliant with ISO 27001, GDPR, and POPIA? How do we start a conversation? I also implemented Answer Engine Optimization (AEO) — structuring every page with correct heading hierarchy, FAQ schema markup, and semantic content blocks so Opsi appears in AI-generated research answers, not just traditional search results. For Lottie animations, I generated custom files by feeding the site content into Claude Code and prompting it to build Lottie diagrams in line with the Opsi brand style — #0A0A1A background, orange accent — then exported them as lightweight JSON files and embedded them inline in Webflow via the Lottie Player component.
**Results:**
- Global Regions: 4
- Years Expertise: 25+
- Figma to Live: 4wks
- AEO: Optimised
- Active Users (90d): 406
- Organic Search Users: 69
- Contact Page Bounce: 12%
- Delivery Page Bounce: 0%
**Client quote:** "BrandingLab understood exactly what we needed — a website that communicates the weight and credibility of what we've built over 25 years. The result speaks for itself." — Opsi Systems Team, opsisystems.com
**FAQs:**
**Q: Why was Webflow chosen for an enterprise build?**
A: Webflow gives Opsi Systems full CMS control with no ongoing developer dependency for content updates. It produces clean, semantic HTML that is both performant and structured correctly for SEO and AEO. For an enterprise company managing content across a global audience, that independence is critical.
**Q: What is AEO and why does it matter for B2B companies?**
A: Answer Engine Optimization (AEO) structures your website content so it appears in AI-generated answers from tools like ChatGPT, Perplexity, and Google's AI Overview. Enterprise B2B buyers increasingly use AI to research platform decisions before visiting any vendor website. AEO ensures Opsi Systems is part of those answers.
**Q: How did BrandingLab handle the technical complexity of the product?**
A: I built the content architecture around buyer questions rather than product features. Technical depth (GPU optimization, multi-principal fleet management) was framed in terms of what it means for the buyer's operation — not in engineering language. This makes the site accessible to procurement teams and technical evaluators simultaneously.
**Q: How were the Lottie animations created?**
A: The Lottie files were generated using Claude Code — I fed the site content into the AI and prompted it to build Lottie animations in line with the Opsi brand style. This produced bespoke, on-brand motion graphics without generic stock animation libraries. Each file was exported as lightweight JSON and embedded via Webflow's Lottie Player component.
**Q: How long did the project take?**
A: The full project — from Figma design to live published site — was completed in 4 weeks. This included Webflow design and development, AEO content architecture, custom Lottie animation generation, and CMS setup.
**Q: Can BrandingLab build something similar for my business?**
A: Yes. If you're running a B2B company that needs a website built for enterprise buyers — with Webflow, AEO strategy, and content architecture that earns trust — get in touch at brandinglab.io.
---
### Case study: Jabali Mining Services
_Mining expertise at the scale of the machinery — a site built to feel the size of the operation, not just describe it._
**URL:** https://www.brandinglab.io/work/jabali-mining
**Industry:** Contract Mining & Mineral Processing
**Stack:** Webflow, Mining, Brand Expression
**Timeline:** 4 weeks
**Challenge:** The sector's visual convention actively works against companies that are good at the work. Buyers evaluating a contract miner are assessing capability and safety — but the standard mining website flattens fleet, blasting capability and rehabilitation practice into a bulleted list that reads identically to every competitor's. Jabali also runs a genuinely wide service line — open cast mining, drilling and blasting, load and haul, crushing and screening, bulk material handling, rehabilitation, equipment hire, quantity surveying, stockpile management, construction and operator training. Presented conventionally, that breadth reads as unfocused. Presented well, it reads as the reason you don't need three contractors.
**Approach:** I designed the site around the physical reality of the operation rather than around a services taxonomy. The homepage opens on blast footage — a live detonation on the mine face — which sets the register for everything below it: heavy, controlled, expert work at scale. The services section pairs each capability with its own site photography and runs a sticky index down the left-hand side, so the visitor scrolls through the operation the way you'd walk it — men, machines and process in sequence — rather than clicking through a menu of abstractions. The brand meaning does structural work rather than decorative work: the Swahili derivation gets its own moment on the page, with pronunciation and translation, so the name becomes a positioning statement. The sustainability commitment is handled the same way — 'put back more than we extract' is treated as the operating principle, with rehabilitation presented as a planned discipline from before a mine opens. Video does the narrative work throughout, not just in the hero — mining is a process, and motion shows the sequence where static photography can only show a frozen instant of it. The drone and ground photography carried a substantial share of this, and the design decision that mattered most was giving it room: full-bleed, uncropped, at scale. Committing to that much video created the obvious constraint — the site had to stay fast on a mine site in southern Africa, on mobile, on a connection that isn't guaranteed. Assets were compressed and served at appropriate sizes per breakpoint, type was kept to system-safe stacks, and the responsive behaviour reflows the full-bleed treatment rather than abandoning it on small screens.
**Results:**
- Service Lines Documented: 11
- Commodities Mined: 10
- Projects Completed: 21
- Years' Experience: 30+
**FAQs:**
**Q: How do you make a mining company website feel like the actual operation?**
A: Scale has to be shown, not claimed. On Jabali we opened on live blast footage from the mine face and gave the drone and site photography full-bleed treatment at full scale. The alternative — cropping strong photography into small uniform cards — is what makes most industrial sites feel smaller than the businesses behind them.
**Q: How do you present a wide service line without it reading as unfocused?**
A: Sequence and continuity. Jabali's eleven service lines run as a single scrollable narrative with a sticky left-hand index that tracks position, so a visitor moves through the operation in a logical order instead of navigating a menu of abstractions. Breadth then reads as capability rather than dilution.
**Q: Why does a brand's name matter to the website structure?**
A: Jabali is Swahili for rock or outcrop — strong as rock. Rather than leaving that buried in an About page, the site gives the derivation its own moment with pronunciation and translation, which converts the name into a positioning statement a buyer actually remembers.
**Q: Why Webflow for an industrial or mining business?**
A: Webflow handles heavy video and image assets without a plugin stack, produces clean semantic HTML that indexes properly for both search and AI answer engines, and lets the client's team update project and service content without a developer on retainer.
**Q: How do you keep a video-heavy site fast on poor connections?**
A: Compress and serve assets at the size each breakpoint actually needs rather than shipping one large file to every device, keep type to system-safe stacks so nothing blocks first render, and make the responsive rules reflow full-bleed media instead of dropping it on mobile. On Jabali this mattered specifically because the audience includes people opening the site from a mine site on an unreliable connection.
---
## Articles
### Article: Wix for AEO: How the Modern Platform Handles AI Search
**URL:** https://www.brandinglab.io/articles/wix-for-aeo
**Published:** 2026-07-19
**Read time:** 5 min read
**Author:** Russel Davis, Founder, BrandingLab
**Category:** AEO
**Key takeaways:**
- Wix's old weakness was client-side rendering, which made content hard for crawlers to read. Newer Wix Studio sites now use server-side rendering, resolving that issue.
- Schema is built in and customizable: a Structured Data Manager adds LocalBusiness, Product, FAQ, and Review schema without code, plus custom JSON-LD.
- Wix offers an AI Visibility tool to track how your site is mentioned across LLMs like ChatGPT, Gemini, and Perplexity.
- The caveats: the strongest capabilities are concentrated in newer Studio sites, and you accept less low-level control in exchange for all-in-one convenience.
Wix spent years with a reputation for weak SEO, so many people assume it's a poor choice for Answer Engine Optimization. That assumption is now out of date. The modern Wix platform — especially Wix Studio — has closed most of the gap. Here's a straight look at where Wix stands for getting cited in ChatGPT, Perplexity, and Google's AI Overviews.
For the full platform-by-platform comparison, see [the best website platform for AEO](/articles/best-website-platform-for-aeo).
### The rendering problem Wix fixed
For most of its history, Wix leaned on client-side rendering — the browser had to run JavaScript to display content. That was a real problem for search, and it's an even bigger one for AEO, because most AI crawlers don't execute JavaScript and would see an incomplete page.
Wix addressed this at the platform level. Its newer Wix Studio product rolled out server-side rendering, so pages are rendered on the server and the content is present in the HTML a crawler receives. Reporting on the platform indicates new Wix Studio sites now achieve strong technical SEO scores out of the box. For AEO specifically, this is the change that matters most — it moves Wix from "works against you" to "works for you" on the core requirement.
### Built-in schema and AI tracking
Wix now applies standard structured data automatically to content like product pages, blog posts, and events, and its Structured Data Manager lets you configure LocalBusiness, Product, Event, FAQ, and Review schema without writing code — generating valid JSON-LD and injecting it into the page head. You can also add custom JSON-LD for cases the presets don't cover, and scale it across templates.
On the measurement side, Wix offers an AI Visibility tool that shows how your site is mentioned in large language models and tracks AI-driven traffic, so you can see whether your AEO efforts are translating into citations.
### The caveats
Two things keep Wix from being a universal answer. First, the strongest rendering and schema capabilities are concentrated in the newer Wix Studio platform; older Wix sites don't automatically inherit all of them, so what you can do depends on how and when your site was built. Second, Wix is an all-in-one, managed environment. That's a feature for simplicity, but it means less low-level control than an open platform like WordPress or a headless setup like Sanity — if you need highly customized technical behavior, you may hit the platform's boundaries.
### Who Wix fits for AEO
Modern Wix is a legitimate AEO option for small businesses and teams that want a single, managed tool and don't need deep customization. If you're on Wix Studio, you get the rendering and schema fundamentals without hiring a developer. Businesses that need maximum control, complex content models, or custom application logic will still be better served by WordPress, Webflow, or a headless build — but for its target user, Wix is no longer the liability it once was.
### Frequently asked questions
#### Is Wix good for AEO in 2026?
Modern Wix is far better than its old reputation. Newer Wix Studio sites use server-side rendering, which resolves the JavaScript rendering issues that historically hurt Wix on search and would block AI crawlers. Wix also includes a Structured Data Manager for schema and an AI Visibility tool for tracking LLM mentions. The main caveat is that the strongest capabilities are concentrated in the newer Studio platform.
#### Does Wix support schema markup?
Yes. Wix automatically applies standard structured data to content like products, blog posts, and events, and its Structured Data Manager lets you add LocalBusiness, Product, Event, FAQ, and Review schema without code. You can also inject custom JSON-LD for cases the built-in options don't cover.
#### Can Wix sites be seen by AI crawlers?
Yes, on newer Wix Studio sites. Because Wix Studio uses server-side rendering, content is present in the HTML that AI crawlers receive, so crawlers that don't execute JavaScript can still read it. Older Wix sites that rely on client-side rendering are weaker in this respect, so the specifics of your build matter.
#### Is Wix or WordPress better for AEO?
Both can work. Wix is more managed and easier for non-technical users, with rendering and schema handled on newer Studio sites. WordPress offers more control and a deeper plugin ecosystem but requires more maintenance. Wix suits small businesses wanting simplicity; WordPress suits teams wanting flexibility and willing to maintain the stack.
---
### Article: How to Choose a B2B Webflow Partner (Accredited, Honest)
**URL:** https://www.brandinglab.io/articles/best-webflow-partners-for-b2b
**Published:** 2026-07-19
**Read time:** 7 min read
**Author:** Russel Davis, Founder, BrandingLab
**Category:** Webflow
**Key takeaways:**
- A great B2B Webflow build is decided by information architecture, CMS modeling, semantic structure, and AEO — not homepage aesthetics.
- Webflow accreditation verifies platform competence; it does not guarantee B2B strategy, AEO capability, or content discipline — check those separately.
- Verify the actual badge an agency holds and ask what the assessment covered, rather than trusting a generic "partner" label.
- Migration discipline — URL mapping and 301 redirects — protects years of search equity and should be standard, not an add-on.
- Ten specific questions on accreditation, IA, CMS modeling, migration, AEO, and process will expose most weak partners before you sign.
- The biggest red flags: badge inflation, no migration plan, SEO/AEO deferred to after launch, and a design-first pitch with no content conversation.
Search for "best Webflow partners for B2B" and you'll find lists ranked by portfolio polish and badge count. Neither predicts whether your rebuild will work. Here's what actually matters — what the badges do and don't tell you, and the questions to ask any agency, including us.
### What separates a good B2B Webflow partner from a merely good Webflow partner?
A good B2B build is decided by information architecture, semantic structure, CMS modeling, and AEO — not homepage aesthetics. Plenty of agencies can produce a beautiful homepage. Far fewer can structure a site so a buying committee can self-serve answers, a marketing team can publish without a developer, and AI answer engines can parse and cite the content.
In practice:
- **Information architecture.** B2B sites serve long, multi-stakeholder buying cycles. The page structure should map to how buyers evaluate — problems, use cases, proof, pricing logic — not to your org chart.
- **CMS and content modeling.** A B2B site is a content system, not static pages. Case studies, integrations, articles, and product pages belong in structured collections with defined fields and relationships, so content scales without breaking design.
- **Semantic structure and AEO.** Buyers increasingly shortlist vendors through AI-generated answers, which requires clean headings, structured data, crawlable rendering, and content that answers questions directly — build-time decisions, not later bolt-ons. If AEO is new territory, start with [what AEO actually is](/articles/what-is-aeo).
- **Migration discipline.** If you have an existing site, the partner's redirect and URL-mapping plan matters more than their moodboards. A sloppy migration quietly deletes years of search equity.
For the fuller picture of what a B2B build on this platform involves, see our pillar guide to [Webflow for B2B](/articles/webflow-for-b2b).
### What do Webflow's accreditation badges actually mean?
Accreditation verifies platform competence — it does not guarantee B2B strategy, AEO capability, or content discipline. Webflow's partner ecosystem includes certification and accreditation tiers, and the distinction buyers most often blur is between Webflow Accredited and Enterprise accreditation. They are different things, and some agencies let the ambiguity work in their favour.
The honest version: an accreditation tells you the team has demonstrated real proficiency in the platform itself. That's useful signal — it filters out agencies that treat Webflow as an afterthought. What it doesn't tell you is whether the team understands B2B positioning, can model your content sensibly, or can make a site legible to answer engines. Those are separate skills, and you have to check them separately.
Two practical rules:
1. **Verify the actual badge.** Ask which accreditation the agency holds and what the assessment covered. "Webflow partner" on a homepage is a label, not a credential.
2. **Don't over-weight the tier.** An Enterprise badge doesn't make an agency good at B2B, and its absence doesn't make one wrong for you. Match the partner to your project, not to the most impressive-sounding label.
For transparency: BrandingLab is Webflow **Accredited** — not Enterprise accredited. We'd rather tell you that plainly than let a vague "partner" claim do the work.
### What should you ask before you hire?
Ask questions that expose process, structure, and honesty — the ten below will do it, put to any agency on your shortlist, including us:
1. Which Webflow accreditation do you hold, and what did it actually assess?
2. Can you walk me through the information architecture of a recent B2B build — and the reasoning behind it?
3. How will you model our content in the CMS? Which collections, which fields, which relationships?
4. What's your migration plan — specifically URL mapping and 301 redirects?
5. How do you handle AEO: schema, structured content, crawlability, llms.txt?
6. Who writes or restructures the content, and when in the process does that happen?
7. What does your process look like, phase by phase, and where do we give input?
8. What will our team be able to edit without a developer after launch?
9. What's included in the price, and what typically triggers extra cost?
10. What happens after launch — handover, documentation, support?
A capable partner will answer all ten specifically. Vague answers to questions 3, 4, and 5 should worry you most, because those failures only surface months after launch. Our breakdown of the [B2B website rebuild process](/articles/b2b-website-rebuild-process) shows what specific answers look like.
### What are the red flags?
The biggest red flag is a pitch built entirely on visuals, with no questions about your buyers, content, or existing URLs. Others worth walking away from:
- **Badge inflation.** Implying enterprise-level partner status without holding it, or "official partner" language they can't specify.
- **No migration plan.** If redirects and URL mapping don't come up until you raise them, your search equity isn't part of their definition of done.
- **SEO and AEO "after launch."** Structure, schema, and rendering are build-time decisions; deferring them is deferring the hard part.
- **No content conversation.** A partner who never asks what you'll publish, or who will write it, is building you a brochure.
- **Design-first process.** Mockups before information architecture means the thinking is happening in the wrong order.
### Where does BrandingLab fit?
BrandingLab is a Webflow Accredited B2B website and AEO studio, founded by Russel Davis. Since this article's premise is honesty, here's our position stated the way we'd want any agency to state theirs.
Typical B2B builds run $15k–$60k through a 6-phase process over 8–12 weeks. Migrations include URL mapping and 301 redirects as standard. AEO is built in from day one: component-level schema, structured CMS, llms.txt, crawlable rendering. Recent work includes Protego Ventures (defence-tech investor site, four weeks), Tabono (20+ page B2B SaaS site and content system), Opsi Systems (enterprise transport-tech, AEO from day one), CHRU (brand refresh and rebuild), and Voxeon (B2B telecoms repositioning and build).
What we won't claim: enterprise accreditation, or that any badge — ours included — proves B2B judgment. Ask us the ten questions above; that's what they're for. Read more about [how we work as a B2B Webflow agency](/articles/b2b-webflow-agency), or [book a discovery call](/contact) and interrogate us directly.
### Frequently asked questions
#### What should I look for in a Webflow partner?
Look for evidence of structure, not just style: information architecture reasoning, CMS content modeling, a concrete migration plan with URL mapping and 301 redirects, and AEO handled at build time. Verify the actual Webflow accreditation held and what it covered, then probe process — phases, timeline, what your team can edit after launch. Portfolio polish matters least; it's the easiest thing to fake.
#### What's the difference between a Webflow Accredited and an Enterprise partner?
They're different tiers in Webflow's partner ecosystem, and the honest summary is that either one verifies platform competence — not B2B strategy or content discipline. Rather than trusting a "partner" label, ask which badge the agency actually holds and what the assessment covered. BrandingLab, for the record, is Webflow Accredited, not Enterprise accredited. Judge any agency on their demonstrated work, not the tier name.
#### Do I need an enterprise partner for a B2B site?
Not necessarily. The badge tier doesn't determine whether a partner can deliver a strong B2B site — information architecture, CMS modeling, migration discipline, and AEO capability do, and those must be checked directly regardless of accreditation level. Scope your decision to your project: team fit, relevant B2B work, and specific answers to the questions in this guide. Want a second opinion on your current site first? [Request an audit](/audit).
---
### Article: WordPress to Webflow Migration for B2B
**URL:** https://www.brandinglab.io/articles/wordpress-to-webflow-migration-for-b2b
**Published:** 2026-07-19
**Read time:** 7 min read
**Author:** Russel Davis, Founder, BrandingLab
**Category:** Webflow
**Key takeaways:**
- The platform switch doesn't cost rankings — sloppy execution does; missing redirects, dropped metadata, and broken internal links are the real risks.
- B2B teams leave WordPress over plugin dependency, security patching, performance tuning, and developer bottlenecks that keep marketing from shipping independently.
- A disciplined migration maps every URL with traffic or backlinks and puts 301 redirects live before launch, with the new sitemap submitted to Search Console at launch.
- Preserve metadata, alt text, internal links, and schema deliberately — a migration should change your platform, not your search footprint.
- AEO (component-level schema, structured content, crawlable rendering) is set up during the migration, not as a second project after.
- A full rebuild plus migration typically runs 8–12 weeks, with migration/QA as its own phase, and well-executed migrations usually see rankings recover within a few weeks.
Most B2B teams considering a WordPress to Webflow migration are stuck on one question: will we lose the rankings we spent years building? A migration executed with discipline — every URL mapped, redirects live before launch, metadata carried over intact — preserves your SEO equity. A casual one can damage it. The difference isn't luck; it's process.
### Why do B2B teams leave WordPress?
B2B teams leave WordPress because maintaining the site starts consuming more effort than marketing on it: plugins that each need updating, security patches that can't be ignored, performance tuning that never quite sticks, and a developer queue for changes that should take minutes.
The plugin problem compounds. Every capability — forms, SEO settings, caching, redirects — depends on a third-party plugin, and each one is a dependency to patch, a potential conflict, and a possible security hole. Keeping the stack stable becomes its own recurring workstream.
The deeper cost is organizational. When routine changes — a new landing page, an updated case study — have to go through a developer, marketing can't ship independently. Campaigns wait on tickets. For a B2B team whose website is its primary demand channel, that bottleneck is the real reason to move. The full comparison is in [Webflow vs WordPress for B2B](/articles/webflow-vs-wordpress-for-b2b); this article covers getting from one to the other safely.
### Will I lose SEO migrating from WordPress to Webflow?
No — not if the migration is executed properly, and this is where discipline matters most. The platform switch itself doesn't cost you rankings. What costs rankings is sloppy execution: URLs that change without redirects, metadata that gets dropped, internal links that break, pages that quietly disappear.
Search engines have your current site mapped — every URL, every title tag, every backlink pointing at a specific page. When a URL changes and nothing tells crawlers where the content went, the equity attached to that page starts to evaporate. That's the actual risk, and it's manageable.
The mitigation is a redirect and preservation plan built before anything launches. Every URL with traffic or backlinks gets mapped to its destination on the new site. 301 redirects go live before launch, not after. Metadata, alt text, and internal links carry over deliberately rather than being rebuilt from memory. Done this way, well-executed migrations typically see rankings recover within a few weeks of launch as search engines process the redirects and re-crawl the new structure. Expect some fluctuation in that window; that's normal re-indexing, not lost ground.
### What does the migration process look like step by step?
A disciplined WordPress to Webflow migration follows a fixed sequence: inventory, URL mapping, rebuild, redirects, launch, and monitoring. At BrandingLab, migration and QA is its own project phase — not a checklist item at the end of a build.
1. **Full content inventory.** Every page, post, asset, and template on the WordPress site gets catalogued, so you decide deliberately what moves, what consolidates, and what retires.
2. **URL mapping.** Every URL with traffic or backlinks is mapped to its destination on the new site. This map is the backbone of the migration — it guarantees no equity gets orphaned.
3. **Rebuild with structured content.** Content moves into structured Webflow CMS collections rather than free-form pages. This is also where AEO is set up — component-level schema, structured content, crawlable rendering — during the migration, not bolted on after.
4. **301 redirects live before launch.** Every mapped URL redirects to its new home the moment the site goes live. There is no gap where a crawler or visitor hits a dead end.
5. **Launch and sitemap submission.** The new sitemap goes to Search Console at launch, so search engines start crawling the new structure immediately.
6. **Post-launch monitoring.** For the first weeks, we monitor 404s and rankings, catching any missed redirect or crawl issue while it's still trivial to fix.
For a full rebuild plus migration, plan on roughly 8–12 weeks end to end. B2B builds at this level typically run $15k–$60k depending on scope. The broader rebuild sequence is covered in [our B2B website rebuild process](/articles/b2b-website-rebuild-process).
### What improves after migrating to Webflow?
The two biggest gains are how your site gets crawled and how fast your team ships. Webflow serves pre-rendered HTML from a CDN, so AI crawlers that don't run JavaScript can read your content directly — your site stays legible to the systems increasingly answering your buyers' questions. Sitemaps, robots.txt, and llms.txt are built in rather than delegated to plugins, and structured CMS collections keep content consistent across every template.
Because AEO is configured during the migration, you launch with schema, structured content, and crawlable rendering already in place — you're not scheduling a second project to become AI-visible.
On the operational side, publishing becomes marketing-led. New pages, content updates, and campaign launches ship without a developer ticket, and the plugin-patching workstream disappears entirely. For the complete case, see [Webflow for B2B](/articles/webflow-for-b2b).
### What should be preserved in a migration?
Preserve every asset that carries your search equity: URLs, metadata, schema, internal links, and the content itself. The working checklist:
- **URLs** — kept identical where possible; 301-redirected where the structure improves.
- **Metadata** — title tags and meta descriptions carried over exactly, not rewritten in bulk during the move.
- **Schema** — existing structured data preserved and rebuilt at the component level in Webflow.
- **Internal links** — remapped to new URLs so no link resolves to a dead page.
- **Alt text** — migrated with the images it describes.
- **Content depth** — pages that rank keep their substance; consolidation is a deliberate choice, never a side effect.
A migration should change your platform, not your search footprint. Everything Google and your backlink profile point at should still resolve, still answer the same query, and still carry its metadata on day one.
If you're weighing a move, the cheapest insurance is scoping it properly before anything gets touched. BrandingLab is a B2B website and AEO studio and a Webflow Accredited partner — [book a discovery call](/contact) and we'll map your migration scope, URL inventory included, or start with [an audit of your current site](/audit).
### Frequently asked questions
#### Will I lose SEO migrating from WordPress to Webflow?
Not if the migration is run with discipline. The risk comes from execution — missing redirects, dropped metadata, broken internal links — not from the platform change itself. With every trafficked and backlinked URL mapped, 301 redirects live before launch, and metadata preserved, rankings typically recover within a few weeks; some fluctuation during re-indexing is normal.
#### How long does a WordPress to Webflow migration take?
A full rebuild plus migration typically runs 8–12 weeks, with migration and QA as its own dedicated phase rather than a task at the end. The timeline covers content inventory, URL mapping, the rebuild in structured CMS collections, redirect setup, launch, and post-launch monitoring. A migration into an existing design moves faster; the discipline stays the same.
#### Do you set up redirects?
Yes — redirects are the backbone of the migration, not an afterthought. We map every URL with traffic or backlinks, put 301 redirects live before the new site launches, submit the new sitemap to Search Console at launch, and monitor 404s and rankings through the first weeks. To scope your migration, [get in touch](/contact).
---
### Article: Sanity for AEO: The Highest Ceiling for Teams With Developers
**URL:** https://www.brandinglab.io/articles/sanity-for-aeo
**Published:** 2026-07-19
**Read time:** 5 min read
**Author:** Russel Davis, Founder, BrandingLab
**Category:** AEO
**Key takeaways:**
- Sanity is headless: it stores structured content and serves it via API, but the website itself is built with a separate frontend framework.
- Its AEO performance depends entirely on that frontend. Paired with a framework like Next.js, you get full control over server-side rendering, static generation, and incremental regeneration.
- Structured content is a genuine AEO advantage: Sanity's content model is highly structured, which makes generating clean schema and machine-readable output natural.
- The cost is that nothing is automatic. Rendering, schema, semantic structure, and sitemaps are all built and maintained by developers — there's no out-of-the-box AEO.
Sanity is a different kind of choice from Webflow, WordPress, or Wix. It's a headless CMS — it manages your content but doesn't render your website. That single fact shapes everything about its Answer Engine Optimization profile: Sanity can achieve the best AEO of any platform in this comparison, but only because (and only when) you build the front end to do it. Here's the honest picture.
For the full platform-by-platform comparison, see [the best website platform for AEO](/articles/best-website-platform-for-aeo).
### What "headless" means for AEO
In a traditional platform, content and presentation are bundled: the same system that stores your blog post also renders it as a web page. Sanity separates them. Your content lives in Sanity's structured "content lake" and is delivered through an API to whatever frontend you choose — commonly Next.js.
This matters for AEO because the frontend, not Sanity, decides how pages are rendered to crawlers. That's both the opportunity and the responsibility. There is no default Sanity website to be "good" or "bad" at AEO — there's only the site your team builds on top of it.
### Why the ceiling is so high
When you pair Sanity with a modern framework, you get access to every rendering strategy AEO could want. With Next.js, for example, you can use server-side rendering, static site generation, and incremental static regeneration — all of which deliver finished HTML that AI crawlers can read without executing JavaScript. That directly satisfies the most important AEO requirement.
Sanity's structured content model adds a second advantage. Because your content is stored as clean, typed, structured data rather than a blob of HTML, it's straightforward to map that data into precise schema markup (Organization, Article, Product, FAQ) and consistent semantic structure across every page. Structured content in, machine-readable output out — which is exactly the shape AEO rewards. Sanity also offers AI features in its editor for generating summaries and SEO metadata mapped to your keyword strategy.
### The cost: everything is a build decision
The flip side of total control is that nothing comes for free. On Sanity, every element of AEO is something your team implements: choosing and configuring the rendering strategy, writing the code that outputs schema, enforcing heading hierarchy in your components, generating sitemaps and robots.txt, and maintaining all of it as the site grows. There's no plugin to install and no visual toggle. That means Sanity only reaches its high ceiling with development resources — in-house or through an agency. For a team without them, the same flexibility that makes Sanity powerful becomes a barrier.
### Who Sanity fits for AEO
Sanity is the right AEO choice for teams that want a fully custom, developer-led build and the highest possible ceiling on performance, structure, and control. It suits organizations with engineering capacity, complex or multi-channel content needs, and a desire to own their entire stack. Teams that want strong AEO without a development commitment will be better served by a more managed platform like Webflow or modern Wix; teams wanting flexibility with a lighter lift may prefer WordPress. Sanity is the specialist's option — exceptional in the right hands.
### Frequently asked questions
#### Is Sanity good for AEO?
Sanity can deliver excellent AEO, but only through the frontend you build on it. As a headless CMS, Sanity itself doesn't render pages; paired with a framework like Next.js you get full control over server-side rendering and static generation, plus a structured content model ideal for clean schema. The trade-off is that nothing is automatic — all AEO work is implemented and maintained by developers.
#### Does a headless CMS like Sanity help or hurt AI search visibility?
It can strongly help, if implemented well. Because Sanity separates content from presentation, your frontend can use server-side rendering or static generation to deliver crawlable HTML, and the structured content model makes generating accurate schema easier. The risk is that a poorly built frontend could still render content client-side and be invisible to AI crawlers — so the outcome depends on the build.
#### Do I need developers to use Sanity for AEO?
Yes. Sanity is designed for custom, developer-led builds. Implementing the rendering strategy, schema output, semantic structure, and sitemaps all require development work, and maintaining them is ongoing. Teams without engineering resources typically get better results from a more managed platform.
#### Sanity vs Webflow for AEO — which is better?
They suit different teams. Webflow delivers strong AEO out of the box with pre-rendered HTML and built-in schema tools, ideal for marketing teams without developers. Sanity offers a higher ceiling and total control but requires developers to build and maintain everything. Choose Webflow for turnkey AEO; choose Sanity for a fully custom build with engineering support.
---
### Article: Webflow for B2B: Why B2B Companies Build on Webflow
**URL:** https://www.brandinglab.io/articles/webflow-for-b2b
**Published:** 2026-07-19
**Read time:** 5 min read
**Author:** Russel Davis, Founder, BrandingLab
**Category:** Webflow
**Key takeaways:**
- Webflow is marketing-led by design. Your team ships pages, tests messaging, and updates content without waiting on engineering.
- It's AEO-ready out of the box. Webflow serves pre-built HTML from a CDN, so your content is already visible to AI crawlers — the thing that silently breaks most modern sites.
- It's not the cheapest, and it's not for everything. Complex web apps and huge content operations still have edges where other stacks win.
- The build quality decides the outcome. Webflow gives you a strong ceiling; a sloppy build still underperforms a well-built WordPress site.
Most B2B websites fail the same way: marketing has an idea on Monday, files a ticket, and sees it live three weeks later — if the developer had capacity. The site becomes a bottleneck instead of a growth channel. Webflow exists to remove that bottleneck, and it's why a growing share of B2B companies build there. This page is the straight version: what Webflow actually gives a B2B team, where it fits, and where it doesn't.
### Why B2B teams move to Webflow
**Marketing ships without a developer in the loop.** The single biggest reason. In a B2B rebuild, the win isn't a prettier homepage — it's that your team can launch a campaign landing page, edit a case study, or reorder a section the same day. That speed compounds over a year.
**Content is visible to AI crawlers by default.** Webflow renders pages as static HTML on a global CDN. Most AI crawlers don't run JavaScript, so sites that assemble content in the browser go invisible in AI search. Webflow sidesteps that entirely — which is why it pairs naturally with [AEO for B2B](/aeo-services). Semantic HTML, metadata, sitemaps, robots.txt, and llms.txt are built in.
**Structured content, not a pile of pages.** Webflow's CMS lets you model blog posts, case studies, team bios, and product pages as structured collections with enforced fields. That structure is exactly what generates clean schema and keeps a growing B2B site consistent.
**Design control without a design system falling apart.** Marketers get visual control inside guardrails, so the site stays on-brand as it scales instead of drifting into one-off pages.
### Where Webflow fits — and where it doesn't
Webflow is a strong default for B2B marketing sites, campaign hubs, and content operations up to a few thousand items. It's *not* the right tool for a full web application, extremely large catalogs, or teams that want zero vendor involvement and total low-level control — a headless setup or WordPress may fit better. We say this plainly because pretending one platform wins everything is how clients end up on the wrong stack. For the direct trade-off, see [Webflow vs WordPress for B2B](/articles/webflow-vs-wordpress-for-b2b).
### Choosing who builds it
The platform sets the ceiling; the partner decides whether you reach it. A B2B Webflow build lives or dies on information architecture, semantic structure, CMS modeling, and AEO setup — not visual polish. If you're evaluating partners, [how to choose a B2B Webflow agency](/articles/best-webflow-partners-for-b2b) walks through what to actually check. Branding Lab is a Webflow **Accredited** studio focused on B2B; when your build is ready, [book a discovery call](/contact).
### Frequently asked questions
#### Is Webflow good for B2B websites?
Yes, for most B2B marketing sites. Webflow lets marketing teams publish and iterate without developers, serves content as crawlable HTML that's ready for SEO and AI search, and models content as structured CMS collections. It's less suited to full web applications or very large catalogs, where a headless stack or WordPress may fit better.
#### Why do B2B companies choose Webflow over WordPress?
The main reasons are speed and maintenance: marketing teams can ship and edit pages themselves without plugin management, security patching, or performance tuning, and Webflow's hosting delivers crawlable HTML by default. WordPress offers a larger ecosystem and more low-level flexibility, so the right choice depends on your team's technical capacity.
#### Is Webflow good for AEO and AI search?
Yes. Webflow serves pre-rendered HTML from a CDN, so AI crawlers — most of which don't execute JavaScript — can read your content by default. It includes semantic HTML, metadata, sitemaps, robots.txt, and llms.txt, which are the technical fundamentals AEO depends on. Getting cited still requires clear, specific content on top of that foundation.
#### How much does a B2B Webflow website cost?
It depends on scope — number of pages, CMS complexity, custom design, and whether AEO setup and migration are included. The bigger cost driver is the partner's process and whether the build is structured for search and AI visibility, not the platform fee itself. Book a discovery call for a scoped estimate.
---
### Article: B2B Webflow Agency: What We Do and How We Work
**URL:** https://www.brandinglab.io/articles/b2b-webflow-agency
**Published:** 2026-07-19
**Read time:** 6 min read
**Author:** Russel Davis, Founder, BrandingLab
**Category:** Webflow
**Key takeaways:**
- BrandingLab is a Webflow Accredited B2B website and AEO studio; typical builds run $15k–$60k depending on scope.
- A full rebuild moves through six phases — discovery, messaging, design, build, migration/QA, launch — and typically takes 8–12 weeks.
- Every build includes CMS modeling so your marketing team can publish without developers.
- AEO (component-level schema, structured CMS, llms.txt, crawlable rendering) is built in from day one, not bolted on after launch.
- Migration always includes full URL mapping and 301 redirects, so a rebuild doesn't cost you existing rankings.
- Not a fit for e-commerce, consumer apps, or budget brochure sites — the work makes sense when the website is a real revenue channel.
If you're searching for a "B2B Webflow agency", you probably don't need another portfolio to scroll through. You need to know whether an agency understands B2B specifically — long sales cycles, multiple stakeholders, content-heavy sites — and whether the site they hand over will actually be run by your marketing team, not a developer. This page explains what BrandingLab does, how we work, what it costs, and how to decide if we're a fit. For the broader case for the platform itself, start with our pillar guide to [Webflow for B2B](/articles/webflow-for-b2b).
### Who do we build for?
We build Webflow marketing sites for B2B companies — particularly B2B SaaS and technology firms whose website has to carry the weight of a considered, multi-stakeholder sale. BrandingLab is a B2B website and AEO studio founded by Russel Davis, and we're a Webflow Accredited agency. Our work spans Webflow marketing sites, brand identity and design, and AI-native or custom builds when a project calls for one.
We're also comfortable saying who we're not for. If you need an e-commerce store, a consumer app, or a five-page brochure site at the lowest possible price, we're the wrong choice — there are cheaper ways to get those. Our typical B2B Webflow builds run $15k–$60k depending on scope, and they make sense when the website is a genuine revenue channel: something your team will publish on weekly, that needs to show up in both classic search and AI answers.
One habit worth knowing about: we test our approaches on our own site before we recommend them to clients. The "lab" in the name isn't decorative.
### What do you get in a B2B Webflow build?
A complete, marketing-operable website: strategy, messaging, design, a structured Webflow build, a clean migration, and answer engine optimization built in from the start. In concrete terms, a typical engagement includes:
- **Rebuild or new build in Webflow.** Design and development of a marketing site your team can edit without touching code — the opposite of a [dev-dependent website](/articles/dev-dependent-website).
- **CMS modeling.** A structured CMS for your blog, case studies, integrations, or resource library, so publishing is a form-fill rather than a design task.
- **AEO setup from day one.** Schema at the component level, a structured CMS, an llms.txt file, and crawlable rendering — the technical groundwork for showing up in AI-generated answers as well as search results. Details on our [AEO services](/aeo-services) page.
- **Migration with full URL mapping and 301 redirects.** Every existing URL is mapped and redirected so you don't trade a new site for lost rankings.
- **Brand identity work where needed.** Some clients arrive with a solid brand; others need a refresh alongside the rebuild. We do both.
### How does the process work?
Our rebuild process runs through six phases and typically takes 8–12 weeks. The phases, in order:
1. **Discovery and strategy** — understanding your buyers, sales motion, and what the current site fails to do.
2. **Messaging and content** — the words come before the visuals. Structure and copy get agreed first.
3. **Design** — page design built on that agreed messaging, not around placeholder text.
4. **Build** — the Webflow development itself, with schema written into components as they're built rather than patched on later.
5. **Migration and QA** — content migration, full URL mapping, 301 redirects, and testing.
6. **Launch** — go-live plus handoff, so your marketing team owns the site from day one.
The 8–12 week range is typical, not universal — scope moves it in both directions. We've written up the reasoning behind each phase in our guide to the [B2B website rebuild process](/articles/b2b-website-rebuild-process).
### What work can we point to?
Recent B2B projects across SaaS, telecoms, transportation technology, and investment. A few examples:
- **Voxeon** — a B2B telecoms repositioning plus Webflow build.
- **Opsi Systems** — an enterprise transportation-technology site with AEO built in from day one.
- **Tabono** — a 20+ page Webflow site and content system for a B2B SaaS launch.
- **Protego Ventures** — a Webflow site for a defence-tech investor, built in four weeks.
- **CHRU** — a brand refresh paired with a Webflow rebuild.
Different industries, same pattern: a marketing site the client's own team runs, structured so machines can read it as easily as people.
### Why AEO-led rather than design-led?
Because a growing share of B2B buyers now get their first answers from AI tools, and a site that's merely beautiful is invisible in that channel. Design still matters — B2B buyers judge credibility partly on how a site looks — but design alone doesn't make your content citable by answer engines. That takes component-level schema, a structured CMS, an llms.txt file, and rendering that crawlers can actually read, all decided during the build. Bolting AEO onto a finished site means reworking templates that were never structured for it; building it in from day one costs almost nothing extra. If the term is new to you, our explainer on [what AEO is](/articles/what-is-aeo) covers it without the jargon.
### How do you start?
Book a discovery call — it's a conversation about your site and goals, not a pitch. [Get in touch](/contact) and we'll talk through what you have, what's broken, and whether we're the right fit; if we're not, we'll say so. If you'd rather start smaller, a [website audit](/audit) gives you a concrete read on where your current site stands before you commit to anything. You can also read more about how we work as a [Webflow agency](/webflow-agency) first.
### Frequently asked questions
#### What does a B2B Webflow agency do?
A B2B Webflow agency designs and builds marketing websites on Webflow for companies that sell to other businesses. In practice that means strategy and messaging, design, a structured CMS your marketing team can publish through without developers, and — in our case — AEO work so the site is visible in both search engines and AI answers. The B2B part matters: these sites are built for long, multi-stakeholder buying processes rather than impulse purchases.
#### How long does a B2B Webflow build take?
Typically 8–12 weeks for a full rebuild, moving through six phases: discovery and strategy, messaging and content, design, build, migration and QA, and launch. Smaller, tightly scoped projects can move faster — we built Protego Ventures' site in four weeks. Larger sites with heavy content migration sit at the longer end.
#### Do you handle migration and AEO?
Yes, both are part of the standard process rather than add-ons. Migration includes full URL mapping and 301 redirects for every existing page, so you keep the search equity you've built. AEO — component-level schema, a structured CMS, llms.txt, and crawlable rendering — is set up from day one of the build, because retrofitting it later is slower and more expensive.
---
### Article: Webflow for AEO: Advantages, Limitations, and How It Compares
**URL:** https://www.brandinglab.io/articles/webflow-for-aeo
**Published:** 2026-07-19
**Read time:** 5 min read
**Author:** Russel Davis, Founder, BrandingLab
**Category:** AEO
**Key takeaways:**
- Webflow serves content as pre-rendered HTML from a CDN, so AI crawlers that don't run JavaScript still see your content — the number-one AEO requirement, handled by default.
- The AEO fundamentals are built in: semantic HTML, editable metadata, sitemaps, robots.txt, and llms.txt, with visual control over heading structure.
- Webflow has invested heavily in AEO as a category, including an enterprise product that tracks AI citations and recommends fixes.
- The limitations are real but manageable: advanced schema can need custom embeds, the deepest tooling is gated to higher plans, and large content operations must plan around CMS limits.
If you're choosing a platform partly to get cited in ChatGPT, Perplexity, and Google's AI Overviews, Webflow is one of the few that solves the hardest AEO problem before you do anything. This is a closer look at where Webflow is strong for Answer Engine Optimization, where it isn't, and who it fits.
For the full platform-by-platform comparison, see [the best website platform for AEO](/articles/best-website-platform-for-aeo).
### Why Webflow starts ahead on AEO
The single most important technical factor in AEO is whether your content exists in the HTML a crawler receives. Most AI crawlers do not execute JavaScript, so a site that builds its content in the browser is effectively invisible to them. Webflow publishes pages as static HTML served from a global CDN. When ChatGPT's or Perplexity's crawler requests a page, the content is already there. You don't have to configure server-side rendering or add a prerender service — it's the default behavior.
That one property removes the most common reason businesses never get cited.
### The built-in AEO toolkit
Webflow includes the structural pieces AEO depends on without plugins. You get semantic HTML output, full control over title tags and meta descriptions, automatically generated XML sitemaps, editable robots.txt, and native llms.txt support — a file that gives AI systems a clean summary of your most important content. Because Webflow gives you visual control over the document structure, you can enforce a logical heading hierarchy (one H1, ordered H2s and H3s), which is exactly what answer engines use to extract and quote passages.
Webflow has also made AEO a headline focus, publishing AEO education and shipping an enterprise product that pairs analytics tracking your brand's presence in AI answers with agents that surface and help execute technical fixes.
### The limitations to plan around
Webflow isn't limitation-free. The most advanced schema scenarios — highly customized or nested JSON-LD — can require custom code embeds rather than a purely visual workflow, though common types (Organization, Article, FAQ, Product) are very manageable. The most powerful AEO analytics and agent tooling sits on higher-tier and enterprise plans, so a small business on a starter plan gets excellent fundamentals but not the full citation-tracking suite. And Webflow's CMS has item and plan limits that large, high-volume content operations need to design around.
### Who Webflow fits for AEO
Webflow is the strongest out-of-the-box option for marketing teams that want to own their site's structure and content without a developer on call. If you value design control, want the rendering and schema fundamentals handled for you, and don't need a fully custom backend, it removes most of the friction from getting AI-ready. Teams that need deep custom application logic or extremely high content volumes may find its guardrails limiting — those are cases where WordPress or a headless setup like Sanity earn a look.
### Frequently asked questions
#### Is Webflow good for AEO?
Yes. Webflow handles the most important AEO requirement automatically by serving content as pre-rendered HTML from a CDN, so AI crawlers that don't run JavaScript can still read it. It also includes semantic HTML, editable metadata, sitemaps, robots.txt, and llms.txt support, and offers enterprise tooling to track AI citations. Its main limitations are that advanced schema can require custom code and the deepest AEO tooling is on higher-tier plans.
#### Does Webflow support schema markup for AI search?
Yes. Webflow supports common schema types and gives you control over metadata and page structure. Standard types like Organization, Article, FAQ, and Product schema are straightforward, while highly customized or nested JSON-LD may require adding a custom code embed to the page or site.
#### Do I need a developer to do AEO on Webflow?
Not for the fundamentals. Webflow's visual editor lets marketers control headings, metadata, sitemaps, and common schema without code. You may want developer help for advanced custom schema or complex integrations, but the core AEO setup is achievable by a non-developer.
#### Does Webflow render content for AI crawlers by default?
Yes. Webflow serves static, pre-rendered HTML from a CDN, so the content is present in the page a crawler receives without any additional rendering configuration — unlike single-page-app platforms that require server-side rendering or prerendering to be added.
---
### Article: How to Show Up in ChatGPT and Perplexity: A B2B Playbook
**URL:** https://www.brandinglab.io/articles/how-to-show-up-in-chatgpt-and-perplexity
**Published:** 2026-07-19
**Read time:** 8 min read
**Author:** Russel Davis, Founder, BrandingLab
**Category:** AEO
**Key takeaways:**
- ChatGPT and Perplexity choose sources differently. Perplexity retrieves live pages and cites them in real time; ChatGPT leans on training data plus live browsing when it searches. You need to be readable by both.
- Getting cited is about extractability, not ranking. Lead every section with a direct, factual sentence that stands on its own — that's the unit an answer engine lifts and attributes.
- Third-party mentions matter as much as your own site. Perplexity often pulls from listicles, reviews, and comparison pages. If those don't mention you, you're invisible even with a perfect homepage.
- Rendering is a silent killer. If your content only appears after JavaScript runs, most AI crawlers see an empty shell. Serve rendered HTML.
- Schema and topical depth are the infrastructure. Structured data tells the model what you are; a cluster of related pages tells it you're authoritative on the topic.
- You can measure this today. Run your buyer queries in both engines monthly and track whether you're named — presence or absence, not a rank.
A prospect opens Perplexity and types "best B2B onboarding platforms for fintech." Three seconds later they have four vendors, a sentence on each, and a set of citation links. They click one, book a demo, and never run a Google search.
You already know the stakes — being absent from that answer is the new version of being on page two. What you probably don't have is a concrete list of what actually moves the needle. This is that list: how ChatGPT and Perplexity decide who to cite, and the specific things you can change on your site to become one of the citations.
### How ChatGPT and Perplexity actually pick sources
The two engines don't work the same way, and the difference changes what you optimize for. Perplexity is a retrieval engine: for most queries it searches the live web, reads the top results, and synthesizes an answer with citation links back to the pages it used. ChatGPT answers from its training data by default, but when it browses (or via SearchGPT) it retrieves and cites live pages much like Perplexity does.
The practical implication: to show up in Perplexity you need to be in the live results it retrieves for a query *and* be clearly extractable once it lands on your page. To show up in ChatGPT you need both a strong presence across the sources it was trained on and clean, crawlable content for when it browses. Neither engine rewards keyword density or backlink volume the way classic SEO did — they reward clarity, structure, and being mentioned in the right places. We unpack the underlying shift in [why your B2B website isn't showing up in AI search](/articles/b2b-ai-search-visibility).
### Make your pages extractable, not just readable
An answer engine cites the sentence it can lift cleanly and attribute with confidence. That means the first sentence under each heading has to work as a standalone answer — no throat-clearing, no rhetorical question, no "in today's fast-moving landscape." State the fact, then support it.
Structure the page so a model can navigate it: H2 headings phrased the way a buyer would ask the question, short paragraphs, and a clear hierarchy. A wall of marketing copy is hard to extract from; the same content reorganized with direct topic sentences becomes citable. This is the same discipline that separates the sites that get cited from the ones that don't — the difference between [AEO and traditional SEO](/articles/aeo-vs-seo).
### Get mentioned where the engines look
Your own site is only half the game. When Perplexity answers "best [category] for [market]," it frequently retrieves third-party pages — roundup listicles, review sites, comparison articles, Reddit threads — and synthesizes from those. If your company isn't named in that ecosystem, you can be absent from the answer no matter how good your homepage is.
So the work extends beyond your domain: earn placement in the "best [your category]" roundups, keep your review-site profiles current and specific, and publish comparison content that names competitors honestly. Every credible third-party mention is another source the engine can pull your name from. This is slower than editing your own pages, but it's often the missing piece when a competitor keeps appearing and you don't.
### Fix the rendering problem before anything else
If your content only exists after JavaScript executes, most AI crawlers see nothing. I learned this on our own site: I rebuilt brandinglab.io on a modern SPA stack, and within weeks our AI-search traffic vanished — the crawlers were pulling an empty hydration shell and moving on. The fix was serving a fully rendered version of each page to bots.
Before you invest in content, confirm the engines can actually read you: view your page source (not the rendered DOM) and check the real text is present in the initial HTML. If it isn't, that's the first thing to fix — everything else is wasted until the content is visible. For React and other SPA stacks, the schema and rendering patterns we ship cover exactly how to do this.
### Add the structured data that tells models what you are
Schema markup gives an answer engine a machine-readable statement of what your company is and what each page covers. At minimum: Organization schema site-wide, Product or Service schema on those pages, FAQPage schema where you answer questions, and Article schema on posts. It's the difference between a model inferring what you do and knowing it because you declared it in a format built for parsing.
Structured data won't rescue thin content, but on strong content it materially improves how confidently a model can cite and describe you. Pair it with topical depth — a cluster of related pages around each core buyer question — and you're signaling authority in the way these systems actually assess it. To gauge where you stand, run yourself through the [AEO maturity model](/articles/aeo-maturity-model).
### Measure whether it's working
There's no rank to track in AI search — you're either named in the answer or you're not. So the measurement is simple: list your ten most important buyer queries, run each one in ChatGPT and Perplexity monthly, and record whether you're cited, how you're described, and which competitors appear alongside you.
That log is your scoreboard. When a change to your site or a new third-party mention moves you into an answer you were absent from, you'll see it — and you'll know what to do more of. Continuous monitoring is also where an AEO monitoring service earns its keep, tracking presence across engines so you don't have to check by hand.
### Where this fits in the bigger picture
Most of these moves — extractable content, schema at the component level, crawlable rendering, topical clusters — are hard to bolt onto a legacy site and straightforward to build into a new one. That's why AI-search visibility is one of [the clearest signs you've outgrown your current website](/articles/six-signs-youve-outgrown-your-website), and why we treat it as a design-time decision in every [B2B website rebuild](/articles/b2b-website-rebuild-process). We did exactly this for Opsi Systems — an enterprise transportation-tech rebuild engineered for credibility and AI-search visibility from the ground up.
**Want to know where you stand in ChatGPT and Perplexity right now?** [Book a free AEO audit with BrandingLab](/audit). We'll run your buyer queries, show you who's getting cited instead of you, and map the specific changes that get you into the answer.
### Frequently asked questions
#### How do I get my company mentioned in ChatGPT?
Getting cited in ChatGPT comes down to two things: being well-represented across the sources it learns from and browses, and having content it can cleanly extract and attribute. Publish clear, entity-specific content on your own site, earn mentions in credible third-party sources (reviews, roundups, comparison pages), implement structured data, and make sure your pages render real HTML that crawlers can read. There's no way to pay for placement — it's earned through clarity, structure, and presence across the web.
#### How is showing up in Perplexity different from ChatGPT?
Perplexity retrieves live web pages for most queries and cites them in real time, so being in the fresh search results it pulls — and being extractable once it lands on your page — matters most. ChatGPT answers from training data by default and retrieves live pages when it browses, so a strong, consistent presence across the web plus crawlable content serves you in both modes. Optimizing for extractability and third-party mentions helps you in both engines.
#### What is generative engine optimization (GEO)?
Generative engine optimization is the practice of structuring your content and web presence so generative AI engines — ChatGPT, Perplexity, Google AI Overviews, Claude — find, understand, and cite you in their answers. It overlaps heavily with answer engine optimization (AEO): both prioritize entity clarity, structured data, extractable content, and topical depth over the rankings and keyword density that traditional SEO chased.
#### Why does my competitor show up in AI answers and I don't?
Usually it's one or more of four structural gaps: their content states clearly what they are and yours hedges; they have structured data and you don't; they've built topical depth and you have isolated pages; or they're mentioned in the third-party sources the engine retrieves and you aren't. AI-search visibility also compounds — sources cited early get cited more — so the gap widens the longer you wait to close it.
#### Does structured data (schema) help with AI search?
Yes. Schema markup gives AI engines a machine-readable declaration of what your company is and what each page covers, which improves how confidently they can cite and describe you. At minimum, implement Organization, Product or Service, FAQPage, and Article schema. Schema won't fix thin content, but on substantive content it meaningfully improves extractability and attribution.
#### How do I measure whether I'm visible in ChatGPT and Perplexity?
Pick your ten most important buyer queries and run each in ChatGPT and Perplexity once a month, recording whether you're named, how you're described, and which competitors appear. There's no ranking position to track — the metric is presence or absence in the answer. Watching that log over time tells you which changes move you into answers you were previously absent from.
---
### Article: Your Website Is Already a Business System. Is It Working Like One?
**URL:** https://www.brandinglab.io/articles/website-as-business-system
**Published:** 2026-07-19
**Read time:** 10 min read
**Author:** Russel Davis, Founder, BrandingLab
**Category:** Strategy
**Key takeaways:**
- The shift from marketing asset to business system is not a future trend — it has already happened. If your site has a form, a CRM integration, or any kind of content workflow, it is already part of your operations. The question is whether it was designed for that role.
- The biggest cost of a poorly structured website isn't bad design — it's the operational drag it creates. Manual follow-ups, broken automations, content that requires developer tickets: these are system failures, not marketing failures.
- Structure is the foundation. Automation is the output. Sites that handle lead routing, onboarding, and content updates automatically are built on clean content models and clear data flows — not plugins stacked on a fragile base.
- AI discoverability is now an operational requirement. If AI crawlers can't read your site, you're losing ground in the channel where a growing share of B2B buyers start their evaluation. That's a systems problem, not a content problem.
- The fix is architectural, not cosmetic. A redesign won't solve a system problem. The structural decisions — content model, data flow, automation architecture — have to come first.
### The tension
Here is what actually happens when a B2B founder submits a form on their own website.
The form goes to an email inbox. Someone on the team reads it, copies the details into a spreadsheet, manually adds the contact to the CRM, sends a follow-up from their personal email, and flags the task in Slack. Three people touched something that should have taken zero people.
Now multiply that by every form submission, every content update, every campaign launch, every onboarding email. The friction compounds quietly, week over week. Nobody notices the cumulative drag until the founder is deep in admin at 10pm and wonders why the team always feels behind.
This is not a website problem. It is a system problem. And it is almost always invisible to the people closest to it — because it was never designed at all. The site just grew.
### The reframe
The category shift happened gradually, then all at once.
For most of the last decade, B2B websites were evaluated as marketing assets: does it look credible? Does it generate leads? Does it reflect the brand? Those are still reasonable questions. But they're no longer sufficient.
A modern B2B website — whether founders realize it or not — is already embedded in operations. It touches lead qualification, client onboarding, content delivery, CRM sync, email automation, and reporting. Every interaction on the site either produces clean data that flows where it needs to go, or it produces noise that someone has to manually process.
The companies that figured this out — the ones whose websites genuinely seem to run themselves — didn't get lucky. They made an architectural decision early: to build the site as a system rather than a series of pages. That decision shapes everything downstream.
### What changes when you treat the website as a system
The practical differences are concrete.
**Lead handling.** On a system-built site, a form submission triggers an automated sequence: the contact is created in the CRM with the right tags, a notification goes to the relevant team member, a personalized follow-up email goes to the prospect, and a task is created for the next step. On a page-built site, someone's inbox gets an email and the process depends entirely on whether that person is having a good week.
**Content operations.** A system-built site has a structured CMS — clean content collections, reusable components, clear publishing workflows. Marketers update content without touching code. New pages follow established patterns. The design system enforces consistency automatically. On a page-built site, every update is a negotiation with whoever built it, and every new page is a decision about whether it's worth opening a developer ticket.
**Onboarding.** A system-built site can trigger a multi-step onboarding sequence the moment a contract is signed — welcome email, account setup, introductory resources, scheduled check-in — without anyone manually managing it. A page-built site requires a human to remember.
**Scalability.** System-built sites get easier to manage as the business grows. Page-built sites get harder. The structural decisions made at build time compound in one direction or the other.
### The proof is in the infrastructure
BrandingLab's own site illustrates this in a way that's hard to argue with.
The site was built on Lovable — a fast, clean React-based SPA. It looked good, performed well for human visitors, and represented the brand accurately. By conventional metrics, it was a solid marketing asset.
Then we started losing AI search traffic. Not gradually — noticeably. Queries we knew buyers were running in ChatGPT, Perplexity, and Google AI Overviews weren't returning BrandingLab as a result. We checked the content. It was fine. We checked the structure. That was the problem.
AI crawlers — GPTBot, ClaudeBot, PerplexityBot, Bingbot — were hitting the site and receiving an unhydrated HTML shell. The SPA only renders its content after JavaScript executes in a browser. AI crawlers don't wait for JavaScript. They crawled the shell, saw no content, and moved on. From the model's perspective, BrandingLab didn't exist.
The fix was a Cloudflare Worker that sits in front of the site and detects bot user agents. When a bot hits the site, the Worker intercepts the request, sends it to a headless Chrome instance for prerendering, and serves the fully-rendered HTML. The result is cached for seven days. Human visitors get the SPA as usual. AI crawlers get a fully readable page.
That Cloudflare Worker is not a marketing feature. It's not a design decision. It's operational infrastructure — as essential to how the business runs as the CRM or the email system. The site became a real business system the day it stopped just looking good and started actively managing how it was read by the machines that now control a significant share of B2B buyer discovery.
The lab lesson: a site can look perfect and still be operationally broken. The failure mode isn't always visible to humans.
### What to do about it
**Start with an operational audit, not a design audit.** Before worrying about aesthetics, map every touchpoint: where does data enter the site? Where does it go? What happens after a form submission? Where are the manual steps? The answers will tell you more about what needs to change than any UX review.
**Separate the content model from the design.** A well-structured CMS means content and design aren't coupled. Marketers can update content without touching layout. Developers can update components without breaking content. This is table stakes for a site that needs to evolve without constant intervention.
**Build automation on a clean foundation.** Lead routing, onboarding triggers, CRM sync — these only work reliably when the underlying data is clean and consistent. Automation on a fragile base creates more problems than it solves. Get the structure right first.
**Treat AI discoverability as infrastructure.** Structured data (schema markup), clear entity definitions on every page, and content formatted for extraction are not optional extras. They are the baseline for being visible to the systems that an increasing share of B2B buyers are using to build shortlists. If your site can't be read by a bot, it can't generate pipeline from AI search.
**Ask the operational question.** After every change, the question isn't "does this look better?" It's "does this help the business run better?" That reframe — applied consistently — is what separates a business system from a marketing asset.
### The standard worth holding
The question for B2B founders in 2026 is not "does our website look good?"
The question is: **Is our website helping the business run better?**
That question sounds simple. Most sites can't honestly answer yes — because they were never designed to. They were designed to look good, generate leads, and reflect the brand. Those are necessary conditions. They are no longer sufficient.
A site that helps the business run better handles its own data flows. It routes leads without manual intervention. It lets non-technical teams move fast. It is readable by the machines that now influence buyer discovery. It gets easier to manage as the company scales, not harder.
That's what a business system looks like. Building one is an architectural decision, not a design decision — and it starts before the first wireframe.
### Frequently asked questions
#### What is the difference between a website as a marketing asset and a website as a business system?
A marketing asset is designed to attract visitors and generate leads. A business system is designed to integrate with the operations of the company — handling data flows, triggering automations, supporting non-technical content updates, and connecting to CRM, email, and onboarding tools. Most B2B websites start as marketing assets and become business systems by accident, accumulating integrations and workflows without architectural planning. The result is fragility and debt. A site designed as a business system from the start makes intentional decisions about data model, automation architecture, and operational workflows before any design work begins.
#### Why do founder-led companies feel website system failures more acutely?
Larger organizations have operational roles — sales ops, marketing ops, RevOps — that absorb the friction from broken website systems. Founder-led companies don't. When a form breaks or a CRM sync fails, it lands on the founder's plate directly. The same structural problem creates proportionally more drag on a leaner team, which is why the decision to treat the website as a system has higher ROI for founder-led businesses than almost any other infrastructure investment.
#### Does treating a website as a business system require expensive custom development?
Not necessarily. Platforms like Webflow are purpose-built for this model: structured CMS collections, component-level design systems, automation-ready forms, and clean integrations with CRM and email tools. The investment is in architectural thinking before the build — defining the content model, mapping the data flows, planning the automation layer — rather than in custom code. Sites built with that thinking upfront tend to cost significantly less to maintain and evolve than sites rebuilt piecemeal.
#### What does AI discoverability have to do with a website being a business system?
AI search engines — ChatGPT, Perplexity, Google AI Overviews — are now a primary discovery channel for B2B buyers. These systems crawl your site and either extract citable content or don't. If your site returns an unhydrated shell to AI crawlers (common with JavaScript-heavy SPAs), or if it lacks structured data and clear entity definitions, it's invisible to AI search. That invisibility is a pipeline problem. Making your site readable and citable by AI systems is operational infrastructure — the same category as CRM integration or lead routing — because it directly affects whether buyers find you during evaluation.
#### How do I know if my site's system problems need a rebuild or can be patched?
The threshold is usually: how coupled is the current architecture? If your CMS, design system, and automation layer are cleanly separated and the issues are specific workflows or integrations, patching is often viable. If content and design are tightly coupled, if the CMS doesn't support a clean content model, or if structured data would require retrofitting hundreds of pages manually — those are architectural problems that patches don't solve. A rebuild is warranted when the cost of maintaining the current system exceeds the cost of replacing it, which on legacy sites typically happens within eighteen to twenty-four months of the first major automation attempt.
#### What should the first step be for a team that wants to move toward a website as a business system?
Start with an operational audit before touching the design. Map every touchpoint where data enters or exits the website: forms, gated content, contact pages, onboarding flows. For each one, trace where the data goes and count the manual steps involved. That map will show you exactly where the system is failing. It will also tell you whether the problems are patchable in the current architecture or require a structural rebuild — which is a much more useful starting point than a design brief.
---
### Article: Your Website Has Two Grunt Tests Now
**URL:** https://www.brandinglab.io/articles/two-grunt-tests-for-your-website
**Published:** 2026-07-19
**Read time:** 11 min read
**Author:** Russel Davis, Founder, BrandingLab
**Category:** Strategy
**Key takeaways:**
- Donald Miller's Grunt Test asks whether a first-time visitor can identify what you offer, who it helps, and how to get it in five seconds. Most B2B homepages still fail this test.
- In 2026, there is a second version of the test: AI crawlers parse your homepage in a single HTTP fetch. A site that passes for humans can be completely invisible to ChatGPT, Perplexity, and Google AI Overviews.
- The most common AI grunt test failure is JavaScript-rendered content — the crawler fetches an empty HTML shell, sees nothing useful, and moves on.
- You can diagnose this in two minutes with a single `curl` command using a bot user agent.
- The fix is a prerendering or server-side rendering layer. It's not optional if you want AI-search visibility.
- BrandingLab's own site failed the AI grunt test before we caught it. Here's exactly what that looked like and what we did about it.
### The test your homepage might be failing without knowing it
Your homepage might pass every human usability standard and still show up as a blank page to ChatGPT.
That's not a hypothetical. It's what happened to brandinglab.io — a site built intentionally, designed carefully, and completely invisible to AI crawlers until we caught it and fixed it. More on that in a moment.
First, the original grunt test. Because it still matters, and most B2B homepages still fail it.
### The human grunt test: a quick recap
Donald Miller, founder of StoryBrand, identified something about the way the brain works: it filters aggressively. Faced with information overload, it doesn't try harder — it disengages.
Miller's Grunt Test is a corrective. It says your homepage should communicate three things within five seconds of first view, without the visitor having to read carefully:
1. What does this company offer?
2. How does it benefit me?
3. How do I get it?
The name is intentional. Even someone with minimal context — someone who could only grunt their comprehension — should walk away with those three answers. If they can't, the homepage is working against you, regardless of how much you spent on the design.
The test sounds obvious. It's harder to pass than it looks, especially in B2B.
### Why B2B homepages keep failing the human version
The failure mode is consistent. A company knows their product deeply, knows the problems they solve, and writes a homepage from that vantage point. The result is usually a headline that means everything to insiders and nothing to a first-time visitor.
"Empowering teams to unlock operational excellence" is not a tagline. It's a placeholder. It tells the visitor nothing about what you do, who you do it for, or why they should stay.
In our work with B2B clients, we see three failure patterns repeatedly:
**The vague headline.** Any company in any industry could claim it. The visitor's brain registers "generic" and starts looking for the exit.
**The service list instead of a value proposition.** Eight service categories on the homepage isn't communication — it's a menu without context. Visitors don't arrive knowing which category applies to them. They need the outcome named first.
**The technically-present-but-invisible CTA.** Small, gray, below the fold, competing with four other buttons of equal visual weight. If it takes effort to find the CTA, the page has failed before the visitor gets there.
None of these are design problems. They're messaging problems that show up in the design. A visual rebrand won't fix them.
### The 2026 addition: AI crawlers run their own version
Here's where the test extends in a way that most websites haven't caught up with.
AI search tools — ChatGPT, Perplexity, Google AI Overviews, Bing's AI answers — index your site by fetching and parsing your pages. When a buyer asks "best B2B website agencies for mid-market companies," those tools pull from what they've been able to read on your site.
The problem: they fetch the page the way a browser does, but they don't execute JavaScript.
If your site is a client-rendered single-page application — React, Vue, or similar — what the crawler receives in that single fetch is the HTML shell. The actual content lives in JavaScript bundles that run after load. A human visitor never sees the problem because their browser executes the JavaScript. The crawler sees an empty `
`. It has nothing to read, so it has nothing to cite.
You can pass the human grunt test — clear headline, prominent CTA, well-designed page — and fail the AI version simultaneously. The human sees your site. The crawler sees a blank.
### How to diagnose your site in two minutes
Run this in a terminal:
```bash
curl -A "Mozilla/5.0 (compatible; GPTBot/1.0; +https://openai.com/gptbot)" https://yourdomain.com | grep -i "
` was there, waiting for JavaScript to fill it in. The headline, the value proposition, the service descriptions, the CTAs — all of it lived in JavaScript bundles that the AI crawler never executed. To every bot that fetched the page without running JavaScript, our homepage was empty.
It was a clean case of passing the human grunt test and failing the AI one.
The fix was a Cloudflare Worker deployed in front of the site. The Worker inspects the incoming user agent on every request. If the request comes from a known bot — GPTBot, ClaudeBot, Bingbot, Perplexity's crawler, and a list of others — the Worker intercepts it and routes the request to a headless Chrome prerender service. The prerender executes the JavaScript, waits for the content to load, and returns the fully-rendered HTML to the crawler. Human visitors get the React app as before. Bots get the prerendered HTML with real content.
The result: AI crawlers can now parse everything on the page. The implementation took less than a day and required no changes to the frontend codebase.
This is the same class of fix available to any JavaScript-heavy site. It's not a full rebuild. It's a routing layer that gives crawlers what they need without changing what humans see.
### What to do about it
**Step 1: Run the human grunt test.** Open your homepage. Give yourself five seconds — no scrolling. Close your eyes. Answer: What does this company do? Who does it help? What should I do next? If any of those is unclear, the messaging needs work before anything else.
**Step 2: Run the AI grunt test.** Use the curl command above against your own site. If the output is an empty shell, you have an AI visibility problem regardless of how well the human version passes.
**Step 3: Fix the human version at the messaging layer.** Rewrite the headline to name what you do and who it's for, plainly. Make the CTA the most visible element in the first viewport. Cut anything on the homepage that doesn't directly serve the visitor's decision in the first five seconds.
**Step 4: Fix the AI version with a rendering layer.** For client-rendered JavaScript applications, the options are server-side rendering (rendering content on the server before sending HTML), static site generation (pre-building HTML at deploy time), or dynamic prerendering (a middleware layer like the Cloudflare Worker approach above). Which is right depends on your stack. The point is that one of them needs to be in place.
**Step 5: Verify, then re-verify.** After implementing fixes, run both tests again. The curl diagnostic should return meaningful content. A human running the five-second test should be able to answer all three questions cleanly.
### The original principle still holds
Donald Miller's insight from 2014 hasn't aged. The brain still filters. Visitors still arrive with limited attention and no prior context about your company. Clarity in the first five seconds still determines whether they stay.
What's changed is that websites now have a second audience with different constraints. AI crawlers don't scroll, don't execute JavaScript, and don't give you multiple chances. They fetch once. What they see in that fetch is what they use to decide whether you exist in their index.
Running both versions of the grunt test is now part of basic website maintenance. Neither is optional.
### Frequently Asked Questions
#### What is the Grunt Test?
The Grunt Test is a website clarity framework from Donald Miller (StoryBrand). It says a first-time visitor should be able to identify — within five seconds, without reading carefully — what a company offers, who it helps, and how to get it. If those three questions can't be answered quickly, the homepage needs to be simplified.
#### Who created the Grunt Test?
Donald Miller, founder of StoryBrand and author of *Building a StoryBrand*, developed the Grunt Test as part of his framework for simplifying brand messaging. The name reflects the idea that even a minimal amount of cognitive engagement should be enough to grasp the core message.
#### Why do most B2B websites fail the Grunt Test?
Because they're written by people who know the company too well. Insiders assume visitors share their context, which they don't. The result is headlines that mean something internally and nothing externally, service lists instead of clear value propositions, and CTAs that are technically present but visually buried.
#### What is the AI grunt test?
The AI grunt test is a term we use to describe whether AI crawlers — the systems that feed ChatGPT, Perplexity, Google AI Overviews, and similar tools — can parse meaningful content from your homepage in a single HTTP fetch. If your site requires JavaScript to render its content, crawlers that don't execute JavaScript may see an empty HTML shell. A site that passes the human grunt test can still fail the AI version.
#### How do I check if AI crawlers can read my homepage?
Run a curl request against your homepage using a bot user agent: `curl -A "Mozilla/5.0 (compatible; GPTBot/1.0)" https://yourdomain.com`. If the output contains your headline and core content, you're likely fine. If it returns an empty shell or a bare HTML frame, AI crawlers are seeing the same thing.
#### What causes a site to fail the AI grunt test?
The most common cause is a JavaScript-rendered single-page application (SPA) where the meaningful page content lives in JavaScript bundles rather than the initial HTML. AI crawlers that don't execute JavaScript fetch the shell and see nothing useful. This is standard behavior for React, Vue, and Angular applications that aren't configured with server-side rendering or a prerendering layer.
#### How do you fix an AI grunt test failure?
There are three main approaches: server-side rendering (the server generates complete HTML on each request), static site generation (complete HTML is built at deploy time), or dynamic prerendering (a middleware layer detects bot user agents and serves pre-rendered HTML to crawlers while serving the JavaScript app to human visitors). The Cloudflare Worker approach is an example of dynamic prerendering — it requires no changes to the frontend and can be implemented in less than a day.
#### Can a website pass the human grunt test and fail the AI version simultaneously?
Yes. That's exactly what happened with brandinglab.io. The site was well-designed, messaging was clear, and human visitors had no trouble navigating it. But because it was a React application without a prerendering layer, AI crawlers received an empty HTML shell. The human test passed. The AI test failed. Both needed to be addressed.
#### Does the human grunt test still matter if AI search is taking over?
Yes. Human visitors still arrive with limited attention and no prior context about your company. The five-second test for humans is as valid as it was when Miller introduced it. What's changed is that it's no longer the only test your site needs to pass. AI crawlers have their own version with different constraints, and both need to be addressed.
#### What's the fastest way to run the Grunt Test on my homepage?
For the human version: open your homepage, look at it for five seconds without scrolling, then close your eyes and try to answer the three questions from memory. For the AI version: run the curl command against your homepage with a bot user agent and check whether meaningful content comes back. Both tests take less than five minutes combined and tell you immediately where to focus.
---
### Article: AI Overview Optimisation: What B2B Marketers Need to Know
**URL:** https://www.brandinglab.io/articles/ai-overview-optimization-for-b2b
**Published:** 2026-07-19
**Read time:** 7 min read
**Author:** Russel Davis, Founder, BrandingLab
**Category:** AEO
**Key takeaways:**
- AI Overviews are Gemini-generated answers at the top of Google results, now live in over 200 countries and 40+ languages. They appear mostly on informational, question-style queries — exactly the queries B2B buyers use early in research.
- When an AI Overview appears, organic clicks fall. Independent CTR studies consistently measure steep position-one declines on queries with an Overview present; simple definitional queries lose the most.
- Being cited in the Overview recovers a meaningful share of those clicks. The brands named inside the answer keep visibility that uncited page-one rankings no longer get.
- Google selects passages, not just pages. Query fan-out breaks a question into sub-queries and pulls the clearest extractable answer for each — so a well-structured section can be cited even when the page isn't the #1 result.
- Third-party surfaces matter. Reddit threads, LinkedIn posts, review sites, and industry roundups are among the most-cited domains in AI answers; your own site is only half the game.
- The fix is the AEO playbook, not a new discipline. Extractable first sentences, question-phrased headings, schema markup, and topical clusters serve AI Overviews, ChatGPT, and Perplexity alike.
Open Google Search Console for almost any B2B site and you'll see the same chart: impressions climbing, clicks flat or falling. Your content is showing up more than ever — inside an AI-written answer the searcher never clicks past.
That's Google AI Overviews at work, and for B2B marketers it changes the job. The goal is no longer just ranking on page one; it's being one of the sources the answer is built from. Here's how AI Overviews actually work, what they do to your traffic, and what to change.
### What are Google AI Overviews and how do they work?
AI Overviews are AI-generated summaries that Google places above the traditional results, built with its Gemini models and linked to the sources they draw from. Launched in the US in May 2024, they have since rolled out to more than 200 countries and over 40 languages, and they sit alongside AI Mode — Google's separate, chat-style search experience.
Under the hood, Google uses a technique it calls query fan-out: a complex question is broken into multiple sub-questions, each is searched in parallel, and the results are synthesized into one answer with citations. The practical consequence for marketers is that Google is selecting *passages*, not just ranking pages — the clearest standalone answer to each sub-question is what gets lifted, wherever it lives.
### Do AI Overviews reduce clicks to my website?
Yes — on queries where an AI Overview appears, organic click-through rates drop sharply, and every major independent study points the same direction. Position-one results lose a large share of their expected clicks when an Overview sits above them, because a meaningful slice of searchers gets the answer without clicking anything.
The damage isn't evenly spread. Definitional and "what is X" queries lose the most — the Overview simply answers them. How-to and process queries hold up better, because readers still click through for depth. And the brands *cited inside* the Overview retain visibility and clicks that uncited rankings no longer get. That's the real takeaway: the penalty isn't for AI Overviews existing, it's for being absent from them. We covered why absence happens — and how it compounds — in [why your B2B website isn't showing up in AI search](/articles/b2b-ai-search-visibility).
### How does Google choose which sources AI Overviews cite?
Google cites sources that its ranking systems already trust *and* that offer a cleanly extractable answer to one of the fan-out sub-questions. Strong rankings still help — they keep you in the candidate pool — but they no longer guarantee citation, and pages outside the top results get cited when a specific passage answers a sub-question better than anything above it.
Two other patterns matter for B2B. First, entity consistency: Google cross-references how your brand is described across the web, so a site that states plainly what the company is — and matches how third parties describe it — is easier to cite with confidence. Second, third-party surfaces punch above their weight: Reddit, LinkedIn, review platforms, and "best of" roundups are among the most-cited domains in AI answers. If your category's roundups and comparison threads don't mention you, an Overview about your category can be built entirely without you.
### How do I optimize my B2B content for AI Overviews?
Optimizing for AI Overviews means making every section of a page work as a liftable, attributable answer. The moves, in priority order:
1. **Phrase H2s the way buyers ask questions,** and make the first sentence under each heading a direct, standalone answer. That sentence is the unit Google extracts.
2. **Answer the sub-questions, not just the head term.** Query fan-out means a page that covers the follow-up questions — pricing factors, timelines, comparisons, risks — gives Google more passages to cite.
3. **Add schema markup** — Organization site-wide, Article on posts, FAQPage where you answer questions — so the models know what you are instead of inferring it.
4. **Build topical clusters.** A pillar page plus supporting articles that interlink signals the topical depth these systems read as authority. Gauge where you stand with the [AEO maturity model](/articles/aeo-maturity-model).
5. **Earn the third-party mentions.** Get into the category roundups, keep review profiles current, and show up where practitioners actually discuss your space.
6. **Make sure crawlers can read you.** If your content only renders after JavaScript, much of this is invisible to the systems doing the citing — the schema and rendering patterns for React SPAs cover the fix.
### Does traditional SEO still matter for AI Overviews?
Traditional SEO still matters — it determines whether you're in the candidate pool Google synthesizes from — but it stopped being sufficient. Crawlability, indexation, site quality, and rankings remain the foundation; what's changed is that the last mile is now extractability and entity clarity rather than squeezing out one more position.
That's the practical difference between classic SEO and answer engine optimization, and we've mapped it in detail in [AEO vs SEO](/articles/aeo-vs-seo). The good news: nothing you do for AI Overviews is wasted elsewhere. The same structure that gets you cited by Google gets you cited by ChatGPT and Perplexity — the playbook for those engines is in [how to show up in ChatGPT and Perplexity](/articles/how-to-show-up-in-chatgpt-and-perplexity).
### Where AI Overviews fit in your AI-search strategy
Treat AI Overviews as one surface in a single AI-search program, not a separate project. One monthly log answers most strategy questions: run your ten most important buyer queries in Google, ChatGPT, and Perplexity; record whether an AI answer appears, whether you're cited, and who is cited instead. Presence or absence — that's the metric.
Most of what gets you cited — extractable copy, schema, clusters, clean rendering — is hard to retrofit and straightforward to build in from the start, which is why AI-search visibility is one of the [six signs you've outgrown your current website](/articles/six-signs-youve-outgrown-your-website) and a design-time decision in every [B2B website rebuild](/articles/b2b-website-rebuild-process) we run.
**Want to know whether AI Overviews are citing you or your competitors?** [Book a free AEO audit with BrandingLab](/audit) — we'll run your buyer queries, show you who's in the answers, and map the changes that get you cited.
### Frequently asked questions
#### What are Google AI Overviews?
AI Overviews are AI-generated answers that Google displays above the traditional search results, built with its Gemini models and linked to the sources they draw from. They launched in the US in May 2024 and are now available in more than 200 countries and over 40 languages. They appear most often on informational, question-style queries.
#### How do AI Overviews affect organic traffic for B2B websites?
Queries that trigger an AI Overview send fewer clicks to organic results, with independent studies consistently measuring steep position-one CTR declines. Definitional queries lose the most clicks, while how-to and process content holds up better. Brands cited inside the Overview retain significantly more visibility than those ranking beneath it uncited.
#### How do I get my content cited in an AI Overview?
Structure each section as a liftable answer: a question-phrased heading followed by a direct first sentence that stands alone. Support it with schema markup, a topical cluster of related pages, consistent entity descriptions across the web, and mentions on the third-party surfaces Google cites, such as review sites and category roundups. Rankings keep you in the candidate pool; extractability gets you cited.
#### Is AI Overview optimization different from AEO?
No — optimizing for AI Overviews is answer engine optimization applied to Google's answer surface. The same fundamentals (extractable answers, structured data, topical depth, entity clarity, crawlable rendering) drive citations in AI Overviews, ChatGPT, and Perplexity. Treating them as one program avoids duplicated effort.
#### What is AI Mode and how is it different from AI Overviews?
AI Mode is Google's separate, conversational search experience — a chat-style surface powered by Gemini — while AI Overviews are summaries placed on the standard results page. Both use query fan-out and cite sources, so content optimized for one tends to surface in the other. B2B marketers should monitor their buyer queries in both.
#### Do AI Overviews appear on B2B search queries?
Yes — AI Overviews trigger heavily on the informational and question-style queries B2B buyers use during early research, such as definitions, comparisons, and process questions. Branded and late-stage transactional queries trigger them less often. That makes top- and mid-funnel content the priority for AI Overview optimization.
---
### Article: Webflow vs WordPress for B2B (Which One to Build On)
**URL:** https://www.brandinglab.io/articles/webflow-vs-wordpress-for-b2b
**Published:** 2026-07-19
**Read time:** 7 min read
**Author:** Russel Davis, Founder, BrandingLab
**Category:** Webflow
**Key takeaways:**
- Both Webflow and WordPress serve crawlable HTML by default, so both can be AEO-ready — rendering is not the dividing line.
- Webflow fits marketing-led teams: publish without developers, low maintenance, pre-rendered static HTML from a CDN.
- WordPress fits developer-led teams: deeper schema and SEO tooling via plugins, but you own patching, security, and performance.
- The real decision is team technical capacity and how often marketing needs to ship — not a blanket platform winner.
- Cost differs in shape, not just size: Webflow trades platform fees for less maintenance labor; WordPress trades cheaper software for ongoing upkeep. Typical B2B Webflow builds run $15k–$60k over 8–12 weeks.
- Migrating WordPress to Webflow is routine if you map URLs and set 301 redirects to preserve SEO equity.
Webflow vs WordPress is rarely a question of which platform is technically superior. Both can produce a fast, crawlable, AI-search-ready B2B website. The real question is which one your team can run well — the platform that wins on paper loses in practice if nobody maintains it. This guide compares the two on rendering and AEO readiness, maintenance burden, team fit, content modeling, and cost of ownership, with a verdict framed by team type rather than a blanket winner.
### What is Webflow best at for B2B?
Webflow is best at letting marketing teams ship and iterate on a B2B site without waiting on developers. Pages are served as pre-rendered static HTML from a CDN, which means AI crawlers that don't execute JavaScript can read your content by default — no rendering workarounds required. Semantic HTML, metadata, sitemaps, robots.txt, and llms.txt are handled in the platform rather than bolted on.
For content operations, Webflow's structured CMS collections give you clean content modeling — resources, case studies, integrations pages — that marketers manage directly. The trade-offs are real: CMS item limits can pinch large content operations, and advanced schema markup sometimes requires custom embeds rather than a native control. We cover the platform in depth in our [Webflow for B2B guide](/articles/webflow-for-b2b).
### What is WordPress best at for B2B?
WordPress is best at flexibility and ecosystem depth for teams with engineering capacity. It server-renders PHP into crawlable HTML by default, so — like Webflow — AI and search crawlers see real content without executing JavaScript. Rendering is not the dividing line between these platforms.
Where WordPress pulls ahead is the plugin ecosystem. SEO and schema tooling like Rank Math, Yoast, and AIOSEO covers 20+ schema types, llms.txt support, and even AI-citation tracking — capabilities that go beyond what Webflow offers natively. Content modeling is effectively unlimited if you build custom post types, and there's no hard item ceiling. The trade-off is that all of this depends on plugins, and plugins mean ongoing responsibility: security patching, compatibility testing, performance tuning, and general maintenance land on your team.
### How do Webflow and WordPress compare side by side?
The honest comparison is a set of trade-offs, not a scoreboard. Here is how the two platforms differ on the dimensions B2B buyers actually weigh:
| Dimension | Webflow | WordPress |
|---|---|---|
| Rendering & AI crawlability | Pre-rendered static HTML from a CDN; readable by non-JS crawlers by default | Server-rendered PHP → crawlable HTML by default |
| AEO/SEO tooling | Built-in semantic HTML, metadata, sitemaps, robots.txt, llms.txt | Plugin-based (Rank Math, Yoast, AIOSEO): 20+ schema types, llms.txt, AI-citation tracking |
| Schema depth | Solid basics; advanced schema can need custom embeds | Deepest schema coverage via plugins |
| Maintenance | Platform-managed; low ongoing burden | Your responsibility: patching, security, performance tuning |
| Team fit | Marketing-led teams publish without developers | Developer-led teams who can own the stack |
| Content modeling | Structured CMS collections; item limits on large content ops | Effectively unlimited with custom development |
| Cost model | Higher platform fees, lower ongoing labor | Lower software cost, higher maintenance labor |
### When should you choose Webflow?
Choose Webflow if marketing owns the website and needs to ship without a developer queue. That pattern fits most B2B marketing sites: frequent landing pages, messaging tests, a content library managed by the people who write it.
Choose Webflow if:
- Your marketing team publishes and iterates often, and developer time is scarce or expensive
- You want maintenance, hosting, and security handled by the platform
- Your content model fits structured collections and stays within CMS item limits
- You'd rather pay platform fees than staff ongoing site maintenance
Typical B2B Webflow builds run $15k–$60k and take 8–12 weeks, depending on scope. If you're weighing a partner for the build, see our guide to choosing a [B2B Webflow agency](/articles/b2b-webflow-agency).
### When should you choose WordPress?
Choose WordPress if you have a capable technical team and requirements that exceed what a hosted platform allows. This is not a consolation prize — for the right team, WordPress is the stronger choice, and we say so even though we ship mostly Webflow.
Choose WordPress if:
- You have developers (in-house or retained) who will own patching, performance, and security
- You need deep schema coverage or SEO tooling beyond Webflow's native features
- Your content operation is large enough that CMS item limits become a real constraint
- You need custom functionality the plugin ecosystem already solves
The condition is non-negotiable, though: WordPress's advantages only materialize if someone maintains it. An unmaintained WordPress site accumulates security exposure and performance debt that no plugin fixes.
### Which should a mid-market B2B company build on?
For most mid-market B2B companies, the deciding factor is team capacity, not platform capability. If marketing leads the website and engineering time is scarce, Webflow's lower maintenance burden and marketer-friendly publishing usually win. If you have a developer-led web team with real ownership capacity, WordPress can match Webflow on AEO — its rendering is crawlable by default, and its plugin ecosystem arguably goes further on schema. Both platforms produce content AI search engines can read; what differs is who does the work to keep it that way. (New to answer engine optimization? Start with [what AEO is and why it matters](/articles/what-is-aeo).)
BrandingLab is a B2B website and AEO studio, and a Webflow Accredited agency — we ship mostly Webflow for B2B marketing sites, but the honest verdict depends on your team, and we'll tell you when WordPress is the better fit. If you're deciding which platform to build on, [book a discovery call](/contact) and we'll scope it with you.
### Frequently asked questions
#### Is Webflow or WordPress better for B2B?
Neither is better across the board — the answer depends on your team. Webflow suits marketing-led teams that need to publish without developers and want low maintenance; WordPress suits developer-led teams that can own patching, performance, and security in exchange for deeper flexibility. Both serve crawlable HTML, so both can be AEO-ready.
#### Is WordPress better for SEO than Webflow?
WordPress has deeper SEO tooling through plugins — Rank Math, Yoast, and AIOSEO cover 20+ schema types, llms.txt support, and AI-citation tracking. Webflow covers the fundamentals natively: semantic HTML, metadata, sitemaps, robots.txt, and llms.txt, with pre-rendered static HTML that non-JavaScript crawlers read by default. In practice, execution and content quality decide rankings more than the platform; either can compete when run well.
#### Which is cheaper long-term?
It depends on where your costs sit. Webflow carries platform fees but offloads hosting, security, and maintenance, which lowers ongoing labor. WordPress software costs less up front, but you carry plugin management, security patching, and performance tuning — costs that show up as staff or agency time rather than a subscription line. For context, B2B Webflow builds typically run $15k–$60k over 8–12 weeks.
#### Can you migrate WordPress to Webflow?
Yes, and it's a common move for B2B marketing teams. The discipline that protects your SEO equity is thorough URL mapping with 301 redirects, so existing rankings and backlinks carry over to the new site. We walk through the full process in our [WordPress to Webflow migration guide](/articles/wordpress-to-webflow-migration).
---
### Article: The Best Website Platform for AEO: Webflow vs WordPress vs Wix vs Vibe-Code vs Sanity
**URL:** https://www.brandinglab.io/articles/best-website-platform-for-aeo
**Published:** 2026-07-19
**Read time:** 10 min read
**Author:** Russel Davis, Founder, BrandingLab
**Category:** AEO
**Key takeaways:**
- AEO is decided at the platform level, not bolted on later. The three things AI engines need most — content delivered as readable HTML, structured data (schema), and clean semantic structure — are either built into your platform or they're a fight.
- The single biggest technical dividing line is rendering. Most AI crawlers do not run JavaScript. If your pages only assemble their content in the visitor's browser, AI engines see a blank shell. Server-side rendering (SSR), static generation, or prerendering is non-negotiable.
- No platform makes you invisible forever, and none guarantees citations. The platform sets your ceiling and your effort level. A well-configured WordPress or Wix site can outperform a badly built Webflow one.
- Match the platform to your team. Webflow and Wix favor marketing teams who want control without developers. WordPress offers flexibility with maintenance overhead. Sanity offers total control but needs developers. Vibe-code tools are fast to launch but need a rendering fix before they're AEO-ready.
Buyers have quietly changed how they find companies. Instead of scrolling a page of blue links, they ask ChatGPT, Perplexity, or Google's AI Overviews a question and get a short, synthesized answer with two or three recommended options. If your business is named in that answer, you're on the shortlist. If it isn't, you're invisible — and you may never know it happened.
That shift is what Answer Engine Optimization (AEO) is about: structuring your website so AI answer engines can find, understand, and cite it. And here's the part most people underestimate: your ability to do AEO well is largely decided by the platform your website is built on. Some platforms hand you most of what AEO needs by default. Others actively work against it unless you bring in a developer to fix the foundation.
This guide compares the five platforms businesses most often weigh — Webflow, WordPress, Wix, vibe-code tools (like Lovable, Bolt, and v0), and Sanity — through one lens: how well each one lets you get cited in AI answers.
### What AI answer engines actually need
Before comparing platforms, it helps to know what you're optimizing for. AEO is different from traditional SEO. SEO tried to rank a page higher on a list. AEO tries to get your content quoted inside a direct answer. The signals that matter shift accordingly, and four of them are technical enough that your platform choice affects each one.
**Content that lives in the HTML.** AI crawlers from ChatGPT, Perplexity, Claude, and Google read the HTML your server returns. Research from crawler studies has repeatedly found that most AI crawlers do not execute JavaScript. If your content only appears after the browser runs scripts, those crawlers see an empty page. This is the make-or-break factor, and it's entirely a function of how your platform renders pages.
**Structured data (schema markup).** Schema is machine-readable code (usually JSON-LD) that explicitly tells an engine what your content is: an organization, a product, an FAQ, an article, a review. Pages with clean schema get cited more often because the engine doesn't have to guess. Every platform handles schema differently — some generate it automatically, some need a plugin, some need custom code.
**Semantic HTML and clear structure.** Pages that use a logical heading hierarchy (one H1, then H2s and H3s) and lead each section with a direct, factual statement are easier for a model to extract and quote. Analyses of cited pages find they score meaningfully better on heading structure than uncited ones.
**Crawler access signals.** A correct robots.txt that doesn't block AI bots, an XML sitemap, and increasingly an llms.txt file (a clean summary of your key content for AI systems) all help engines find and prioritize your pages.
With that framework, here's how the platforms stack up.
### The comparison at a glance
| Platform | Content in HTML by default? | Built-in schema | Native AI-citation tracking | Best for | Main limitation |
| --- | --- | --- | --- | --- | --- |
| Webflow | Yes (static hosting on CDN) | Semantic HTML, metadata, llms.txt, sitemaps built in; visual control | Yes, on enterprise plans | Marketing teams wanting design + AEO control without developers | Advanced schema can need custom embeds; higher-tier AEO tooling is gated |
| WordPress | Yes (server-rendered) | Via plugins (Rank Math, Yoast, AIOSEO) — 20+ schema types | Via plugins (AI traffic tracking) | Teams wanting flexibility, ownership, and a large ecosystem | Plugin dependency, maintenance, security, and performance overhead |
| Wix | Yes on newer Wix Studio (SSR); older sites weaker | Structured Data Manager (LocalBusiness, Product, FAQ, Review) + custom JSON-LD | Yes (AI Visibility tool) | Small businesses wanting an all-in-one builder | Less low-level control; SSR strongest only on newer Studio sites |
| Vibe-code (Lovable, Bolt, v0) | No by default (single-page apps) — needs SSR/prerender | Only what you or the AI add manually | Rarely built in | Rapid prototyping and launching an app fast | Default output is often invisible to AI crawlers until rendering is fixed |
| Sanity (headless) | Depends entirely on your frontend (excellent with Next.js) | You implement it — total control | You build it | Custom builds where developers want full control | Nothing works out of the box; requires developers to build and maintain |
### Webflow
Webflow serves pages as pre-built HTML from a global CDN, so your content is already in the HTML when a crawler arrives — the rendering problem is solved by default. It bakes in semantic HTML, SEO metadata, sitemaps, robots.txt, and llms.txt, and gives marketers visual control over structure without touching code. Webflow has also leaned hard into AEO as a category, launching an enterprise product that tracks brand citations in AI answers and recommends technical fixes.
The tradeoffs: the most advanced schema scenarios can still require custom code embeds, the deepest AEO tooling sits on higher-tier and enterprise plans, and there are CMS limits to plan around on larger content operations. For a marketing team that wants strong AEO fundamentals without a developer on call, it's one of the most turnkey options. [Read the Webflow deep dive.](/articles/webflow-for-aeo)
### WordPress
WordPress renders pages on the server, so content arrives as crawlable HTML — the fundamentals are sound out of the box. Its real strength is the ecosystem: plugins like Rank Math, Yoast, and AIOSEO now offer 20+ schema types, site-wide structured-data maps, llms.txt support, and even AI-citation tracking. With the right configuration, WordPress can match almost any platform on AEO.
The cost is responsibility. That flexibility comes with plugin dependency, security patching, performance tuning, and the risk of bloat from poorly built themes and plugins. WordPress rewards teams that either have technical capacity or are willing to maintain the stack. [Read the WordPress deep dive.](/articles/wordpress-for-aeo)
### Wix
Wix has changed a lot. For years it was criticized for client-side rendering that hurt SEO, but its newer Wix Studio platform rolled out server-side rendering that resolves those JavaScript issues, and new Studio sites now score well on technical SEO out of the box. Its Structured Data Manager lets you add LocalBusiness, Product, FAQ, and Review schema without code, plus custom JSON-LD, and it offers an AI Visibility tool to track LLM mentions.
The caveats: the strongest rendering and schema tooling is concentrated in newer Studio sites rather than older Wix builds, and you trade some low-level control for the all-in-one convenience. For small businesses that want a single tool and don't need deep customization, modern Wix is a legitimate AEO option — a real change from its reputation. [Read the Wix deep dive.](/articles/wix-for-aeo)
### Vibe-code platforms (Lovable, Bolt, v0)
AI app builders let you describe a site and get a working one in minutes. The catch for AEO is rendering. By default these tools produce single-page applications (SPAs) that assemble content in the browser with JavaScript — which means an AI crawler that doesn't run JavaScript sees an empty shell. Studies have found these sites frequently invisible to AI engines until the rendering is fixed.
The picture is improving: Lovable, for example, now uses server-side rendering for new apps and prerendering for verified crawlers on older ones. But behavior varies by tool and by when your app was built, and the fix (adding SSR or a prerender service) is on you. Vibe-code tools are excellent for speed; treat AEO-readiness as a deliberate step, not an assumption. [Read the vibe-code deep dive.](/articles/vibe-code-platforms-for-aeo)
### Sanity
Sanity is a headless CMS: it manages your content but doesn't render your website. That means its AEO performance depends entirely on the frontend you pair it with. Paired with a framework like Next.js, you get full access to server-side rendering, static generation, and incremental regeneration — everything AEO needs — plus a highly structured content model that's ideal for generating clean schema and machine-readable output.
The flip side: nothing is automatic. Every piece of AEO — rendering strategy, schema, semantic structure, sitemaps — is something your developers implement and maintain. Sanity offers the highest ceiling of any option here, but only teams with development resources can reach it. [Read the Sanity deep dive.](/articles/sanity-for-aeo)
### So which platform is best for AEO?
There's no single winner, because the right answer depends on who's maintaining the site. The honest framing is this:
- **If you want strong AEO with minimal technical lift**, Webflow gets you the furthest out of the box, with modern Wix Studio a strong option for smaller businesses.
- **If you want flexibility and an ecosystem and can handle upkeep**, WordPress with a capable SEO plugin can compete with anything.
- **If you have developers and want maximum control**, Sanity paired with a modern framework offers the highest ceiling.
- **If you built on a vibe-code tool**, you can absolutely make it AEO-ready — but confirm how it renders and fix that first.
The biggest mistake isn't picking the "wrong" platform. It's assuming AEO happens automatically. On every platform, getting cited in AI answers takes deliberate setup — and on some, it takes fixing the foundation before you can start.
### Frequently asked questions
#### What is the best website platform for AEO?
There is no universal best platform; the right choice depends on your team's technical capacity. Webflow offers the strongest out-of-the-box AEO fundamentals for marketing teams, WordPress offers the most flexibility for teams comfortable with maintenance, and Sanity paired with a framework like Next.js offers the highest ceiling for teams with developers. What matters most is that the platform delivers content as server-rendered HTML, supports structured data (schema), and lets you control heading structure — and that you actually configure those things.
#### Does the website platform really affect AI search visibility?
Yes, significantly. The most important AEO factor is whether your content is present in the HTML that AI crawlers receive, because most AI crawlers do not execute JavaScript. Platforms that render pages on the server or serve static HTML (Webflow, WordPress, modern Wix Studio, or a headless setup like Sanity with Next.js) make content visible by default. Platforms that render content in the browser — such as default single-page apps from many vibe-code tools — can leave AI engines seeing a blank page until rendering is fixed.
#### Why can't AI crawlers see JavaScript-rendered websites?
Most AI crawlers fetch the raw HTML your server returns and do not run JavaScript the way a human browser does. If a page assembles its content in the browser after the initial load (client-side rendering), the crawler receives a near-empty HTML shell and cannot read the content. This is why server-side rendering, static site generation, or prerendering for crawlers is essential for AEO.
#### Is Wix good for AEO in 2026?
Modern Wix is far better than its old reputation. Newer Wix Studio sites use server-side rendering, resolving the JavaScript issues that historically hurt Wix on search, and include a Structured Data Manager for schema and an AI Visibility tool for tracking LLM mentions. The strongest capabilities are concentrated in the newer Studio platform rather than older Wix sites, so the specifics of your build matter.
#### Can a vibe-code website (Lovable, Bolt, v0) be optimized for AEO?
Yes, but usually not by default. These tools often produce single-page applications that AI crawlers can't read until server-side rendering or a prerendering service is added. Some, like Lovable, have introduced SSR for new apps and prerendering for verified crawlers. If you build on a vibe-code tool, verify how it renders content to crawlers and add a rendering solution before expecting AI citations.
---
### Article: WordPress for AEO: Flexibility, Plugins, and the Maintenance Trade-Off
**URL:** https://www.brandinglab.io/articles/wordpress-for-aeo
**Published:** 2026-07-19
**Read time:** 5 min read
**Author:** Russel Davis, Founder, BrandingLab
**Category:** AEO
**Key takeaways:**
- WordPress renders pages on the server, so your content arrives as crawlable HTML by default — the core AEO requirement is met.
- The plugin ecosystem is its superpower for AEO: Rank Math, Yoast, and AIOSEO now offer 20+ schema types, site-wide structured-data maps, llms.txt support, and AI-citation tracking.
- The trade-off is responsibility: plugin dependency, security patching, performance tuning, and the risk of bloat all fall on you or your team.
- WordPress rewards technical capacity. With a capable team it can match nearly any platform; without one, it can quietly underperform.
WordPress powers a huge share of the web, and with the right configuration it can hold its own on Answer Engine Optimization — getting cited in ChatGPT, Perplexity, and Google's AI Overviews. The catch is that WordPress gives you the pieces but leaves the assembly and upkeep to you. Here's an honest look at where it's strong for AEO and where the work lives.
For the full platform-by-platform comparison, see [the best website platform for AEO](/articles/best-website-platform-for-aeo).
### Why WordPress meets the AEO fundamentals
WordPress generates pages on the server (rendered from PHP), which means the content is present in the HTML a crawler receives. That matters because most AI crawlers don't execute JavaScript — and WordPress doesn't depend on the browser to assemble content. So unlike a default single-page app, a standard WordPress site is readable by AI engines from the start. The foundation is sound before you install anything.
### The plugin ecosystem is the real advantage
Where WordPress pulls ahead is the depth of its SEO and AEO tooling. Modern plugins have moved aggressively into the AI-search era:
- **Rank Math** offers a visual schema builder with 20+ schema types in its free tier, added llms.txt support to help AI crawlers understand site structure, and an AI search traffic tracker that shows which content AI engines cite.
- **Yoast SEO** takes a standards-focused approach and introduced a Schema Aggregation feature that builds a site-wide structured-data map AI agents can use to understand your whole domain; its schema output is among the most standards-compliant available.
- **AIOSEO** consolidates on-page and technical SEO in one workflow and scales cost-effectively across many sites, which suits agencies and multi-site teams.
With one of these configured well, WordPress can output clean JSON-LD, enforce good structure, manage sitemaps and redirects, and give you visibility into AI citations — a genuinely complete AEO stack.
### The trade-off: everything is your responsibility
The flexibility that makes WordPress powerful is also its cost. You're responsible for keeping the core, theme, and plugins updated and secure. Performance depends heavily on your hosting, theme quality, and how many plugins you stack — poorly built themes and plugin bloat are a common cause of slow sites, which hurts both users and crawlers. Plugin dependency also means a key feature can change, break, or move behind a paywall. None of this is disqualifying, but it means AEO on WordPress is an ongoing operational commitment, not a set-and-forget setup.
### Who WordPress fits for AEO
WordPress is a strong AEO choice for teams that want maximum flexibility and ownership and either have technical capacity in-house or are comfortable maintaining the stack (or paying someone to). If you want a large ecosystem, full control over your content model, and no vendor lock-in, it's hard to beat. Teams that want AEO handled with minimal upkeep may prefer a more managed platform like Webflow or modern Wix, while teams wanting a fully custom, developer-led build may lean toward a headless setup like Sanity.
### Frequently asked questions
#### Is WordPress good for AEO?
Yes, with the right setup. WordPress renders content on the server so it's readable by AI crawlers by default, and plugins like Rank Math, Yoast, and AIOSEO provide extensive schema, llms.txt support, and AI-citation tracking. The trade-off is that WordPress requires ongoing maintenance, security updates, and performance management, so it performs best for teams with technical capacity.
#### Which WordPress plugin is best for AEO?
Rank Math, Yoast SEO, and AIOSEO are the leading options in 2026. Rank Math offers the most schema types in its free tier plus llms.txt support and AI-traffic tracking; Yoast is known for standards-compliant schema and a site-wide Schema Aggregation map; AIOSEO scales cost-effectively across multiple sites. The best choice depends on your budget, number of sites, and how much hand-holding you want.
#### Does WordPress render content for AI crawlers by default?
Yes. WordPress generates pages on the server, so content is present in the HTML a crawler receives without extra rendering configuration. This is a key advantage over default single-page-app platforms that require server-side rendering or prerendering to be visible to AI engines.
#### What is the downside of using WordPress for AEO?
The main downside is operational overhead. You are responsible for security updates, plugin maintenance, and performance, and poorly chosen themes or too many plugins can slow the site and hurt both user experience and crawlability. WordPress gives you all the AEO capabilities but expects you to assemble and maintain them.
---
### Article: Vibe-Code Platforms for AEO: Lovable, Bolt, and v0 vs AI Crawlers
**URL:** https://www.brandinglab.io/articles/vibe-code-platforms-for-aeo
**Published:** 2026-07-19
**Read time:** 5 min read
**Author:** Russel Davis, Founder, BrandingLab
**Category:** AEO
**Key takeaways:**
- Vibe-code tools often ship single-page applications (SPAs) that assemble content in the browser with JavaScript.
- Most AI crawlers don't execute JavaScript, so they receive a near-empty HTML shell — meaning your content can't be read or cited.
- The fix is a rendering change: server-side rendering (SSR) or a prerendering service that returns finished HTML to crawlers.
- The landscape is improving. Lovable, for example, now uses SSR for new apps and prerendering for verified crawlers — but behavior varies by tool and by when your app was built, so verify rather than assume.
AI app builders — often called vibe-code platforms — like Lovable, Bolt, and v0 let you describe a website and get a working one in minutes. They're remarkable for speed. But for Answer Engine Optimization, they carry a specific risk that catches many people off guard: the default output can be effectively invisible to AI search engines. Here's what's going on and how to fix it.
For the full platform-by-platform comparison, see [the best website platform for AEO](/articles/best-website-platform-for-aeo).
### Why vibe-code sites struggle with AEO
The problem is rendering, not content quality. By default, many vibe-code tools generate single-page applications built with frameworks like React. In an SPA, the server sends a minimal HTML shell and the browser runs JavaScript to build the actual page. A human visitor never notices. An AI crawler does — because most AI crawlers fetch the raw HTML and do not run JavaScript.
The result: when ChatGPT, Perplexity, or Claude's crawler requests your page, it can see an almost empty document. Independent testing has repeatedly found vibe-coded sites invisible to AI engines for exactly this reason, and studies note that search engines take far longer to index JavaScript-heavy pages even when they can eventually render them. For AEO — where the whole game is being present in the answer — an unreadable page is a non-starter.
### The good news: it's fixable, and improving
This is a solvable problem, and the platforms are moving. Lovable is a clear example: newer apps use a framework with server-side rendering built in, and for older apps it serves prerendered HTML to verified crawlers — including Google, Bing, and AI engines like ChatGPT, Perplexity, Claude, and Gemini. That means a Lovable site built or updated recently may already be far more AEO-ready than the blanket "SPAs are invisible" warning suggests.
But this varies significantly by tool and by when your project was created. Other builders may still default to client-side rendering with no crawler handling. So the rule is simple: don't assume, verify.
### How to make a vibe-code site AEO-ready
The path depends on the tool, but the options are consistent:
- **Check how your site renders to crawlers first.** View the raw HTML a crawler would receive (for example, by fetching the page without JavaScript) and confirm your actual content — headings, body text — is present, not just an empty shell.
- **Use server-side rendering if the tool supports it.** SSR is the most robust fix because every visitor and crawler gets finished HTML. Some platforms now offer this natively.
- **Add a prerendering service** if you can't move to SSR. Prerendering detects crawlers and serves them a fully rendered HTML snapshot, while human users still get the app experience.
- **Then layer on the usual AEO work**: schema markup, clean heading hierarchy, sitemaps, robots.txt that allows AI bots, and llms.txt — none of which help if the content isn't in the HTML in the first place.
### Who vibe-code tools fit for AEO
Vibe-code platforms are excellent for speed — prototypes, internal tools, and getting a product in front of users fast. If AI-search visibility matters for the site, treat AEO-readiness as an explicit step in the build, not a default you inherit. For a site whose main job is to be found and cited, you'll either want a tool that renders server-side out of the box or a plan to add SSR or prerendering before launch.
### Frequently asked questions
#### Are vibe-code websites bad for AEO?
Not inherently, but by default many are. Vibe-code tools like Bolt and v0 often generate single-page applications that assemble content in the browser with JavaScript, which most AI crawlers can't read — leaving the site invisible to AI answer engines. This is fixable with server-side rendering or a prerendering service, and some tools now handle it automatically.
#### Can Lovable sites show up in AI search?
Yes, increasingly. Lovable now uses server-side rendering for new apps and serves prerendered HTML to verified crawlers — including ChatGPT, Perplexity, Claude, and Gemini — for older apps. A recently built or updated Lovable site can be AEO-ready, but you should still verify that your content appears in the HTML crawlers receive.
#### How do I fix AEO on a vibe-code site?
Start by checking whether your content appears in the raw HTML a crawler receives without JavaScript. If it doesn't, add server-side rendering (the most robust fix) or a prerendering service that returns finished HTML to crawlers. Then add schema markup, a clean heading structure, sitemaps, and an llms.txt file.
#### Why can't ChatGPT see my vibe-code website?
Most likely because the site is a single-page application that builds its content with JavaScript in the browser. ChatGPT's crawler fetches raw HTML and does not run JavaScript, so it receives an empty shell instead of your content. Adding server-side rendering or prerendering for crawlers resolves this.
---
### Article: B2B Brand Identity for AI Search: Building a Citable Brand
**URL:** https://www.brandinglab.io/articles/b2b-brand-identity-for-ai-search
**Published:** 2026-07-08
**Read time:** 9 min read
**Author:** Russel Shalom Davis, Founder, BrandingLab
**Category:** AEO
**Key takeaways:**
- AI engines cite brands as entities, not keywords — your brand needs a machine-readable identity.
- Schema.org (Organization, Person, sameAs) is how you tell AI models who you are and what you do.
- Consistent naming, descriptions and category positioning across the open web train the models.
- Visual identity still matters, but for AI visibility, structured data does the heavy lifting.
- The B2B brands winning in AI search treat entity-building as a first-class marketing discipline.
Brand identity used to end at a logo, a colour palette and a tone-of-voice guide. In an AI-mediated internet, that is no longer enough. When a buyer asks ChatGPT "who are the best B2B web agencies for AI-native brands?", the model does not look at your Figma files. It looks at whether it recognises your company as a distinct **entity** — and whether the open web agrees on who you are and what you do.
This is the shift from brand-as-visuals to **brand-as-entity**. It is the single most important brand strategy question for B2B teams in 2026.
### Why AI engines think in entities
Large language models don't index pages the way Google's classic crawler did. They compress the web into a statistical map of entities and the relationships between them. An entity is anything with a stable identity — a company, a person, a product, a place, a concept.
When Perplexity or ChatGPT answers a buying question, they retrieve passages from sources they can attribute to a **known entity**. If your brand isn't in that map, you don't get cited — no matter how good your website is.
### The three layers of a citable brand identity
#### 1. Structured data on your own site
Schema.org markup is how you introduce your brand to machines. At minimum, every B2B site should ship:
- An `Organization` (or `ProfessionalService`) schema on the homepage, with `name`, `url`, `logo`, `description`, `sameAs`, `founder`, `areaServed` and `knowsAbout`.
- A `Person` schema for each founder or key expert, linked via `@id` from the organization.
- A `WebSite` schema with a `SearchAction` so the site is machine-readable as a corpus.
The `sameAs` array is the bridge — it points the model at your LinkedIn, Crunchbase, GitHub, Clutch and any authoritative third-party profiles. This is how models resolve "BrandingLab" the string to BrandingLab the entity.
#### 2. Consistent identity across the open web
Models learn who you are from the sources they trained on. That means every mention of your brand should agree on the basics: the same legal name, the same category, the same founder story, the same city. Discrepancies confuse the model and dilute the entity.
Audit your Crunchbase, LinkedIn, Clutch, G2, Wikipedia (if applicable), and personal author bios. If your homepage says "B2B website and AEO studio" but Crunchbase says "digital marketing agency", the model doesn't know which one you are.
#### 3. Content that reinforces the entity
Every article you publish should either:
- Reinforce **what you do** (the services, methods, frameworks you own), or
- Reinforce **who you are** (the founder's expertise, the company's point of view).
Long-form content with clear author attribution, dates and headings trains the models to associate topics with your brand. Thin, generic content trains them to ignore you.
### Frequently asked questions
#### How is brand identity different for AI search vs traditional SEO?
Traditional SEO optimised for keyword-to-URL matching. AI search optimises for entity-to-answer matching. Your brand needs to be a recognisable entity before any of its pages can be cited.
#### Does visual identity still matter?
Yes — for humans. Logo, typography and design still drive conversion once someone lands on your site. But visual identity is invisible to LLMs; structured data is what makes you visible to them.
#### What's the fastest way to become a citable brand?
Ship comprehensive Organization and Person schema, align your top five third-party profiles (LinkedIn, Crunchbase, Clutch, G2, personal bios), and publish two or three long-form articles per month that reinforce your category and expertise.
#### How long does it take to appear in AI answers?
Most brands see initial citations within 60–120 days of shipping proper schema and aligned third-party profiles. Consistent publishing accelerates it.
### The takeaway
If you want to be recommended by ChatGPT, Perplexity and Google AI Overviews, your brand has to be a **thing the models recognise** — not just a website they can crawl. Structured data, aligned third-party profiles and expertise-rich content are the new brand identity system for B2B.
---
### Article: From Months to Seconds: Building Gazette-Search for the Collections Industry
**URL:** https://www.brandinglab.io/articles/gazette-search-case-study
**Published:** 2026-07-05
**Read time:** 19 min read
**Author:** Shalom Petersen, Founder, BrandingLab
**Category:** Case Study
**Key takeaways:**
- The 5-minute-per-search bar in South African collections was a bar a pre-AI small team had already failed to clear. A one-person shop with Claude cleared it — the unlock is a small operator shipping at a quality bar that used to require a team.
- A dashboard that said 0.3% gazette coverage was measuring the wrong thing. Write down every metric on every dashboard and what it is actually measuring — before you need to trust it in a crisis.
- When the product was defective, the right move was to absorb the cost of the fix, not pass it back to the user. 507 quiet retroactive watchlists beat one bulk "we're sorry" email.
- Subscriptions are for founders who haven't yet learned what they don't know about their pricing. Credits plus Enterprise — usage-based for the long tail, contract-based for the head — is what most B2B products want to be eventually.
- The most expensive bugs in a B2B product live at the seams between systems nobody owns: platform scratch space meeting a growing database, a cloud sync product meeting Git internals, a PDF parser meeting scanned pages.
## From Months to Seconds: Building Gazette-Search for the Collections Industry
The 5-minute challenge, the Lovable-to-Claude pivot, the data crisis we found, the customer-ethics call I'm proudest of, and who's using it now.
An associate of mine in the collections space had been watching me work on a concept. I showed him the prototype one afternoon, with the kind of energy you only have for the first SaaS you've ever built. His response, paraphrased close to verbatim:
"Unless you can get search results in under 5 minutes, my industry isn't interested. We've already tried to build something like this — with a developer, before AI — and it was a mess."
That's the inciting incident for this whole project. Not a market research deck. Not a competitive analysis. One industry insider, sitting across the table, setting a clear bar and quietly letting me know what had already failed.
It's also why this case study is worth your time if you run a collections agency, a BPO, or a financial-services team in South Africa. Because the bar that associate set wasn't just met. It was lapped. And the story of how a one-person shop got from "interesting demo" to "30-year credit management firm on a 3-month professional contract" runs through every interesting infrastructure problem a B2B SaaS can have.
Pull up a chair.
### Why <5 minutes is the bar that matters in collections
Large collection agencies and BPOs in South Africa run hundreds of thousands of searches per month against the Government Gazette. They're verifying deceased estates. Insolvencies. Liquidations. Sales in execution. Name changes. Every ID they don't clear is a case they can't close, a fee they can't bill, a recovery that doesn't ship.
Turnaround time isn't a feature for this segment. It's the entire product.
The manual baseline is unspeakable. Searches on government sites take hours, days, and sometimes months. The official government source is technically online but locked behind a corporate authentication layer that rejects anything other than a live browser session — useless for any kind of programmatic search at scale. The most popular community-built mirror, which most previous attempts had been built against, had started returning broken files for parts of the archive. The legally-clean public archive of historical issues was authoritative and complete, but frozen at 2021. Every existing access path was broken in a different way.
For due-diligence work, a false "nothing found" is not a cosmetic problem. It's a real one — with legal and financial consequences a search engine isn't supposed to be responsible for. A lawyer who closes an estate without finding an unfiled insolvency notice ends up in a courtroom six months later answering questions about due diligence they thought they'd done. A collections analyst who clears an ID against a stale dataset puts a recovery into a queue that should never have been opened.
That's the problem space. The associate had clocked it. So had everyone else in his industry. None of them had a working tool for it.
### The first build, the Lovable wall, the move to Claude
One developer (me). One repo. A pragmatic web stack. The kind of stack you ship in, not the kind you put on a slide. I'm a designer who learned to ship — not a career backend engineer.
I started in Lovable.
Lovable is excellent for what it's excellent for. Fast UI iteration. Opinionated full-stack scaffolding. The kind of platform that gets a working web app standing in an afternoon. If you've never used it and you're building a marketing site, a dashboard, or a structured CRUD application, it's a serious tool.
None of those strengths were the problem this product had to solve.
The challenge wasn't "ship a search interface." It was: return matches against a database of millions of rows, fast enough that a collections analyst doesn't notice the wait — sub-second in the happy path, in a tool a user might run a thousand times in a shift. That requires query design and index strategy and the kind of repo-wide refactoring an SPA builder isn't designed for. I battled to get the system to return results in time. Not Lovable's fault. The wrong tool for the layer of the build I was on.
So I switched to Claude.
Claude understood the goal. Not in a marketing sense — in the practical sense of being able to hold the whole codebase in mind. Walking me through database queries I'd designed without thinking hard enough about how they'd be searched. Finding why a specific search was slow and rebuilding the index that fixed it. The engineering decisions stayed mine. The speed of working through them changed completely.
Hundreds of prompts later — over several months of iteration — we had a system returning matches in seconds. Against a 2GB database. From a single web instance. For a use case where the manual alternative takes hours, days, sometimes months. The 5-minute bar wasn't met. It was lapped.
This is what working with an AI assistant looks like in 2026, in my experience. The AI doesn't replace engineering judgment, and it doesn't write your architecture for you. It removes the cost of moving across unfamiliar territory. The bar an associate gave me was a bar a pre-AI small team had already failed to clear. A one-person shop with Claude cleared it. That isn't "AI builds it for you." It's "a small operator can punch above their weight class."
I keep coming back to that distinction because it's the actual unlock — for me, and for every client build I do at BrandingLab. If you've ever been quoted six months for a build that should take six weeks because the agency is staffing five people on it, you've felt the inverse of this principle.
### The day the data started lying
Six months into running the product, I caught a pattern I'd been missing.
Roughly 29.6% of the historical searches we'd served had been silently coming back empty — not because the IDs weren't in the gazettes, but because the gazettes themselves had never been read correctly on our side. Lawyers had searched for IDs and gotten "nothing found" on cases that were actually there. For due-diligence work, that's not a quality issue. That's a defective product.
The first place this showed up was a dashboard that said we had "0.3% gazette coverage" — which almost made me panic before I realised the metric was lying to me. The 0.3% was the share of total rows in the database that were gazettes, not the share of gazettes we'd processed. Each gazette spawns hundreds of child notices, so gazettes are always going to be a small slice of the row count by design. The real problem was buried one layer down, in a different table, where I hadn't been looking.
I almost trusted the dashboard. I have written down, since, every metric on every dashboard I run, and what it is actually measuring. That's a habit I owe to a near-miss on a Thursday morning.
The why was less mysterious than the what. The historical data source we'd been pulling from had become unreliable — returning broken or substituted files for parts of the archive. On top of that, the PDF parsing library we used couldn't read scanned image-based PDFs at all, and a meaningful slice of the older legal gazettes are scanned image-based PDFs. The two failure modes overlapped, and the result was a real data gap nobody on our side had noticed.
The fix was honest work. I investigated every alternative source — official, community, archival, commercial — and most were broken in some way. One legally-clean public archive of historical issues was authoritative and complete, just frozen at 2021. I migrated all historical backfill to that source and rebuilt the missing data. For everything from 2022 onward, the platform now runs a weekly fetch against the official source — matched to the Gazette's own publication rhythm (52 issues a year). Data stays current without manual intervention.
So the archive that was 29.6% empty six months ago is now both backfilled to completeness and kept current automatically. The next time we have a data-quality issue, it'll be a new one, not the old one.
That's not a flex. That's how compounding investment in infrastructure actually works.
### Five times the platform fought us
Even with the application returning matches in seconds, the question of how we kept the data fresh nearly took us down. Five separate times. All while the live product was serving paying users.
First try. I ran the data-recovery work inside the same machine that served search traffic. The recovery pegged the CPU. The health check (which was, in retrospect, running a heavy database query — never do this) failed. The cloud platform interpreted the failed health check as a dead service and restarted the whole instance every 60 seconds. The recovery job never completed. The site flickered for an hour while users tried to search and got intermittent errors. The lesson: never put a database query in your health check. I now write this down on a sticky note before every new project.
Second try. I made the health check stop doing database queries. Moved the recovery work into a low-priority background process on the same machine. Hit the memory ceiling instead — the recovery job got killed silently every time, even after I upgraded the machine to 5GB of RAM. The old legal gazettes are giant scanned PDFs and parsing them eats memory in ways no documentation warns you about, and the machine was also serving live search traffic in the background, and the kernel just kept choosing the recovery process to sacrifice.
Third try. I tried to move the recovery work to a completely separate machine, sharing the database file with the live service. Turned out the cloud platform attaches a database disk to exactly one machine at a time. The architectural path I was on was closed by a platform constraint I should have read about a month earlier. The lesson: sometimes the platform is the boundary, not your code. The mental model you have of "I can just spin up another worker" assumes a degree of decoupling between compute and storage that doesn't actually exist on most managed platforms.
The resolution. I took the recovery off the cloud platform entirely. Downloaded the production database to my Mac, ran the recovery work locally where there were no users to disturb and no platform limits to fight, then shipped the fixed database back to production through two new admin endpoints I built specifically for the purpose. Took an evening to wire up. Took a weekend to actually run the recovery. Took a long while to talk myself into the fact that the right move was off-platform after I'd spent so long trying to make on-platform work.
The kicker. After the recovered 2.6GB database went live, the whole site started failing every request with a 502 error. Searches returned what looked like JSON to the browser but was actually HTML. The cloud platform's working scratch space had a hard 2GB ceiling. My database had just grown past it. Every time the service booted, it got evicted within 90 seconds, and the cycle repeated. I moved the database off the scratch space onto persistent storage, resized that persistent storage from 2GB to 10GB, and the platform finally stopped fighting me.
The line I keep repeating to myself, and now to clients:
It wasn't memory. It wasn't health checks. It was disk space. The CPU and RAM I'd been blaming were a red herring.
None of this was about search latency. Sub-second search was already solved at the application layer. The five attempts above are the story of keeping that capability alive every time we needed to refresh the data underneath it. Operating a SaaS is mostly the second story, not the first. The first one ends the day you ship the feature; the second one continues for as long as anyone is using it.
### A bug from outside the system
One of the worst bugs in the entire project wasn't on the cloud platform at all. It was on my own laptop.
The folder I'd put the source code in was being silently synced by a cloud drive product running in the background. Every time I tried to save a change in the source-control system, the sync would write a file in the middle of the lock mechanism, and the save would silently fail. The first hint was that commits were failing on push. The second hint was that the commits had never actually completed locally. The third hint was a stack overflow thread three pages down that mentioned the same product by name.
I spent more hours on this than I want to put in writing before I noticed.
Moved the folder. Solved.
The lesson: sometimes the bug is in a product you weren't even thinking about. The harder a bug is to reproduce, the more likely it's a system you didn't know was touching your system. I now keep a written list of every background-running product on every machine I develop on, just so I have a place to start when a bug refuses to make sense.
### The customer-ethics call
This is the moment I'm proudest of in the whole project. It's also the moment that probably tells you the most about how I'd handle a client build, so it's worth slowing down for.
The data crisis meant real users had searched for real IDs and gotten "nothing found" — when the gazette had been there the whole time. For collections agencies and lawyers running due diligence, that's not a service issue. It's a defective product they had paid us for and trusted.
The expected SaaS move was obvious. Email everyone. Announce the dataset is now improved. Tell them to re-search. They'd pay for the re-searches. We'd technically be in the clear.
I didn't do that.
Instead, I went through every historical "nothing found" search in the system and quietly created a free retroactive watchlist for each one. 507 of the 728 historically failed searches were identifier-based and matchable against the recovered dataset. When a watchlist entry matches, the user gets an automatic alert at no cost, forever. They never have to know there was a problem. They just get the answer they originally needed, when it became findable.
A bulk announcement would have re-opened the trust question. ("Wait — your data was wrong? For how long? What else?") A quiet retroactive watchlist alert, framed as a notification the user signed up for, simply delivers the value they were trying to buy in the first place. No "we apologise" email. No "please re-search at no charge" prompt that turns a defect into a marketing moment. Just the answer they came for.
The principle:
When the product was defective, the right move was to absorb the cost of the fix, not pass it back to the user.
I've been quietly running that test on every operational decision since. It would have been cheap to do the bulk announcement and pocket the upsell. It would also have been the kind of decision I'd be embarrassed to write down in a case study like this one. The fact that you can read about it here without me cringing is, in a small way, the actual proof that it was the right call.
### A lawyer and a BPO walk into the same SaaS
This is the title of an act, not the start of a joke. The structural tension Gazette-Search has had to live with from day one is the pricing tension between two completely different ends of the same market.
A lawyer running a single estate-due-diligence search on one ID has the potential to surface billable work worth tens of thousands of rand. That one search is worth R35 to them all day, every day — it replaces a manual gazette check that costs R500-plus and takes months.
An enterprise BPO running hundreds of thousands of searches a month against a recovery book cannot pay R35 per search. The unit economics of debt collection do not survive it.
Same query. Two ends of the market. A several-hundred-thousand-fold volume gap. Completely different economic value per search.
My first instinct was wrong. I started with what every SaaS founder starts with: subscription tiers. Three plans at R1,500 / R4,000 / R6,000 a month. It looked sensible on a pricing page. It fit neither persona. The lawyer who runs three searches a year shouldn't be paying R1,500 a month. The BPO running hundreds of thousands of searches a month wasn't going to fit inside a R6,000 ceiling without the spreadsheet starting to argue. The model penalised both ends and only worked for a narrow middle that didn't really exist.
The current model is credits plus Enterprise.
Credit packs. Eight tiers, R35 a search at the single end down to R0.55 at the 200,000-credit Volume end — a 64× per-credit compression across the volume curve. Pay for what you use. Credits valid 12 months from purchase. The lawyer buys one credit for R35 — or a 100-credit Starter pack at R10 a search — and never thinks about a subscription. The BPO buys the 200,000-credit Volume pack at R0.55 a credit (or steps up to Enterprise), and the per-search cost survives their unit economics. Monthly buyers put any pack on auto-refill and save 10%. Both ends pay a price that matches the value the search is actually delivering to them.
Enterprise. From R250,000 for 500,000-plus credits, custom MSA. Banks, bureaus, continuous monthly screening — the segment where contracts and SLAs matter more than per-credit pricing.
I'll be honest about what's still in transition. I migrated off the subscription model to credit packs earlier in 2026. The pricing config and every customer-facing page shipped clean. A few of the payment-processor-dependent pieces — the business-verification gate for the bigger packs, the monthly add-ons, auto-refill recurring billing — are still partially shipped. Some pages still advertise things that aren't billable yet. I'm fine telling you that, because honesty about what's not yet shipped is part of what this case study is.
The lesson, the kind I'm going to keep repeating to clients:
Subscriptions are for SaaS founders who haven't yet learned what they don't know about their pricing. Credits-plus-Enterprise is what most B2B products want to be eventually — usage-based pricing for the long tail, contract-based pricing for the head of the curve, and the discipline to stop pretending one model fits both.
If you've ever sat across the table from a buyer and watched them do the arithmetic on a tier that doesn't fit their actual usage, you know how much commercial damage a bad pricing structure does. The damage is silent because the buyer doesn't tell you they're rounding you down to "too expensive." They just don't come back.
### Who's using it now
I held off writing this section until the rest of the case study was solid, because traction without a built product to back it up is just a slide deck. Here's where it is today.
The anchor customer is a 30-year-old South African credit management firm on a 3-month professional contract. The kind of business that has been doing due-diligence work the manual way for three decades — and decided to test the seconds-not-hours version on a paying contract. They're not named in this article. The point isn't who they are; the point is the kind of customer they are.
A large BPO is in commercial discussions with us for an Enterprise contract right now — the right end of the pricing curve described above. Specifics are confidential while we're in negotiation.
A handful of other businesses and solo practitioners are running the free demo tier. Some will convert when their first batch of credits runs out and they take a clean look at what they got for it.
What this means for the reader: the 5-minute bar an associate set in the opening paragraph is operational at customer scale. The pricing model is not a thought experiment. It's billing real businesses for real searches at the per-credit prices specified.
That's enough. I don't want to over-sell what's still a young product.
### The breach runbook, built before the breach (and not yet drilled)
South African data-protection law gives a company 72 hours from discovering a breach to notify both the data-protection regulator and every affected user. Most SaaS startups don't think about that until incident one.
I built the response runbook first. Five phases — Identification, Containment, Assessment, Notification, Post-mortem. Each phase has the actual database queries, command-line steps, and decision rules you would run while the 72-hour clock is on. Not theatre. Operational steps.
The supporting infrastructure is deployed. A structured audit log of every admin action. A notifications table that proves which user got told what, and when. A "preview" admin endpoint that dry-runs the affected-users list and the exact email body before anything sends, so the IC can read every word before any user does. A "notify" endpoint that paces the actual sends to stay inside the email provider's rate limits. The code is in production. The endpoints respond.
Why build all of this cold. A runbook you write under stress is a runbook with mistakes in it. Writing it cold meant I could think about edge cases I'd never think of mid-incident — like what to do if email itself is the compromised channel (fall back to LinkedIn messages and a notice on the public site).
Here's what I haven't done — and what it's quietly taught me about my own operational discipline. I have never run a drill against the runbook. The runbook itself opens with a line that says "Last drill: never." I keep telling myself I'll do one next quarter. Compliance infrastructure is the kind of thing that's easy to leave alone until you can't anymore — until an incident lands and you find out, in real time, which parts of your runbook actually work and which parts you wrote for a version of the code that has since changed.
The honest version:
Built it cold. That was the right call. Haven't kept it warm since. That's the next call.
I think that's a better closing line than the alternative version of this section, where I'd have told you confidently that the runbook is "battle-tested." The truthful version is more useful — to me, to anyone reading this who's also let a piece of compliance infrastructure go un-drilled too long, and to any prospect of mine who'd want to know what kind of person they're hiring to build their own infrastructure.
### Where it goes from here
A roadmap with no overpromising attached.
The database migration. The infrastructure war story above is the story of one specific decision — keeping the database on the same machine as the web service. Moving to a managed database (and running data refresh as a fully isolated scheduled job) is the version where the five attempts in Act 4 never repeat themselves. Costed at roughly $45–$105 a month all in. Next major architectural project.
International expansion — Sub-Saharan first. Most Sub-Saharan African countries — Zimbabwe, Nigeria, and others — use the same Government Gazette structure as South Africa. The same core search engine works against any of them with minimal change. Sub-Saharan rollout is the active next data project, and it's commercially significant for collection agencies and BPOs with cross-border recovery work — which is the segment Gazette-Search was already built for. UK gazette scaffolding sitting in the repo was the original proof that the architecture generalises; the Sub-Saharan rollout is what's actually next.
Image-based PDFs. The scanned PDFs that yielded nothing earlier would yield real text under an OCR pass. That's a quality-of-corpus win sitting right in the backlog and the cleanest path to closing the long tail of historical gaps.
Pricing model still in transition. The subscription-to-credit-packs migration is mostly shipped. A few payment-processor-dependent pieces — the verification gate, the monthly add-ons, auto-refill billing — are still pending.
No "we're disrupting the industry" close. Just honest sequencing.
### What this taught me about how BrandingLab works
Three lessons. Each one shows up in every client build I do, and each one is here because the Gazette-Search build is where I actually learned it.
1. Infrastructure debt compounds quietly, at the seams. Every problem in this build was where two systems met. The cloud platform's working storage meeting a growing database. A cloud file-sync product meeting source-control internals. A PDF parser meeting scanned image-based pages. The lesson isn't "test more." It's: look for the seams between systems and assume there's a hairline crack you haven't found yet. The most expensive bugs in a B2B product are never in one component. They're at the interface between two components nobody owns.
2. The default option is not always the right option. The most popular data source for what I was doing was fine until it wasn't. The official government source was correct but unreachable. A quieter, legally-clean archive — the one nobody talks about — was the one that worked. The same principle holds for every client build I do at BrandingLab. The popular CMS, the standard hosting choice, the obvious stack are correct most of the time and quietly wrong in the cases that matter. The work is knowing which case you're in, and being honest with the client when the obvious answer isn't the right one.
3. AI assistants don't replace engineering judgment. They remove the cost of moving across unfamiliar territory — and they let one-person shops compete with teams. I made every architectural call myself. Claude made it possible for me to make them across hundreds of prompts and several months of iteration, instead of the years it would have taken solo and pre-AI. The associate's 5-minute bar was a bar a pre-AI small team had already failed to clear ("it was a mess"). A one-person shop with Claude cleared it. That's the actual unlock — not "AI builds the product for you," but "a small operator can ship at a quality bar that used to require a team."
This is what "B2B website and AI studio" means in practice at BrandingLab. I don't just build websites for clients. I run my own SaaS and feel every infrastructure call before I bring it to a client build.
If you're a collections agency, a BPO, or a financial-services team running gazette searches — and you want to see what seconds-not-hours looks like inside your actual workflow — book a demo of Gazette-Search. The demo is real data against the live system, not a sandbox.
If you're a B2B team with a project that doesn't fit a normal agency mould — including the kind of build where the only honest answer is "I'll prototype it on my own SaaS first" — talk to BrandingLab.
A runbook you write under stress is a runbook with mistakes in it. I've been trying to write everything cold ever since.
— Shalom
---
### Article: The Real Cost of a Dev-Dependent Website (And What Marketing-Led Looks Like)
**URL:** https://www.brandinglab.io/articles/dev-dependent-website
**Published:** 2026-06-16
**Read time:** 9 min read
**Author:** BrandingLab, Editorial
**Category:** Strategy
**Key takeaways:**
- The real cost isn't slow turnaround — it's the experiments that never happen. When every change needs a developer, marketing stops testing new messaging, building campaign pages, and iterating on conversion. You lose the data you never collect.
- Dev-dependency makes AEO impossible — and that's now a rebuild-level problem. Answer Engine Optimization requires content velocity, structured data on every page, and rapidly published content clusters. None of that happens when every change needs a developer. In 2026, a site that can't support AEO is a site that's losing ground in AI search every week.
- Dev-dependency isn't a people failure — it's infrastructure debt. It happens when a website is treated as a one-time project rather than evolving infrastructure. CMS rigidity, eroded design systems, and broken staging environments compound quietly.
- Marketing-led doesn't mean engineering-free. It means marketing handles the 80% of changes that don't need custom code — and engineering focuses on the 20% that does.
- A marketing-led site runs on modular components, structured CMS collections, visual editing, and a design system that enforces brand consistency automatically — plus built-in AEO infrastructure like schema markup managed at the component level. Platforms like Webflow are purpose-built for this model.
- 60-80% of website-related engineering tickets at most mid-market B2B companies are content or layout changes that a marketing team with the right tools could handle in an afternoon.
## The Real Cost of a Dev-Dependent Website (And What Marketing-Led Looks Like)
Here's a scene that plays out every week at mid-market B2B companies:
Marketing needs a landing page for a campaign launching Tuesday. They've got the copy, the design direction, and a clear conversion goal. They submit a request. Engineering looks at the backlog and says two sprints out — maybe three. The campaign launches without a dedicated page. Traffic goes to the homepage. Conversion is mediocre. Nobody's surprised.
This isn't a failure of collaboration. It's a structural problem. The website was built in a way that requires a developer for virtually any change — and that dependency is quietly costing more than anyone has quantified.
### The visible cost vs. the real cost
The visible cost is easy to spot: slow turnaround. A landing page takes weeks instead of hours. A testimonial update becomes a Jira ticket. A pricing change sits in a queue behind feature work.
But the real cost is what doesn't happen because the friction is too high.
Marketing stops proposing landing pages for mid-funnel campaigns because they know the page won't be ready in time. They stop testing new messaging variations because each test requires a dev ticket and a two-week cycle. They stop building out content hubs because adding new templates to the CMS is a project in itself.
Over time, the team builds muscle memory around working around the website rather than through it. The site becomes a static artifact — updated quarterly at best — instead of a growth tool that evolves as fast as the business does.
That's the real cost: not the slow changes, but the experiments that never run, the campaigns that never get their own page, and the data you never collect because the infrastructure made it too hard to try.
And there's a newer cost that's compounding faster than any of these: AEO readiness. Answer Engine Optimization — the practice of structuring your site so AI-powered search engines can find, understand, and cite you — requires exactly the kind of work that dev-dependent sites make nearly impossible. Building content depth across topic clusters. Implementing structured data markup on every page. Publishing new content frequently enough to signal topical authority. Updating entity definitions as the business evolves. All of this requires a marketing team that can move fast and publish independently. If every piece of content needs a developer, you can't build the velocity that AEO demands — and your competitors, the ones who can publish freely, are training the models to cite them instead of you.
### How you got here
Nobody builds a dev-dependent website on purpose. It usually happens through a combination of reasonable decisions that compound over time.
The site was built by an agency or contractor three years ago. It worked well at launch. Then the team started making changes — a new section here, a custom layout there, a quick fix that became permanent. The original structure got layered over until only the person who built it (who's no longer around) could navigate the codebase confidently.
The CMS was configured for the content that existed at launch, not for the content marketing would want to create two years later. Adding a new page type means modifying templates. Adding a new section means touching code. The visual editor, if there is one, breaks if you deviate from the three layouts it was set up to handle.
The design system — if it was ever formalized — eroded. Components that were supposed to be reusable became one-offs. Brand consistency now depends on a developer manually matching styles rather than a system enforcing them. Marketing can't tell which components are safe to use and which ones will break something.
The staging environment is either broken, confusing, or nonexistent. Publishing a change feels risky because there's no clean way to preview it. So changes get batched, reviewed, and deployed by engineering on their schedule — not marketing's.
None of these things happened because someone made a bad decision. They happened because the website was treated as a project (build it, ship it, done) rather than as infrastructure (build it, maintain it, evolve it).
### What marketing-led actually looks like
"Marketing-led" doesn't mean engineering is cut out. It means marketing can operate the website independently for the 80% of changes that don't require custom development — and engineering is freed up to focus on the 20% that actually needs them.
In practice, that looks like:
**Modular, component-based pages.** Marketing builds pages by assembling pre-designed, brand-consistent components — hero sections, feature grids, testimonial blocks, CTA modules. No code involved. The components enforce the design system automatically, so the output always looks right regardless of who assembled it.
**A CMS built for how content actually works.** Collections for blog posts, case studies, team bios, product features — each with structured fields that marketing can populate without guessing at formatting. Content relationships (like linking a case study to a product page) are built into the structure, not hacked together with custom code.
**Visual editing with real-time preview.** Marketing sees exactly what the page will look like as they build it. No staging environment gymnastics, no "it'll look different on the live site" surprises. What you see is what ships.
**Publishing without a deploy cycle.** Content goes live when marketing says it's ready — not when the next deployment window opens. Changes can be scheduled, staged for review, and rolled back without touching a terminal.
**A design system that holds.** Colors, typography, spacing, component variants — all governed by a system that marketing can use but can't break. Brand consistency isn't maintained by vigilance; it's maintained by structure.
**Built-in AEO infrastructure.** Structured data markup managed at the component level, so every page automatically includes the schema that AI search engines need to parse and cite your content. Structured CMS collections that enforce entity-clear content by design. The ability to rapidly publish content clusters, FAQ sections, and comparison pages that build the topical depth AEO requires — without waiting for a sprint.
This isn't a hypothetical. Platforms like Webflow were built specifically for this model — giving marketing teams direct control over their site while maintaining the design and performance standards that engineering cares about. And because AEO depends on content velocity and structural consistency, a marketing-led platform is no longer a nice-to-have — it's the operational foundation that makes AI search visibility possible. It's the same reason most modern B2B teams are moving away from legacy CMS platforms that were designed for a different era of web publishing and a different kind of search engine.
### The math on regaining control
Here's a quick way to quantify what dev-dependency is costing you:
Count the number of site-change requests that went through engineering last quarter. Estimate the average turnaround time. Now calculate how many of those were content or layout changes that a marketing team with the right tools could have done in an afternoon.
For most mid-market B2B teams, that number is somewhere between 60% and 80%. That's 60-80% of website-related engineering time that could be redirected to product work — and 60-80% of marketing requests that could have shipped in days instead of weeks.
The pipeline impact is harder to quantify but just as real. Every landing page that didn't get built is a campaign that ran at reduced effectiveness. Every messaging test that didn't happen is data you don't have about what converts. Every quarter the site sits unchanged is a quarter where conversion trends are driven by inertia rather than intention.
### When it's time to fix it
If your marketing team has stopped asking for site changes because they know the answer will be "next sprint," the problem has moved past inconvenient into actively harmful. The website isn't a growth tool anymore — it's a bottleneck that's one of the clearest [signs you've outgrown your current site](/articles/six-signs-youve-outgrown-your-current-website/).
The fix isn't incremental. You can't bolt marketing-led capabilities onto a dev-dependent architecture. It requires rethinking the platform, the design system, and the content model — which is exactly what [a well-structured rebuild](/articles/b2b-website-rebuild-process/) is designed to do.
The good news: for most mid-market teams, this transition takes weeks, not months. And the ROI shows up immediately — in faster campaigns, more experiments, and a marketing team that starts treating the website as their most powerful tool again.
Tired of waiting on engineering for every site change? [Talk to BrandingLab](/contact) about what a marketing-led website looks like for your team.
### Frequently asked questions
#### What is a dev-dependent website?
A dev-dependent website is a site where marketing, content, and design changes require a developer to implement — even for tasks like updating a testimonial, changing a headline, or building a landing page. This dependency typically results from a rigid CMS, an eroded design system, or a codebase that only the original builder understood. It slows marketing velocity and turns the website into a bottleneck rather than a growth tool.
#### What does a marketing-led website mean?
A marketing-led website is one where the marketing team can independently create, edit, and publish pages without writing code or filing engineering tickets. This is achieved through modular component libraries, a structured CMS with defined content types, visual editing with real-time preview, and a design system that enforces brand consistency automatically. Engineering remains involved for custom integrations and advanced functionality — but the day-to-day operation of the site is in marketing's hands.
#### How does dev-dependency affect AI search visibility and AEO?
Dev-dependency directly undermines Answer Engine Optimization. AEO requires consistent structured data markup across every page, frequent content publishing to build topical authority, rapid deployment of content clusters and FAQ sections, and the ability to update entity definitions as the business evolves. When every change needs a developer, marketing cannot maintain the content velocity or structural consistency that AI search engines need to recognize your site as an authoritative, citable source. Companies with marketing-led websites can implement and maintain AEO strategies independently — giving them a compounding advantage in AI search results. Learn more in [Why Your B2B Website Isn't Showing Up in AI Search](/articles/b2b-ai-search-visibility/).
#### How do I know if my website is too dependent on developers?
Common signs include: landing pages taking weeks instead of hours to publish, content updates requiring Jira tickets, a staging environment that's broken or confusing, a CMS that only supports the page layouts it was originally configured for, and a marketing team that has stopped requesting site changes because they know the turnaround will be too slow. If your marketing team works around the website instead of through it, the dependency has become a strategic problem.
#### Can I make my existing website marketing-led without a full rebuild?
In most cases, no. Dev-dependency is an architectural problem — it's baked into the platform, the CMS configuration, and the design system (or lack of one). Adding a visual editor plugin to a rigid codebase creates the appearance of flexibility without the substance. A proper fix usually requires rethinking the platform, content model, and component system from the ground up. Read our full process breakdown in [What a B2B Website Rebuild Actually Looks Like](/articles/b2b-website-rebuild-process/).
#### What is the best CMS for a marketing-led B2B website?
The best CMS for a marketing-led B2B website gives marketing direct page-building control through modular components, enforces brand consistency through a design system, supports structured content collections, and publishes without a deploy cycle. Webflow is purpose-built for this model — it combines visual editing, a component-based architecture, and a structured CMS in a single platform. Other options include headless CMS solutions paired with a front-end framework, though these typically still require developer involvement for page creation and layout changes.
---
*BrandingLab helps mid-market B2B teams design and build websites that match the pace of their business. We specialize in Webflow builds, brand-driven redesigns, and sites engineered for AI-era discoverability.*
---
### Article: The B2B Guide to AEO: Moving from Search Engines to Answer Engines
**URL:** https://www.brandinglab.io/articles/b2b-aeo-strategy-2026
**Published:** 2026-06-08
**Read time:** 14 min read
**Author:** BrandingLab, Editorial
**Category:** AEO
**Key takeaways:**
- AEO optimises for citation inclusion in AI answers, not ranking position on a SERP
- LLMs retrieve from Bing and Google indexes — traditional SEO crawlability is a prerequisite
- B2B AEO mechanics: clean H2/H3 structure, schema markup, named sources, consistent claims
- Brand mentions across the web now function like backlinks did in 2015 — a primary authority signal
- 90-day plan: baseline audit, fix indexability, rewrite top 10 pages, build authority and monitoring
## The B2B Guide to AEO: Moving from Search Engines to Answer Engines
For fifteen years, B2B marketing teams built their pipelines on a single assumption: buyers type a query into Google, scan the blue links, and click. That assumption is breaking. By mid-2026, more than 60% of B2B technical research queries begin in an LLM — ChatGPT, Claude, Perplexity, or Google's AI Overviews — and the buyer never sees a ranked list of ten sources. They see one synthesised answer, sometimes with citations, often without.
This is the shift from **Search Engine Optimization (SEO)** to **Answer Engine Optimization (AEO)**. It is not a rebrand of the same playbook. It is a different optimisation target, with different mechanics, different success metrics, and a different competitive landscape.
This guide is written for B2B SaaS leaders, advisory firms, and demand-gen teams who already do SEO well and now need to understand what AEO requires — strategically, structurally, and operationally.
### What is Answer Engine Optimization?
Answer Engine Optimization is the practice of structuring your content, data, and authority signals so that large language models (LLMs) and AI search engines cite your brand when a buyer asks a question.
The "answer engines" that matter for B2B:
- **ChatGPT** (with web browsing and the SearchGPT layer)
- **Claude** (with web search)
- **Perplexity** (citation-first by design)
- **Google AI Overviews** (synthesised summaries above traditional results)
- **Microsoft Copilot** (Bing-indexed, ChatGPT-grounded)
- **Gemini** (Google's consumer and Workspace assistant)
Where SEO optimises for *ranking position*, AEO optimises for *citation inclusion*. A page that ranks position 8 on Google is invisible in the traditional sense — most clicks die at position 3. But the same page, if structured cleanly and authoritatively, can be cited by ChatGPT in 40% of the answers it generates on that topic. That citation drives qualified, high-intent traffic to your site — buyers who already trust your brand because an AI named you.
### SEO vs AEO: The strategic shift
| Dimension | SEO (2010–2024) | AEO (2025+) |
| --- | --- | --- |
| Optimisation target | Ranking position on a SERP | Inclusion in a synthesised answer |
| Primary asset | Keyword-targeted pages | Structured, citable claims |
| Success metric | Organic clicks, position | Citation rate, referral traffic from LLMs |
| Content format | Long-form, keyword-dense | Modular, scannable, claim-based |
| Authority signal | Backlinks, domain authority | Brand mentions, structured data, factual consistency |
| Update cadence | Quarterly refresh | Monthly factual review |
| Competitive moat | Domain age and link equity | Distinctive perspective and verifiable data |
The mental model that helps most B2B teams: **SEO is a popularity contest, AEO is a credibility contest.** Google ranks pages by signals of relevance and authority that compound over years. LLMs cite sources by signals of factual reliability and structural clarity that can be earned in weeks — *if* you write the right way.
### How LLMs decide who to cite
Every B2B AEO strategy starts here. If you don't understand the citation mechanics, you are guessing.
#### 1. The corpus
LLMs are trained on a snapshot of the open web, plus licensed datasets (news, books, academic papers, code). For *current* queries, they augment training data with live retrieval — typically Bing's index (ChatGPT, Copilot), Google's index (Gemini, AI Overviews), or a custom crawl (Perplexity, Claude).
What this means: if you are not indexed by Bing and Google, you do not exist to most answer engines. AEO begins with traditional crawlability.
#### 2. The retrieval layer
When a user asks a question, the LLM does not search its training data — it issues 2–8 search queries to a live index, reads the top results, and synthesises an answer. The pages it reads are usually:
- Top 10 organic results for the query
- Pages with high topical authority signals
- Pages that match the *structural shape* of an answer (lists, definitions, comparisons)
Your AEO job is to be in those top 10, *and* to be structurally easy to extract from.
#### 3. The synthesis layer
The LLM reads the retrieved pages and generates an answer. It chooses which sources to cite based on:
- **Specificity** — concrete numbers, dates, named entities
- **Clarity** — clean H2/H3 hierarchy, short paragraphs, definition-style openings
- **Consistency** — claims that match what other authoritative sources say
- **Authority** — domain reputation, author credentials, schema markup
Pages that read like marketing copy get summarised but rarely cited. Pages that read like a well-edited reference document get cited by name.
### The B2B AEO checklist
This is the playbook we use with B2B SaaS and advisory clients. Work through it in order — each step compounds on the previous.
#### Step 1 — Audit your current AI visibility
Before changing anything, measure. For 20–30 queries your buyers actually ask, prompt ChatGPT, Claude, and Perplexity and record:
- Is your brand cited? (yes / no / paraphrased without citation)
- Which competitors are cited?
- What sources are cited *instead* of you?
This is your baseline. Re-run quarterly to measure progress.
#### Step 2 — Fix indexability
LLMs cannot cite what they cannot read. The most common B2B AEO failure is not strategy — it is a single-page-app website that renders content client-side and serves an empty HTML shell to crawlers. Check:
- Server-side rendering or prerendering on every page that matters
- `robots.txt` does not block GPTBot, ClaudeBot, PerplexityBot, or Google-Extended
- Sitemap is current and submitted to Bing and Google
- Schema.org markup on Organization, Article, FAQPage, and Product where applicable
#### Step 3 — Restructure your top 20 pages
Pick the 20 pages that already drive the most pipeline. Rewrite them so each one:
- Opens with a one-sentence definition of the topic
- Uses H2s phrased as questions or claims a buyer would search
- Includes a comparison table if the topic involves a choice
- Cites named sources for every non-obvious factual claim
- Ends with a clear takeaways block
This is not "writing for AI". It is writing for a reader who skims, which happens to be the same shape LLMs extract well.
#### Step 4 — Build a claim library
Identify the 30–50 factual claims your firm wants to own — statistics, definitions, frameworks, methodologies. Publish each one on a canonical page, with a citation to your primary research or source. Repeat the same claim, in the same words, across multiple pages (blog, product, case study). Consistency is a citation signal.
#### Step 5 — Earn unstructured citations
LLMs notice when your brand is mentioned across the web — even without a backlink. Prioritise:
- Guest posts on industry publications
- Podcast appearances with show-note transcripts
- Conference talks with public recordings
- Customer-driven case studies and review-site presence
Brand mention frequency now functions like backlinks did in 2015 — a primary signal of authority for retrieval-augmented LLMs.
### Common B2B AEO mistakes
After working on AEO with mid-market and enterprise B2B teams since 2024, the same five mistakes recur:
1. **Treating AEO as a content task.** It is a content, structure, and authority task. Skipping any one of the three breaks the chain.
2. **Optimising for ranking, not citation.** A page that ranks #1 with thin, marketing-heavy copy will be summarised and dropped. A page that ranks #6 with clean, citable claims will be quoted by name.
3. **Blocking AI crawlers in `robots.txt`.** Some legal teams have done this defensively. It means zero AI citations. The right answer is allow + monitor, not block.
4. **Ignoring schema markup.** Schema is not optional for AEO. Organization, FAQPage, and Article schema directly improve citation rates in Google AI Overviews.
5. **Measuring with Google Search Console.** GSC does not show LLM referrals. You need a separate monitoring layer — manual prompt audits, or a tool like our [AEO monitor](/aeo-monitor).
### What stays the same
It is easy to read the shift from SEO to AEO and assume the old playbook is dead. It is not. Foundational SEO mechanics still matter — they are now table stakes rather than a competitive moat.
- **Crawlable, fast, well-structured sites still win.** AEO requires SEO.
- **Topical authority still compounds.** A site with 200 pages on B2B SaaS will out-cite a site with 20.
- **Backlinks still help.** They are a stronger signal than ever for *which* of your pages get retrieved.
The shift is additive, not subtractive. B2B teams that already do SEO well are 12–18 months ahead of teams starting from scratch.
### What changes for B2B specifically
Consumer brands have a different AEO problem — high search volume, low decision stakes. B2B AEO has the opposite shape:
- **Lower query volume, higher pipeline value.** A single citation in a CFO's ChatGPT session can drive a six-figure deal.
- **Long, multi-turn research sessions.** Buyers ask 8–15 questions across a vendor shortlist. You need to be cited consistently across the funnel, not just on the opening query.
- **Trust signals matter more.** Author credentials, customer logos, named case studies, and verifiable data are weighted heavily by LLMs on B2B topics.
- **Pricing transparency wins.** LLMs cite pages with concrete pricing, even ranges, far more often than "contact us" pages.
### A 90-day B2B AEO plan
If you are starting from zero, this is the sequence we recommend.
**Days 1–14 — Baseline.** Run the visibility audit (Step 1 above). Document where you stand on 25 priority queries. Identify your three strongest competitors in AI search.
**Days 15–30 — Foundations.** Fix indexability. Add or repair schema markup on every priority page. Resolve any robots.txt or rendering issues blocking AI crawlers.
**Days 31–60 — Rewrite the top 10.** Restructure your ten highest-value pages using the format above. Publish a canonical "what is X" definition page for each of your three top-of-funnel topics.
**Days 61–90 — Authority and measurement.** Begin a structured outreach programme for unstructured citations (podcasts, guest posts, review sites). Set up monthly LLM visibility monitoring. Re-run the baseline audit and measure delta.
By day 90, well-executed B2B teams typically see a 2–4x increase in citation rate across their target query set.
### How BrandingLab approaches B2B AEO
We build Webflow and Next.js sites for B2B SaaS and advisory firms with AEO as a first-class concern from day one. That means server-side rendering by default, schema markup baked into every template, content structured for citation extraction, and a monitoring layer to track which LLMs are citing the brand and which competitors are winning queries.
If you are a B2B leader thinking about AEO seriously for 2026, start with our [AEO audit](/audit) or talk to us about a [strategic AEO sprint](/aeo-services).
### FAQ
#### What is the difference between SEO and AEO?
SEO optimises for ranking position in traditional search engines like Google. AEO optimises for citation inclusion in AI-generated answers from systems like ChatGPT, Claude, Perplexity, and Google AI Overviews. SEO is a popularity contest; AEO is a credibility contest.
#### Does AEO replace SEO?
No. AEO requires SEO as a foundation — LLMs retrieve from the same indexes Google ranks against. The shift is additive: traditional SEO mechanics are now table stakes, and AEO is the new layer of competitive advantage.
#### How do I know if ChatGPT is citing my brand?
Manually prompt ChatGPT, Claude, and Perplexity with the queries your buyers ask and record citations. For continuous monitoring, use a tool like BrandingLab's AEO monitor to track citation rates across LLMs over time.
#### How long does AEO take to show results?
Most B2B teams see measurable citation rate improvements within 60–90 days of restructuring their top pages, fixing indexability, and adding schema markup. Authority-driven gains from unstructured citations compound over 6–12 months.
#### Should I block AI crawlers like GPTBot in robots.txt?
For most B2B brands, no. Blocking AI crawlers guarantees zero citations from those systems. The competitive cost is far higher than the perceived IP risk. Allow + monitor is the right default; only block if you have a specific legal reason.
---
### Article: What is Answer Engine Optimization? The B2B Guide to AEO
**URL:** https://www.brandinglab.io/articles/what-is-aeo
**Published:** 2026-06-05
**Read time:** 12 min read
**Author:** BrandingLab, Editorial
**Category:** AEO
**Key takeaways:**
- AEO is the practice of earning citations inside AI-generated answers from ChatGPT, Claude, Perplexity and Google AI Overviews.
- 89% of B2B buyers now use generative AI in the purchase journey — citation share is the new market share.
- Citation depends on three layers: technical foundation, content structure, and brand entity signals. All three must be in place.
- Open every page with a one-sentence definitional answer. That sentence is what engines extract.
- Allow GPTBot, ClaudeBot, PerplexityBot and Google-Extended in robots.txt. Blocking them blocks your future pipeline.
- Expect three to six months for citations to start appearing on an established domain. The work compounds.
Answer Engine Optimization (AEO) is the practice of structuring your content, brand and technical foundation so that AI answer engines — ChatGPT, Claude, Perplexity, Gemini and Google's AI Overviews — cite your business when buyers ask questions in your category.
For B2B teams, AEO is no longer optional. Gartner forecasts a 25% drop in traditional search traffic by 2026 as buyers move research into conversational AI. The companies showing up inside those answers will own the next decade of pipeline. The ones that don't will quietly disappear from the consideration set.
This guide explains what AEO is, how answer engines actually pick sources, and exactly what a B2B team should do this quarter to start getting cited.
### What is Answer Engine Optimization?
Answer Engine Optimization is the discipline of earning citations inside AI-generated answers.
Where SEO optimised for ten blue links, AEO optimises for one synthesised paragraph with two or three named sources. The unit of distribution has changed: a buyer no longer browses a SERP and picks a result. They read an answer and trust the brands the answer mentions.
AEO sits at the intersection of three things:
- **Technical foundation** — clean HTML, schema markup, server-rendered content, fast load times, indexable pages.
- **Content structure** — semantic headings, definitional opening sentences, lists, tables, FAQs, original data.
- **Brand authority** — third-party mentions, consistent entity signals across the web, a recognisable point of view.
Without all three, your content is invisible to the systems that increasingly mediate B2B research.
### Why AEO matters for B2B specifically
B2B buyers are exactly the audience that adopted ChatGPT fastest. According to Forrester, 89% of B2B buyers now use generative AI at some stage of the purchase journey, most heavily in the awareness and shortlist phases — the phases where pipeline is won or lost.
Three structural reasons AEO disproportionately affects B2B:
1. **High-intent questions are conversational.** "What's the difference between [vendor A] and [vendor B] for a 200-person engineering org" is a ChatGPT query, not a Google query. The buyer asks the model directly.
2. **Trust is concentrated.** AI engines cite a small number of sources per answer. If the model decides three companies are the canonical players in your category, the rest get no consideration.
3. **The funnel shortens.** Buyers arrive at sales conversations already informed — and already biased toward whoever the model mentioned by name.
If your competitors are being cited and you aren't, your pipeline will compress before your analytics shows it. By the time the demo requests drop, the damage is six months old.
### How LLMs actually pick sources
Understanding citation mechanics is the difference between guessing at AEO and engineering for it. Each major engine has a slightly different retrieval pipeline, but the shared logic is consistent.
#### ChatGPT (with browsing) and ChatGPT Search
ChatGPT uses Bing's index as its primary retrieval layer, augmented with OpenAI's own crawler (GPTBot). When a user asks a question, ChatGPT issues several reformulated search queries, retrieves the top results, and synthesises an answer. Sources that appear in the top 10 of Bing for those reformulated queries are the candidate pool. Pages with clear definitional sentences, structured data and recognisable brand entities are favoured in the final cite list.
#### Claude
Claude's retrieval (via the web search tool) leans on Brave Search and runs heavier reasoning over fewer sources. Claude is unusually sensitive to source credibility signals — domain authority, author bylines, and external mentions — and tends to cite long-form, deeply argued pages rather than thin SEO content.
#### Perplexity
Perplexity is the most transparent. It runs multiple search engines in parallel, ranks results with its own model, and shows you exactly which sources it used. Perplexity heavily favours pages that answer the question in the first 100 words, have clear sections, and include data or original research.
#### Google AI Overviews and Gemini
Google AI Overviews use Google's full search index plus the Knowledge Graph. Pages that rank in the traditional top 10, have rich schema markup, and have strong entity associations are most likely to be summarised. AI Overviews are aggressively conservative — they cite high-trust domains and rarely surface unknown brands.
The common thread: **rank well in classical search, structure your content for extractive answers, and build entity authority across the web.** No AEO tactic works in isolation.
### The B2B AEO Checklist
This is the working checklist we use at BrandingLab when running an AEO programme for a B2B client. Work through it in order.
#### 1. Technical foundation
- Server-render or pre-render every page that needs to rank. Single-page apps without SSR are largely invisible to GPTBot and Bingbot.
- Make sure `robots.txt` allows `GPTBot`, `ClaudeBot`, `PerplexityBot`, `Google-Extended` and `OAI-SearchBot`. Blocking them blocks your future pipeline.
- Achieve a Lighthouse performance score above 90 on mobile. Slow pages are deprioritised.
- Use semantic HTML — ``, ``, `
` through `
` in order, real `
` elements, real lists.
#### 2. Schema markup
- `Organization` schema on every page, with a complete `sameAs` array linking to your LinkedIn, Crunchbase, GitHub and other authoritative profiles.
- `Article` schema on every blog post, with `author`, `datePublished` and `wordCount`.
- `FAQPage` schema on any page with question-style headings.
- `BreadcrumbList` schema for navigational clarity.
- `Product` or `Service` schema on commercial pages, with `aggregateRating` if you have legitimate review data.
#### 3. Content structure
- Open every page with a one-sentence, definitional answer to the page's core question. This sentence is what answer engines extract.
- Use H2s that read like questions. "What is X" / "How does X work" / "When should you use X".
- Add a comparison table on any "vs" or category page. Tables get extracted intact.
- Include a short FAQ block at the bottom of every pillar page covering the three or four questions buyers actually ask in sales calls.
- Publish original data, benchmarks or frameworks. Engines disproportionately cite content that contains numbers nobody else has.
#### 4. Brand and entity signals
- Maintain a single, consistent brand entity across the web — same legal name, same description, same logo, same `sameAs` profiles.
- Earn mentions on third-party sites that the models already trust — industry publications, podcasts, podcast show notes, partner blogs, Crunchbase, G2, Capterra.
- Publish an `about` page that reads like an entity definition. Who you are, what category you serve, who your customers are. Models use this verbatim.
- Get cited in directories and "best of" listicles in your category. Models lean on these for shortlist construction.
#### 5. Measurement
- Track citations manually each month across ChatGPT, Claude, Perplexity and Google AI Overviews for your top 20 buyer-intent queries.
- Use a citation monitoring tool (Profound, Otterly, Peec) for ongoing coverage.
- Watch referral traffic from `chat.openai.com`, `perplexity.ai` and `claude.ai` in GA4. The volumes are small but the intent is enormous — these visitors convert at multiples of organic.
### Common AEO mistakes B2B teams make
- **Treating AEO as SEO with a new acronym.** It is not. SEO optimises for rankings; AEO optimises for extraction and citation. The tactics overlap but the success criteria are different.
- **Hiding answers behind brand voice.** Witty intros and metaphor-heavy openings get skipped. Lead with the answer; add personality in paragraph two.
- **Publishing thin content faster.** Models reward depth, not volume. One 2,500-word pillar beats ten 600-word posts.
- **Ignoring third-party signals.** You cannot AEO your way to authority from your own domain alone. Mentions on sites the model trusts are non-negotiable.
- **Blocking AI crawlers by default.** Many enterprise IT teams added `GPTBot` to `robots.txt` in 2023 "to be safe". Reverse it.
### How long does AEO take to work?
Three to six months for a structured programme on a domain with existing authority. Six to twelve months for a newer domain. Citations are a lagging indicator — the technical and content work compounds, then citations appear in clusters once your brand entity crosses a recognition threshold inside the models.
The teams that started in 2024 are already being cited in 2026. The teams starting now will be cited in 2027. The teams waiting until they "see what happens" will not be cited at all.
### Frequently asked questions
#### What is the difference between AEO and SEO?
SEO optimises a page to rank in a list of links. AEO optimises a page to be extracted and cited inside a generated answer. SEO tactics are a prerequisite for AEO — if you cannot rank in classical search, you cannot be retrieved by answer engines — but AEO adds structural, entity and citation-earning work on top.
#### Is AEO the same as Generative Engine Optimization (GEO)?
Effectively yes. AEO, GEO and AI SEO are competing terms for the same discipline. The industry has not settled on a winner. We use AEO because it most clearly describes the goal: being cited in answers.
#### Which AI engine should B2B brands optimise for first?
Optimise for ChatGPT first. It has the largest user base, the most B2B usage, and its retrieval pipeline (Bing-based) overlaps heavily with what works for Google AI Overviews. Wins on ChatGPT tend to transfer.
#### Do I need to publish more content to do AEO well?
Not necessarily. Most B2B sites have enough content but the wrong structure. An audit of existing pillar pages — tightening openings, adding schema, restructuring headings, adding FAQs — usually delivers more citations than a new content sprint.
#### How do I know if AEO is working?
Track three things: direct citation appearances in your top 20 buyer queries, referral traffic from AI domains in GA4, and pipeline-sourced mentions in sales calls ("ChatGPT recommended you"). The last one is the most valuable and the hardest to measure.
---
If you want help running AEO for your B2B brand, BrandingLab runs structured AEO programmes for enterprise teams. See our [AEO services](/aeo-services) page for how we work, or [request a quote](/request-a-quote) for your site.
---
### Article: Opsi Systems — Enterprise Transportation Technology Website
**URL:** https://www.brandinglab.io/articles/opsi-systems-90-days-data
**Published:** 2026-05-08
**Read time:** 8 min read
**Author:** Russel Shalom Davis, Founder, BrandingLab
**Category:** Case Study
**Key takeaways:**
- The Opsi Systems site grew out of an existing Tramm retainer — proof of work won the parent-brand brief.
- AEO is a continuous retainer activity, not a launch deliverable, in a world of ChatGPT, Perplexity, and Google AI Overview research.
- Low bounce on intent pages (Contact 12%, Delivery 0%) signals the right enterprise buyers found the right content.
- Referrals from claude.ai and gemini.google.com confirm FAQ schema and AEO architecture surfacing in AI-generated answers.
- 4 weeks Figma to live — full Webflow build, custom Lottie animations generated via Claude Code, and CMS handover.
### Overview
This project didn't start with Opsi Systems. It started with Tramm.
BrandingLab was brought in on a retainer to work on [tramm.global](https://www.tramm.global) — the website for Opsi's flagship transportation management system. That engagement involved ongoing SEO and AEO optimisation, content architecture, and digital strategy for Tramm TMS and the Chora GPU optimization engine.
Having seen what BrandingLab could do for the Tramm brand, the team at Opsi Systems — the corporate parent behind Tramm and Chora — decided to brief us on rebuilding the Opsi corporate website. The result was [opsisystems.com](https://www.opsisystems.com).
Opsi Systems operates across 4 global regions and serves enterprise logistics environments where complexity is the norm — global 3PLs, private fleets, retail, FMCG, and manufacturing. BrandingLab designed and built opsisystems.com as a full Webflow website that positions Opsi as a credible enterprise technology parent and communicates platform depth, global scale, and governance standards to demanding B2B buyers.
Critically, this is not a one-time project. BrandingLab continues to work with Opsi Systems on an ongoing retainer — optimising content, strengthening AEO structure, and ensuring the site is found by the right buyers through AI-powered search tools. In a world where enterprise buyers increasingly use tools like ChatGPT, Perplexity, and Google's AI Overview to research platform decisions before visiting any website, AEO is not a launch activity. It is a continuous one.
### The Challenge
Enterprise software buyers evaluate risk as much as they evaluate features. Opsi needed a website that would earn the trust of logistics directors, CIOs, and procurement teams in the first scroll — without a generic SaaS template, without startup energy, and without simplifying the technical depth of the product.
The challenge wasn't just design. It was communication architecture: how do you present GPU-powered route optimization, ISO 27001 compliance, multi-fleet TMS, and 25 years of domain expertise to four different global buyer audiences in one coherent digital experience?
### Our Approach
We built opsisystems.com on a dark, authoritative visual foundation — a deliberate departure from the startup aesthetic. Every design and content decision was made around one question: *what does an enterprise procurement team need to see to move forward?*
The content architecture was structured around buyer questions, not product features:
- Who is this company and how long have they been doing this?
- What does the platform actually do at enterprise scale?
- Can this handle our complexity — multi-fleet, multi-principal, global?
- Are they compliant with ISO 27001, GDPR, and POPIA?
- How do we start a conversation?
We also implemented Answer Engine Optimization (AEO) — structuring every page with correct heading hierarchy, FAQ schema markup, and semantic content blocks so Opsi appears in AI-generated research answers, not just traditional search results.
### Lottie Animations
To bring the Opsi Systems brand to life on the website, we generated a series of custom Lottie animations in line with the brand's dark, authoritative visual style. Rather than using generic stock animations, we took a different approach: the Lottie files were generated by feeding the site content into Claude Code and prompting it to build Lottie diagrams in line with the Opsi brand style.
This AI-assisted animation workflow allowed us to produce bespoke, on-brand motion graphics that visualise complex technical concepts — GPU-powered route optimization, multi-fleet logistics flows, and enterprise platform architecture — without generic stock animation libraries.
Each animation was:
- Generated by Claude Code using the site's content as the brief
- Styled to match the Opsi dark palette — #0A0A1A background, orange accent
- Exported as lightweight Lottie JSON files for fast web rendering
- Embedded inline in Webflow via the Lottie Player component
The result is a set of animations that feel native to the brand — not borrowed from a generic library — and communicate technical complexity in a way that is immediately clear to an enterprise buyer.
### Results
Here's what the project delivered — a complete enterprise digital presence built for the buyers Opsi needs to reach.
| Metric | Value |
|---|---|
| Global Regions | 4 |
| Years Expertise | 25+ |
| Figma to Live | 4 weeks |
| AEO | Optimised |
**What was delivered:**
- Full Webflow design and development — responsive across all devices
- Corporate brand architecture — Opsi as parent, Tramm + Chora as products
- Custom Lottie animations generated via Claude Code, styled to brand
- AEO-optimised content with FAQ schema (JSON-LD)
- Enterprise buyer-focused content hierarchy
- Governance credibility signals — ISO 27001, GDPR, POPIA
- Global audience-ready copy across 4 regions
- CMS setup for ongoing content management without developer dependency
### Performance — First 90 Days
Within the first 90 days of launch, opsisystems.com was already demonstrating the results of a well-structured, well-optimised Webflow build.
| Metric | Value |
|---|---|
| Active Users | 406 |
| Organic Search Users | 69 |
| Contact Page Bounce | 12% |
| Delivery Page Bounce | 0% |
#### SEO & AEO Working From Day One
Google and Bing delivered 69 organic search users within the first 90 days of a new domain — a direct result of the correct heading hierarchy, semantic HTML structure, and AEO content architecture built into every page of the Webflow site.
Referral sessions from claude.ai and gemini.google.com confirmed that the FAQ schema markup and structured content blocks were surfacing Opsi Systems in AI-generated research answers — not just traditional search results.
#### Enterprise Buyers Engaging Deeply
The pages designed for serious enterprise evaluation — Contact (12% bounce), Industries (11.8% bounce), and Delivery & Implementation (0% bounce) — showed that the right audience was finding the right content and taking action. These are not casual visitors. These are buyers in an evaluation process.
Referral traffic from Microsoft Teams, active Tramm client deployments, and an enterprise technology company evaluating Opsi from their internal test environment confirmed the site was reaching and engaging the correct audience.
#### Global Reach — Built In
The site reached buyers across Johannesburg, New York, Nairobi, Cape Town, Shanghai, Dubai, Vienna, Montreal, and 80+ cities worldwide — reflecting Opsi's actual global operational footprint and the content architecture designed to serve four distinct regional audiences from a single coherent digital presence.
### Client Feedback
> "BrandingLab understood exactly what we needed — a website that communicates the weight and credibility of what we've built over 25 years. The result speaks for itself."
>
> — Opsi Systems Team, opsisystems.com
### Frequently Asked Questions
#### Why was Webflow chosen for an enterprise build?
Webflow gives Opsi Systems full CMS control with no ongoing developer dependency for content updates. It produces clean, semantic HTML that is both performant and structured correctly for SEO and AEO. For an enterprise company managing content across a global audience, that independence is critical.
#### What is AEO and why does it matter for B2B companies?
Answer Engine Optimization (AEO) structures your website content so it appears in AI-generated answers from tools like ChatGPT, Perplexity, and Google's AI Overview. Enterprise B2B buyers increasingly use AI to research platform decisions before visiting any vendor website. AEO ensures Opsi Systems is part of those answers.
#### How did BrandingLab handle the technical complexity of the product?
We built the content architecture around buyer questions rather than product features. Technical depth (GPU optimization, multi-principal fleet management) was framed in terms of what it means for the buyer's operation — not in engineering language. This makes the site accessible to procurement teams and technical evaluators simultaneously.
#### How were the Lottie animations created?
The Lottie files were generated using Claude Code — we fed the site content into the AI and prompted it to build Lottie animations in line with the Opsi brand style. This produced bespoke, on-brand motion graphics without generic stock animation libraries. Each file was exported as lightweight JSON and embedded via Webflow's Lottie Player component.
#### How long did the project take?
The full project — from Figma design to live published site — was completed in 4 weeks. This included Webflow design and development, AEO content architecture, custom Lottie animation generation, and CMS setup.
#### Can BrandingLab build something similar for my business?
Yes. If you're running a B2B company that needs a website built for enterprise buyers — with Webflow, AEO strategy, and content architecture that earns trust — get in touch at [brandinglab.io](/contact).
### Built by BrandingLab
opsisystems.com was designed and developed by BrandingLab — full Webflow build, AEO content architecture, custom Lottie animations via Claude Code, four weeks from Figma to live.
- See the case study: [brandinglab.io/work/opsi-systems](/work/opsi-systems)
- Work with us: [brandinglab.io/contact](/contact)
---
### Article: JSON-LD for React SPAs: A Practical Schema Markup Guide
**URL:** https://www.brandinglab.io/articles/jsonld-for-react-spas-schema-markup-guide
**Published:** 2026-05-01
**Read time:** 9 min read
**Author:** BrandingLab, Editorial
**Category:** AEO
**Key takeaways:**
- React SPAs ship empty HTML; without JSON-LD in the initial payload, AI crawlers see nothing semantic.
- Put site-wide schema (Organization/ProfessionalService, WebSite) statically in index.html so it is present before React mounts.
- Inject per-route schema (BlogPosting, Service, FAQPage, BreadcrumbList, CreativeWork) via react-helmet-async.
- Prefer specific subtypes: BlogPosting over Article, ProfessionalService over generic Organization.
- Validate every page type at Google Rich Results Test and validator.schema.org before shipping.
## JSON-LD for React SPAs: A Practical Schema Markup Guide
### TL;DR
- React SPAs (Vite, CRA, Lovable, Bolt, v0) ship empty `` HTML. Without JSON-LD in the initial payload, AI crawlers see nothing semantic.
- **Site-wide schema** (`Organization`/`ProfessionalService`, `WebSite`) goes statically in `index.html` so it's present before React mounts.
- **Per-route schema** (`BlogPosting`, `Service`, `FAQPage`, `BreadcrumbList`, `CreativeWork`) goes via `react-helmet-async` so each URL ships its own structured data.
- Validate everything at https://search.google.com/test/rich-results before declaring victory.
- The patterns below are what we ship on every B2B Vite + React SPA we touch. Copy them, change the values, deploy.
This is the tactical companion to [our piece on why React SPAs are invisible to AI search](/articles/why-your-spa-is-invisible-to-ai-search). Read that for the *why*. Read this for the *what*.
---
### Why React SPAs need JSON-LD even more than server-rendered sites
JSON-LD is structured data — a JSON block in your HTML that tells search engines and AI crawlers what your page is about in a machine-readable format. For server-rendered sites, JSON-LD is a bonus: crawlers can understand most of the page from the rendered HTML alone. For React SPAs, JSON-LD is not optional — it's often the only thing crawlers can read.
When a crawler hits a Vite + React SPA without executing JavaScript, the body is ``. Empty. The only signal-carrying content available is whatever's in the static ``. Title and meta description help. JSON-LD helps far more, because it gives crawlers structured, typed information they can map directly into knowledge graphs.
Even crawlers that *do* execute JavaScript benefit. Schema present in the initial payload is treated as more authoritative than schema injected during hydration.
### Where JSON-LD goes in a React SPA
Two locations. Use both.
#### Static, in `index.html`
For schema that's true site-wide and never changes per route. Goes in the `` of `index.html` (the Vite entry HTML). Present before React executes. Visible to every crawler.
Use for:
- `Organization` or `ProfessionalService` (the entity behind the site)
- `WebSite` (with `SearchAction` for sitelinks search box)
#### Dynamic, via `react-helmet-async`
For schema that changes per route. Mounted in React; updated whenever the user navigates. Visible to JS-capable crawlers; falls back to the static schema for non-JS crawlers.
Use for:
- `BlogPosting` on each article
- `Service` on each service page
- `CreativeWork` on each case study
- `FAQPage` on FAQ pages and case-study FAQ blocks
- `BreadcrumbList` on every page
### The patterns we ship
#### Pattern 1 — Static `Organization` (or `ProfessionalService`) in `index.html`
`ProfessionalService` is a more specific subtype of `Organization` that extends `LocalBusiness`. If you're a B2B services firm with an address and a price range, prefer it.
```html
```
The `@id` matters — it's the canonical identifier other schema blocks reference (e.g., `"publisher": {"@id": "https://example.com#organization"}`). Use a fragment URL like `#organization`.
#### Pattern 2 — Static `WebSite` in `index.html`
```html
```
The `SearchAction` enables Google's sitelinks search box for branded queries. Drop it if you don't have an internal search.
#### Pattern 3 — A reusable schema generator module
Don't paste JSON-LD inline on every page. Centralise it. A single `src/lib/schema.ts` exports functions for each page type:
```ts
const SITE_URL = "https://example.com";
const LOGO_URL = `${SITE_URL}/logo.svg`;
export function articleSchema(a: {
slug: string;
headline: string;
description: string;
image?: string;
datePublished: string;
dateModified?: string;
authorName?: string;
}) {
return {
"@context": "https://schema.org",
"@type": "BlogPosting",
headline: a.headline,
description: a.description,
image: a.image,
datePublished: a.datePublished,
dateModified: a.dateModified ?? a.datePublished,
author: { "@type": "Person", name: a.authorName ?? "Editorial Team" },
publisher: {
"@type": "Organization",
name: "Your Company",
logo: { "@type": "ImageObject", url: LOGO_URL }
},
mainEntityOfPage: { "@type": "WebPage", "@id": `${SITE_URL}/articles/${a.slug}` }
};
}
export function serviceSchema(s: {
name: string;
description: string;
slug: string;
serviceType: string;
}) {
return {
"@context": "https://schema.org",
"@type": "Service",
name: s.name,
description: s.description,
provider: { "@id": `${SITE_URL}#organization` },
serviceType: s.serviceType,
areaServed: ["IL", "US", "GB", "EU", "Worldwide"],
url: `${SITE_URL}/${s.slug}`
};
}
export function faqPageSchema(items: { question: string; answer: string }[]) {
return {
"@context": "https://schema.org",
"@type": "FAQPage",
mainEntity: items.map(i => ({
"@type": "Question",
name: i.question,
acceptedAnswer: { "@type": "Answer", text: i.answer }
}))
};
}
export function breadcrumbSchema(crumbs: { name: string; url: string }[]) {
return {
"@context": "https://schema.org",
"@type": "BreadcrumbList",
itemListElement: crumbs.map((c, i) => ({
"@type": "ListItem",
position: i + 1,
name: c.name,
item: c.url
}))
};
}
```
**Use `BlogPosting`, not `Article`, for blog posts.** `BlogPosting` is a more specific subtype and triggers richer SERP and AI treatment.
#### Pattern 4 — Inject per-route schema with `react-helmet-async`
```tsx
import { Helmet } from "react-helmet-async";
import { articleSchema, breadcrumbSchema } from "@/lib/schema";
export function ArticlePage({ article }) {
const schemas = [
articleSchema({
slug: article.slug,
headline: article.title,
description: article.excerpt,
image: article.ogImage,
datePublished: article.publishedAt,
dateModified: article.updatedAt,
authorName: article.author
}),
breadcrumbSchema([
{ name: "Home", url: "https://example.com" },
{ name: "Articles", url: "https://example.com/articles" },
{ name: article.title, url: `https://example.com/articles/${article.slug}` }
])
];
return (
<>
{article.title} · Your Company
{schemas.map((s, i) => (
))}
{/* page body */}
>
);
}
```
Wrap your app in `` once at the root (`src/main.tsx`):
```tsx
import { HelmetProvider } from "react-helmet-async";
createRoot(document.getElementById("root")!).render(
);
```
### Validate everything
Two free tools, both worth running on every page type:
- **Google Rich Results Test** — https://search.google.com/test/rich-results — confirms validity and shows which rich results your schema is eligible for.
- **Schema.org Validator** — https://validator.schema.org/ — stricter; catches edge cases Google's tool ignores.
Run both on:
- Homepage (expect: `Organization` or `ProfessionalService` + `WebSite` + `BreadcrumbList`)
- One article (expect: + `BlogPosting`)
- One service page (expect: + `Service`)
- The FAQ page (expect: + `FAQPage`)
- One case study (expect: + `CreativeWork` or your domain-appropriate type)
### Common mistakes we see weekly
1. **Two `BreadcrumbList` blocks per page.** Happens when an auto-injector adds breadcrumbs *and* the page also passes `breadcrumbSchema(...)` manually. Pick one source of truth.
2. **`Article` instead of `BlogPosting`.** `BlogPosting` is more specific and triggers richer treatment. Use it for any blog content.
3. **Generic `Organization` instead of `ProfessionalService` (or `LocalBusiness`).** If you have an address and a price range, the more specific type accepts richer fields and signals more confidence.
4. **No `@id` references.** Without `@id`, schema blocks can't reference each other (e.g., `BlogPosting.publisher` referencing the site's `Organization`). Use fragment URLs.
5. **`og:image` URL that 404s.** We've seen this on dozens of sites — the OG image is referenced in `index.html` but the file doesn't exist. `curl -I` every URL in your schema before shipping.
6. **`datePublished` in the future or as a non-ISO string.** Both fail validation silently. Use ISO 8601: `2026-05-01`.
7. **Inline JSON in JSX without `JSON.stringify`.** React will escape quotes and break the JSON. Always serialize with `JSON.stringify(schema)`.
### What this gets you
Schema markup is necessary but not sufficient for AEO. It establishes brand entity in AI knowledge graphs, makes your pages eligible for rich results in Google, and gives JS-capable AI crawlers structured signal to work with. It does *not*, by itself, fix the SPA invisibility problem — for that you also need either pre-rendering (build-time SSG via tools like `react-snap`), server-side rendering, or a markdown-based discovery file (`llms.txt` and `llms-full.txt`).
For the full strategy — schema plus rendering plus discovery — see [why your SPA is invisible to AI search and how to fix it](/articles/why-your-spa-is-invisible-to-ai-search).
### Frequently asked questions
#### Do I need both static and dynamic JSON-LD?
Yes. Static schema in `index.html` (Organization/ProfessionalService, WebSite) gives crawlers identity and site context on every URL before React mounts. Dynamic per-route schema (BlogPosting, Service, FAQPage, BreadcrumbList) describes the specific page. Crawlers that don't execute JavaScript still get the site-wide entity; crawlers that do execute it get the per-page detail.
#### Will react-helmet-async work for AI crawlers that don't run JavaScript?
No — that's the catch. `react-helmet-async` injects schema after React mounts, so non-rendering crawlers (most AI bots, classic Googlebot fallback) won't see it. For those, you need prerendering, SSR, or a markdown discovery file (`llms.txt`/`llms-full.txt`). Use Helmet for the JS-capable crawlers; use one of the other three to cover the rest.
#### Which schema type should I use for a blog post — Article or BlogPosting?
`BlogPosting`. It's a subtype of `Article` and signals editorial blog content specifically. Google and most AI engines prefer the more specific subtype. Same logic for `ProfessionalService` over `Organization`, `LocalBusiness` over `Organization` for location-based businesses.
#### Do I need to validate every page or just the templates?
Validate every distinct page type — homepage, article template, service page, case study, FAQ — once. You don't need to revalidate every individual blog post unless you change the template. Run Google Rich Results Test and validator.schema.org on one example of each type before shipping, and after any template change.
#### Will Google penalize me for having JSON-LD that doesn't match visible content?
Yes. Schema must accurately describe what's on the page. Don't fabricate AggregateRating values, don't mark up FAQs that aren't visible, don't claim authorship that isn't real. Mismatched schema is treated as spam and can trigger manual actions.
### Get a free AEO audit of your B2B site
We'll audit your site's schema, rendering, and AI-crawler accessibility — for free. Twenty-minute report, prioritized fix list, no commitment.
[Request your free AEO Audit →](/audit)
---
### Article: Why Your SPA Is Invisible to AI Search (And How to Fix It)
**URL:** https://www.brandinglab.io/articles/why-your-spa-is-invisible-to-ai-search
**Published:** 2026-04-30
**Read time:** 14 min read
**Author:** BrandingLab, Editorial
**Category:** AEO
**Key takeaways:**
- AI crawlers like GPTBot and ClaudeBot do not reliably execute JavaScript, so SPAs return a blank shell
- A single-page app served as a blank shell is invisible to most answer engines
- Schema markup only helps if the surrounding HTML is server-rendered
- Three fixes exist: SSR migration, edge prerendering, or build-time static generation
- The right choice depends on publishing cadence, not site size
## Why Your SPA Is Invisible to AI Search (And How to Fix It)
Open a terminal. Pick any URL on your marketing site. Run this:
```bash
curl -A "GPTBot" https://yoursite.com/your-best-article
```
Read what comes back.
If your site is built as a single-page application — React, Vue, Angular, Svelte without server rendering — there is a strong chance the response is a near-empty HTML shell. A ``, a script tag, and almost nothing else. No headline. No body copy. No schema. No author. No publish date. Nothing for an answer engine to read, summarize, or cite.
This is the AEO visibility problem in a single command. It is the most consequential SEO issue most marketing teams have never tested for, and it is silently excluding well-resourced brands from the conversations being had inside ChatGPT, Perplexity, Claude, and Google AI Overviews.
The good news: it is solvable. The harder news: the solution is architectural, not editorial. No amount of better copy, more backlinks, or richer schema will fix a page that the crawler cannot read in the first place.
This article explains exactly why this happens, how to diagnose it on your own site in five minutes, and the three viable paths to fix it — with the trade-offs each one carries.
### Why this matters now
For two decades, search optimization meant ranking on a list of blue links. The unit of success was a click. The crawler that mattered was Googlebot.
That world is fragmenting fast. A growing portion of high-intent research now happens inside conversational interfaces that synthesize an answer rather than return a list. ChatGPT processes hundreds of millions of queries a week. Perplexity is being adopted as a default research tool by analyst teams, consultants, and procurement leads. Google AI Overviews now sit above the traditional results for a substantial share of commercial queries. Claude is increasingly used inside enterprises for vendor research and technical evaluation.
The unit of success in these interfaces is not a click. It is a citation. When a buyer asks an answer engine "who are the best AEO consultancies in Europe?" or "what is the difference between SEO and AEO?", the engine composes a response from sources it has indexed, and it names some of them. Being named is the new ranking. Not being named is the new page two.
The crawlers behind these systems are not Googlebot. They are GPTBot (OpenAI), ClaudeBot and Claude-Web (Anthropic), PerplexityBot, Google-Extended, and a dozen smaller ones. They behave differently from the crawler your SEO tooling is designed around. Critically, most of them do not execute JavaScript reliably, do not wait for client-side hydration, and do not return for a second pass.
If your site only renders its content after JavaScript runs, these crawlers see your blank shell — and they move on. Your authority, your insight, your case studies, your schema markup all exist only inside a black box they never opened.
### The technical root cause
To understand the fix, you have to understand exactly what is happening on the wire.
A traditional server-rendered website works like this: the browser asks for a URL, the server runs application logic, queries a database, composes the full HTML for that page, and sends it back. Everything visible to a human is also visible in the raw HTML response. The browser then enhances that HTML with CSS and JavaScript, but the content is already there.
A single-page application works differently. The server returns the same minimal HTML file for nearly every URL — a shell containing a script tag and an empty `
`. The browser downloads a JavaScript bundle, executes it, fetches data from APIs, and constructs the page in memory. Content appears only after this process completes, sometimes seconds after the initial response.
A human with a modern browser does not notice this. They see a brief loading state, then the finished page.
A crawler is not a human. A crawler issues an HTTP request, receives the response, and parses what it gets. Whether it then executes the JavaScript bundle to discover what the page actually contains is a choice — one made by the crawler operator, weighed against compute cost, latency, and the number of pages they need to index.
Here is how the major crawlers currently behave with respect to JavaScript execution. Treat this as a directional snapshot rather than a contract — these systems change quietly and frequently:
| Crawler | Operator | JavaScript execution | Practical implication for SPAs |
|---|---|---|---|
| Googlebot | Google Search | Yes (deferred, second pass) | Eventually sees content, often with delay |
| Bingbot | Microsoft / Bing | Yes (limited) | Mostly sees content |
| GPTBot | OpenAI / ChatGPT | No reliable execution | Sees the blank shell |
| ClaudeBot | Anthropic | No reliable execution | Sees the blank shell |
| PerplexityBot | Perplexity | Limited | Often sees the blank shell |
| Google-Extended | Google AI / Gemini training | Inherits Googlebot behavior, opt-in | Eventually sees content |
| LinkedInBot | LinkedIn previews | No | Blank shell — broken social previews |
| Slackbot, Twitterbot, FacebookExternalHit | Social previews | No | Blank shell — broken social previews |
The pattern is clear. The traditional search crawlers have invested heavily in JavaScript execution because their commercial model demands it. The newer AI crawlers and the social preview bots have not. They prioritize breadth and freshness over completeness on individual pages, and they assume that any site that genuinely wants to be indexed will return meaningful HTML on the first request.
This is not an oversight. It is a design choice. And it is unlikely to change soon, because executing JavaScript at the scale these crawlers operate at would multiply their infrastructure costs by an order of magnitude.
The takeaway is uncomfortable but precise: if your content is not in the HTML that comes back from the first HTTP request, you should assume AI crawlers cannot see it.
### How to diagnose your own site
Before deciding on a fix, confirm you actually have the problem. Three tests, five minutes total, no tools required beyond a browser and a terminal.
#### Test 1: The curl test
This is the definitive test. It shows you exactly what a crawler sees, with no JavaScript involved.
```bash
curl -s -A "Mozilla/5.0 (compatible; GPTBot/1.0)" \
https://yoursite.com/your-most-important-page \
| head -100
```
A healthy result contains your headline, body copy, structured data, and meta tags in readable HTML. A broken result contains a `` (often generic), a few meta tags, an empty `