006 · Website Optimization

What this is

Bet 1 of the H2 plan, as the program of record: focused website optimization — a site that converts the audience it earns. The site still attracts a large audience, but AI answer surfaces are eroding it, and we convert too little of what arrives; this program fixes the conversion side with one prioritized queue in four phases, live in Asana with owners and tasks. The scope is defined by the Website v1 design project — 16 page templates covering ~103 pages on a six-chapter spine (01 Platform → 02 Build → 03 Deploy → 04 Solutions → 05 Start → 06 Compare — build-then-deploy order ratified with Shafiq Sep 1) — timed to the October platform launch, with Woolly Mammoth as the build partner through launch and the two-seat web team plus Verto hours carrying it after. The Sitemap is both the page-by-page map and the design snapshot — every template and page links straight into the design directory.

Goal: turn the approved scope into shipped pages that convert — leads, opps & pipeline plus product sign-ups, reviewed weekly against core KPIs, with every treated page measured for lift against a locked baseline.

The outcomes (the capital-investment answer): three, kept simple. Conversion rate up across every conversion point — lead forms and product sign-ups both. Hand-raiser volume up — more pages built to produce them, more offers worth asking for. Traffic rebuilt as brand equity in new-product terms — owning agent memory, semantic cache, and the head terms the map assigns, instead of renting the brand term. Gate: starting-point benchmarks locked with Reet before any lift claims (ratified with Shafiq, Sep 1).

The direction

We are leaning back into product: clear, consistent messaging, closer to our technical roots, and a site designed to show, not tell.

• Product and platform pages convert, visibly. We are updating the pages and the overall UX across every product/platform surface so CTAs are so visible it is hard *not* to convert — every page pushes a clear conversion at all times.
• Standardized templates do the optimizing. We accomplish this through standardized templates that optimize for conversion on each page type — engineered once, inherited by every page.
• More ways for traffic to convert. We are creating additional offers on both tracks: self-service (the interactive demo/guided tour, the MCP server) and enterprise offers built to appeal to larger teams and more complicated buying cycles.
• Every new page owns a head term. All new pages in the sitemap map to a major head term (vector database, semantic cache, and so on), assigned from the content & keyword map below — one page per term, so pages never compete with each other and coverage gaps are visible.
• Destinations make the most of what we already earn. The web destination redesigns — Glossary, Downloads, Insight, Resource Center, Blog, and Compare/Why Redis — focus on our existing high-traffic assets: recapture traffic, build new assets, and transform these sections into improvements.
• Schema and markup that machines can read. Structured data and markup on every page, so answer engines, assistants, and coding agents can parse, cite, and recommend what we publish — legibility for the surfaces where discovery now happens.
• Agentic web development is the only way to move this fast. Modular page components assembled by agentic development, so new pages ship at agent speed and stay on brand by construction — the components carry the brand, not the reviewer.
• The Build chapter captures demand strategically. Build pages exist to capture traffic for features, products, and capabilities in a deliberate way — each primer a landing surface for the queries that matter, with a real next step on every page.

Why now

Two curves are crossing, and the website sits at the intersection.

Traffic is falling. AI Overviews now answer many of our queries before the click:

• Organic clicks −40.4% YoY while impressions are +75.9% — visibility without visits.
• Sitewide CTR collapsed 5.72% → 1.94% even as rankings improved.
• Base case: ~854K more clicks lost over the next four quarters (204K–1.56M range) if nothing changes.
• No rank headroom to buy it back — most traffic already sits at positions 1–3. We cannot rank our way out of this.

Goals are rising. The quarter already asks for $21.5M sourced pipeline, 345 SAOs, and 70K product signups, and the growth targets step up again from here.

Fewer visits against bigger numbers leaves exactly one lever: the conversion rate of every visit that still lands. The timing is set — the October platform launch is the immovable anchor, the taxonomy and page map exist, the templates are designed, and the build workflow (Phase 04) makes ~100 pages feasible inside the window.

The five phases

• Phase 0 · The template system — the 16-template build that carries everything after it.
• Phase 01 · Product & platform — the product and platform pages rebuilt show-first, with conversion impossible to miss.
• Phase 02 · Offers & flows — four new offer pages, four existing flows optimized.
• Phase 03 · Destinations — the six traffic-carrying pages rebuilt to convert.
• Phase 04 · Foundations & measurement — redirects, GA4, tracking standards, the LP system, and the build workflow.

Phase 0 · The template system

Goal: every page type built once as a template, so every page after is a content pass — one platform story, told consistently across ~103 pages, shipped for the October launch.

The system is the capacity answer: one template per page type, one shared copy source (nav, spine, products, use cases, proof points, CTAs — change it once, every page updates), and one token system with zero hardcoded hex, which is what keeps the Storybook contract and every hand-off safe.

Where the system lives:

• Storybook — every template ships as coded components; the shared source of truth between web engineering and brand (the component contract section below).
• Figma design system — maintained with the brand team; tokens bind design to code, so a brand change propagates through every page instead of forking per page.
• Production speed — once a template exists, a new page is a content pass, not a design cycle: a page in minutes, a section in a day, a redesign in a week. That speed is what makes ~103 pages feasible inside the launch window, and what keeps the site operable after WM's exit on the two-seat web team plus Verto hours.

The locked design decisions travel with the templates: TT Trailers all-caps H1s, sentence case, verb-first CTAs, every CTA routing to Get Started, mega-menu navigation, Compare off the top nav, the speaker-spotlight motif, and the magazine treatment on editorial pages. Design-stage gates clear as content work on the templates: figures validated, the 42 Solutions snippets engineer-reviewed, customer outcome lines migrated, logos dropped in.

Deliverables — the 16 templates, in two classes. Every template has its own scope page — the layout mock, what the page does, and the components on it — linked below and from the Templates page.

Section templates

Built once, they render a whole class of pages — this is where the leverage lives. Each new page on a section template is a content pass, not a build.

• Platform Product — one template · 7 product pages (LangCache, Context Retriever, Agent Memory, Data Integration, Flex, Search, Feature Store). Scope →
• Build — chapter 02 hub + 9 capability primers in one template family (caching, streaming, vector database, semantic search, RAG, semantic cache, NoSQL, auth token storage, data deduplication), each with How it works, starter packs, blog cross-links, and case studies. Scope →
• Solutions detail — one fixed 10-section spine · 14 sub-pages (3 apps, 6 workloads, 5 industries), each with an assigned A1–A6 proof visual. Scope →
• Deploy — one template across the deployment set: three options (Cloud recommended), the marketplace paths (AWS, Azure, Google Cloud, Snowflake, Vercel), responsibility matrix, "what never changes." Scope →
• Why Redis — the template for direct, criteria-led comparison pages — the shape every future competitor page reuses. Scope →
• Customers — magazine treatment: cover story, sticky filter bar — renders the whole customer-story roster. Scope →
• Glossary — the AEO-ready term template behind every glossary page (Phase 03 carries the spec). Scope →
• Blog — corporate / engineering / AI — magazine treatment, technical-publication structure, per-post product-sign-up CTA — one template family rendering every post across all three surfaces. Scope →

Single pages

Designed once as one-off experiences — the narrative anchors and the conversion chapter.

• Homepage — the one-platform story, rebuilt from below the fold up. Scope →
• Redis Platform — chapter 01 hub: the platform narrative. Scope →
• Solutions — chapter 04 hub: apps, workloads, and industries, mapped. Scope →
• Compare — chapter 06 anchor: criteria-led comparison, off the top nav by design. Scope →
• Get Started — the single destination every CTA links to. Scope →
• Demo — talk to an expert · see a demo. Scope →
• Pricing — the numbers page, feeding the Pricing → Configure flow. Scope →
• Offers — chapter 05 anchor: the offer hub. The four offer pages themselves are Phase 02's page experiences, spec'd below. Scope →

Phase 01 · Product & platform

Goal: the product and platform pages convert, visibly — pages and UX updated across every product/platform surface so CTAs are so visible it is hard *not* to convert, with every page pushing a clear conversion at all times.

The locked direction is show-first on the CTA kit: lead with the product running, code in position two, claims demoted to captions on proof, and the same four CTA placements on every page (hero primary + tour ghost · inline try-it after the snippet · contextual secondary after the metrics · closing band). Every primary routes to Get Started; conversion visibility is measured, not asserted — each treated surface reads against its locked baseline.

The seven product pages

Rebuilt show-first on the Platform Product template: a three-beat hero demo (~20 seconds, replayable), a Wire-it-in snippet in position two, three capability beats, a live-styled metric strip, an enterprise note, and cross-links into Build, Solutions, and sibling products. The content pack is written — each page is now a content pass, with working headlines:

• LangCache — "Stop paying twice for answers": semantic caching for LLM calls, the spend counter as the hero proof.
• Context Retriever — "The context your agent asks for": hybrid retrieval tuned for context windows, not results pages.
• Agent Memory — "Agents that remember": durable memory with relevance recall, inspectable by design.
• Data Integration — "Your databases, streaming in": continuous CDC with zero pipeline code, lag on screen.
• Flex — "Big memory, small bill": DRAM + SSD tiering with the same commands and a falling cost counter.
• Search — "Search your live data": vector, full-text, and geo in one query, indexed live.
• Feature Store — "Features, served online": one definition, served at request-path speed with visible freshness.

Head-to-head on every product page (added Sep 1) — each product page carries a comparison module ("Agent Memory vs. the alternatives") cross-linking into the Compare chapter, so the comparison shopper gets the answer here instead of Googling it — and answer engines get a citable, criteria-led comparison per product.

Flags that travel with the pack: metric-strip numbers illustrative pending PMM + Data review, every snippet gated on engineer validation, product names under the naming gate.

The platform story pages

The narrative surfaces that set the frame every product page inherits, on the same show-not-tell bar:

• Homepage — the one-platform story rebuilt from below the fold up: proof band, five-product stack, audience paths, industry proof strip, every scroll earning the next one. Scope →
• Redis Platform hub — the chapter 01 anchor: the platform thesis told properly, the router into all seven product pages, and the consolidation proof (one platform, one client, one SLA). Scope →
• One narrative, enforced — both pages draw from the shared content module, so the platform story never forks between the homepage, the hub, and the product pages beneath them.

The Build chapter — strategic capture

The 9 capability primers exist to capture feature/product/capability traffic deliberately — each primer a landing surface for the queries that matter, not a docs page with a logo:

• Query-mapped coverage — caching, streaming, vector database, semantic search, RAG, semantic cache, NoSQL, auth token storage, data deduplication: the capability terms buyers and builders actually search, each owned by one primer.
• Machine-legible by construction — schema, structured sections, and citation-ready markup on every primer, so answer engines and coding agents can parse and recommend them (the direction's legibility bullet, applied).
• A real next step on every page — starter packs and validated snippets route into Get Started; no primer dead-ends into prose.

Measured like everything else

Product and platform surfaces carry locked baselines from Phase 04's measurement stack; the conversion-visibility bar ("hard not to convert") is proven in lift on treated pages, and the CRO agent inherits these surfaces as its first test queue in November.

Phase 02 · Offers & flows

Goal: replace "book a meeting" with offers worth asking for, and rebuild the four paths high-intent visitors already take so they finish. Each of the eight below is a page or multi-page experience, not a template — the offers are single pages built on the template system; the flows are multi-step experiences that span pages and systems. Every experience has a scope page with its mock on the Templates page (Phase 02 section). Every offer on a page is a promise sales fulfills — fulfillment owners lock before pages launch (Decision 03, with the Spencer/Jon/Simba review), and the agentic offers depend on the chartered product roadmap with Jon (MCP, agentic database creation).

Free Redis Corporate MCP

The agentic hook: a free, useful MCP that puts Redis inside the buyer's own AI workflow. Converts evaluation intent into hands-on usage and gives sales a warm, technical follow-up.

• Offer page on the Offers template with agreed positioning and packaging
• Fulfillment path: delivery, activation tracking, and the sales/SDR follow-up owner
• Product dependency cleared with Jon before launch
• Scope + mock →

AI Architecture Advisory

Expertise as the offer for teams designing agentic systems — a structured advisory session that earns the architecture conversation instead of asking for a meeting.

• Offer page + intake with qualifying project details
• Named SE/advisory owners and a per-session deliverable format
• Routing into the scored-account motion (72-hour treatment)
• Scope + mock →

Cloud Migration Plan

Captures active migration intent with a concrete deliverable: a tailored plan for teams moving off a competitor or self-managed setup.

• Offer page paired with competitor/comparison paid campaigns
• Assessment workflow: inputs → plan document → SE review
• Fulfillment owner in sales + SLA from request to delivered plan
• Scope + mock →

Enterprise Product Trial

The high-intent evaluation path for accounts that outgrow self-serve — a structured trial with success criteria and white-glove support.

• Offer page + qualification gate
• Trial provisioning path with named CS/SE ownership
• Conversion tracking from trial to opportunity
• Scope + mock →

Flow · Pricing → Configure

Pricing stops dead-ending in a table: it transitions into a "Configure Redis" experience that turns price-shopping into scoping.

• Configure experience designed and built on the Pricing template
• Config inputs carried into the hand-raise (no re-asking)
• Shipped behind a test against the current pricing page
• Scope + mock →

Flow · Demo request

The demo path splits by who's asking: personalized demos for new logos, interactive tours for customers.

• Routing logic by relationship status
• Interactive tour experience stood up for the customer path
• Meeting quality tracked to the CPL meeting program
• Scope + mock →

Flow · Cloud + Iris sign-up

The sign-up and initial onboarding experience rebuilt to finish — the front door of the product funnel (hands off to the Signup Activation Journey post-signup).

• Sign-up UX pass on both flows
• Onboarding first-run improvements to first-value
• Baseline → test → measured lift on completion rate
• Scope + mock →

Flow · White-glove follow-up

Product sign-ups from high-value accounts get human treatment: detection, routing, and a personal follow-up commitment.

• High-value detection rule (scored accounts × sign-up events)
• SDR/AE follow-up play with an SLA
• Measured on sign-up → conversation → opportunity
• Scope + mock →

Phase 03 · Destinations

Goal: the pages that carry most of the site's organic value, rebuilt to convert it — each shipped against a locked baseline with measured lift. One method across all six: schema and structure for AEO, a real next step on every page, hub-and-spoke where topical authority matters, WCAG remediation riding the same build.

Glossary

Regain the traffic AI Overviews absorbed and become the cited definition source. Every page gets a keep / fix / retire verdict plus an expansion plan; depth an answer box can't replicate.

• Verdict pass on all pages + expansion list for missing terms
• Schema markup, images, and video on kept/fixed pages
• Citation share tracked on Profound against baseline

Downloads

The disjointed download-to-docs dead-end becomes a flow: capture what the visitor is building, cross-sell Cloud, and hand off into get-started.

• Project-details capture with privacy-friendly tracking
• Redis Cloud cross-sell CTAs in the flow
• Guided get-started handoff replacing the docs dead-end

Insight

The Redis Insight page sells the desktop GUI experience — show it, don't describe it — and promotes the platform around it.

• GUI showcase hero with real product visuals/interaction
• Feature story: visualize · query · debug
• Product sign-up routing + platform tie-ins

Resource center

Reorganized from formats to topics: hub-and-spoke topical authority for SEO and AEO, mixed content per hub.

• Topic taxonomy + hub pages with mixed-content spokes
• Schema across hubs; series rails retained
• Phased build plan (the original build ran multiple sprints — sequence accordingly)

Blog

Relaunched as a technical publication: named series, editorial structure, and a conversion path on every post. Three surfaces — corporate, engineering, and AI (the technical publication for AI builders — not AI slop; naming of the engineering surface vs. "developers" is an open call). The play is Cloudflare's: our people write, are proud of it, and share it — capture the internal enthusiasm to publish instead of the growth-x volume model.

• Named-series architecture replacing high-velocity text-only
• Topic hub pages as the ranking play — tag-driven hubs targeting the commercial LLM terms (context engineering, LLM cost, RAG + vector): as content accumulates per topic, the hub cross-promotes it ("10 articles on cutting LLM cost") and earns the head term
• Multi-team publishing model — dedicated spaces and a feeling of ownership per team (engineering, product, even talent), with an editorial bar that keeps it authoritative
• Customized product-sign-up CTA on every post; featured blog content surfaces dynamically on relevant site pages (Build primers, homepage)
• Cross-links from the refactor's build sections feeding it; a dev-rel video series rides the Build primers (ship without video, add video after)

Compare / Why Redis

The comparison page buyers keep looking for: direct, credible, criteria-led — paired with paid search so competitor-term campaigns land somewhere that converts. Off the top nav by design (footer + chapter spine).

• Why Redis page + criteria-led comparison table
• The "Redis versus" concept — one dropdown-driven surface (Redis vs. cloud/software/open source, Redis vs. everything else), organized by the trending categories answer engines pick up on: agent memory, cache, vector database
• Existing competitor pages re-evaluated and made direct; the per-product head-to-head modules (Phase 01) feed into and cross-link this chapter
• Message-matched with the paid competitor campaigns

Docs — flagged, cross-team: ~40% of site traffic, managed by a separate team; the re-alignment toward a "get started" experience with project templates needs scope confirmed with the docs team.

Phase 04 · Foundations & measurement

Goal: make the other three lanes measurable and fast — trustworthy numbers, one convention, and a build pipeline that ships weekly.

Redirect map

• 807 URLs mapped, verified by re-crawl, index junk removed
• Day-30 bar: the redirect map is live

GA4 sign-off

• Bots out, key events in, B2B event taxonomy replacing e-commerce defaults
• A published sign-off that site data is trustworthy end to end — the artifact baselines lock against

Conversion loop

• Online + offline conversion tracking (CAPI + Marketo OCT) feeding value-attached conversions back to the platforms
• Day-30 bar: real values feeding bidding

Tracking standards

• One convention for UTMs, event names, and campaign taxonomy, aligned with the warehouse joins

Landing page system

• High-intent, message-matched LPs built through the workflow, replacing bare get-started forms (delivered with the Website & Landing Page Development Workflow project)

The build workflow

• Component library v1 + the nine-step brief-to-production pipeline with brand review built in
• A template per page type; the day-30 bar: the queue shipping weekly
• The web request process — intake to scoped brief to shipped page — documented in the workflow section below

The workflow & LP system (merged Sep 5 — was 007 · Workflow & Component System)

The pipeline every page ships through: the web request process at the front, the GitHub + Storybook development workflow and component library in the middle, and the high-intent landing-page system coming out the other end — the AI-enabled production rail that makes ~100 refactor pages, per-campaign LPs, and weekly shipping feasible with a two-seat web team. A page moves from brief to production in days; the queue ships weekly instead of piling up. Ad-hoc requests are discontinued (Jul 28) — all work enters through planning.

The web request process

Every page request follows one path — intake to a scoped brief to a shipped page. This is the workflow's front door; nothing enters the build rail without passing through it.

• 1 · Request intake — two entry points, one door: a digital/growth team request, or an internal request from stakeholders. Both land in the planning session, not in someone's DMs — the July rule (no ad-hoc work) is enforced here, at intake.
• 2 · Scope defined — an agent puts the request into the web brief template: goal, audience, baseline data, and the campaign activation deliverables it needs — landing page, supporting campaign pages, forms & conversion paths, and tracking & measurement setup. A request without a measurable goal gets bounced back at this step, not at build.
• 3 · Proposal — the requester gets back a brief + page wireframe proposal with directional copy and an image/illustration request attached, then review, revise & accept. Acceptance is the commitment point: scope is locked, and changes after this re-enter at intake.
• 4 · Build — the Figma ⇄ Storybook loop: the design system manages components and templates, so the build is assembly on the rail below, not custom work. Ships through staging QA to production with its tracking live on day one.

#### Who holds what

• Requesters (any team) bring the goal and the deadline; the planning session triages priority.
• The agent drafts the brief and the proposal skeleton — throughput, not judgment.
• Nash / Alexis / Scott hold the judgment steps: triage at intake, proposal review, and the scope-lock.
• Scott's pod (Stalin, FSD 1 from Nov, Content Manager line) builds on the rail; brand review runs inside the pipeline; staging QA is the mandatory gate (ratified Jul 30).
• Turnaround bars — set from the first measured cycles rather than promised upfront; the day-30 bar is the queue shipping weekly. [owner to complete]

The pipeline, per piece

• The nine-step brief-to-production workflow with brand review built in — brief with goals and baseline data → AI content draft from existing material → automated brand review against guidelines → design mockups → coding-agent build → manual QA on staging (the mandatory step, ratified Jul 30) → publish, measure, iterate. Humans hold the judgment steps; agents hold the throughput steps.
• GitHub workflow + Storybook utilization (Month 1) — the development rail the team and contractors share, on the component library contract (zero hardcoded hex, tokens only) that makes hand-offs safe.
• The template system — a template per page type (Website v1's 16), so every new page is an instance; the content-creation agent (AI agent build, M1) drafts against them.
• Ad-level landing pages + testing strategy (Month 2) — the LP system replacing bare forms: message-matched pages at the ad level, every LP shipping with a test attached, built through the same pipeline. This is Phase 04's landing-page system delivered.
• Personalization, popups, and user flows (Month 3) — on-site personalization, popups, and the sign-up user flows, riding the same rail.
• CMS continuity — Kevin hands CMS publishing off Sep 30; Stalin plus Verto hours bridge until the Content Manager and FSD 1 land (Nov), on the Sanity + Next.js stack.

The component contract (was Design System / Component Library)

The Storybook library documented, governed, and consumed by the Website v1 template system — the contract that lets a two-seat web team, contractors, coding agents, and an exiting build partner all produce the same site. WM implemented Storybook (March) and hands over governance before the Oct 31 exit; governance, not more components, is the exit deliverable.

• Ownership + update process documented (Month 1) — who owns each component, how changes propose/review/land, aligned with the design refactor (Allison, Claudia, Regine) so design and code stop diverging. This is the WM exit condition — treat the doc as the hand-off artifact.
• v1 component documentation published (Month 2) — every approved component documented: variants, states, tokens, usage. Cleanup on the way in per the Aug 31 alignment (utilization data from Scott; new components designed around what AI engines consume well).
• Approved components migrated into production templates (Month 3) — the Website v1 templates consume the documented set; anything undocumented doesn't ship. Versioned releases (v1, v2 …) per the Claudia/Regine process so every toolkit push to Scott is traceable.

The content & keyword map

Goal: one map connecting every URL we have to every keyword that matters — the shared input each phase draws from, so page decisions stop being judgment calls and start being lookups.

The pipeline, in order:

• Clean Sanity export — every live page URL on the site, exported from the CMS. Scott owns the export; it is the ground truth of what exists today.
• Merge the demand data — Ahrefs + Google Search Console + paid media keyword data joined onto the URL list, so every page shows what it ranks for, what it earns, and what we bid on against it.
• Keyword-to-content mapping — the merged set mapped across all pages and sections of the website: every new page in the sitemap assigned its major head term (vector database, semantic cache, and so on), cannibalization flagged, coverage gaps surfaced as the new-page queue.
• Deep-directory review — blog, resources, glossary, and the other deep content directories reviewed against the map: keep, fix, consolidate, or retire per URL. This feeds the Phase 03 verdict passes directly.

Ownership: Nash + the incoming agency drive the map, Verto SEO/AEO hours support the analysis, Scott delivers the Sanity export.

The campaign directory

A hidden directory (working path `/c/` — noindex, excluded from sitemap.xml, full analytics) becomes the home for every other digital campaign surface, built on the same templates and the Phase 04 LP system so campaign pages inherit the conversion engineering:

• Paid search & paid social — query-matched and creative-matched landing pages, message-matched to their campaigns.
• Newsletters & email programs — signup, issue, and lifecycle destinations that stop borrowing pages built for other jobs.
• 1:1 ABM for Redis500 — personalized pages per target account on the Redis500 list, assembled as content passes on the template system.
• Referral campaigns — co-branded pages for influencer and partner campaigns, with tracked links, riding the same directory. This is a new motion: referral-based demand from voices the audience already trusts.

The directory keeps campaign surfaces out of the crawlable architecture (the six-chapter spine stays clean) while every campaign gets a purpose-built page instead of a compromise.

Work to be done

• The template system shipped for the October launch — 16 templates built on the six-chapter spine, ~103 pages migrated as content passes, design-stage gates cleared (figures validated, 42 snippets engineer-reviewed, customer outcomes migrated, logos in), through staging, WCAG 2.1 AA remediation, and launch-readiness QA before the Oct 31 WM hand-off.
• Product & platform converting visibly — the seven product pages live show-first on the CTA kit, the homepage and platform hub on the same bar, and the Build chapter capturing its mapped queries — every treated surface measured for lift against its locked baseline.
• Offers & flows converting — the four offer pages live with locked fulfillment owners, and the four high-intent flows rebuilt and shipped behind tests, the first live by day 90.
• Destinations rebuilt to convert — all six destination specs above shipped to their agreed structure, each measured for lift against a locked baseline, with citation share moving on the AEO surfaces.
• The content & keyword map live — the Sanity URL export merged with Ahrefs, GSC, and paid keyword data, keyword-to-content mapping across every page and section, every new sitemap page carrying its head term, and the deep directories (blog, resources, glossary) reviewed against it with per-URL verdicts.
• The campaign directory standing — the noindex `/c/` directory serving paid search, paid social, newsletter, email, and Redis500 ABM pages on the template system, with the first influencer and partner referral campaigns live on it.
• The rail live end to end — GitHub + Storybook workflow operating, component library v1 published, the nine-step pipeline running with the QA gate — and the queue shipping weekly (the day-30 bar).
• The LP system in production — ad-level, message-matched landing pages with the testing strategy attached, replacing every bare get-started form paid traffic lands on today.
• The experience layer shipped — personalization, popups, and rebuilt sign-up flows running through the pipeline with measured lift.
• The ownership doc shipped — component ownership and update process documented and agreed with the design refactor team; the WM exit condition.
• v1 component docs published — the documented component set live for design and dev, feeding the template builds.
• Production migration complete — approved components in the production templates, undocumented ones retired or documented.

Current state

Build in flight against the v1.1 scope; the queue lives in Asana with owners and tasks per lane. The taxonomy is ratified and the Website v1 design snapshot is in this hub (updated as the design iterates). WM notice Oct 1, exit Oct 31 — after the platform launch; launch-month testing rides Verto's bank of hours and the coding-agent workflow absorbs the capacity risk.

Dependencies & risks

• The October launch is the immovable anchor — slippage compresses QA onto Verto hours and the two-seat team.
• Offer pages gate on PMM alignment (Decision 03) and the Spencer/Jon/Simba review; the agentic offers gate on the product roadmap with Jon.
• Product naming needs clear separation before launch — answer engines repeat whatever we publish (PMM + comms).
• The platform narrative supplies the words on the page — structure ships regardless. [owner to complete]
• Chapter naming needs one meeting — Build vs. Solutions vs. "use cases" (Nash + Shafiq + Jeff + Allison); the blog surface naming (engineering vs. developers) rides the same conversation. Nav *order* is decided (Platform → Build → Deploy → Solutions, Sep 1); Jeff read-back follow-up in flight.
• The agentic outcome needs exec alignment — the Olga conversation (product side, ~3 weeks) defines the agentic-database-creation outcome the agentic offers build toward; exec circulation follows.
• Developer marketing is now a named partner — agent recommendation (AEO from the advocacy/content side) assigned to dev marketing (Sep 1) with a close partnership into this program; docs stays product-owned (Michelle partnership) with accountability held through dev marketing.
• Socialize beyond marketing — waterfall shipping means changes land continuously; keep the wider org informed on what changed and why (the blog is a known hot-button), without turning it into an approval gate.