Your Website Needs a Brain  🔗 **Source:** [Your Website Needs a Brain](https://www.jonoalderson.com/conjecture/your-website-needs-a-brain/) > [!note]+ Document Notes > --- > tags: [content-modeling, cms-architecture, ai-site-generation, static-publishing, technical-seo, structured-data] > author: Jono Alderson > source: jonoalderson.com > reference: https://www.jonoalderson.com/conjecture/your-website-needs-a-brain/ > date created: 2026-10-04 16:16 > --- > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > [!warning] Source note. This is a 2,910-word essay (Reader count; an independent count of the stored text gives 2,923) published 2026-10-04 in the "Conjecture" section of jonoalderson.com. It contains 10 links: 8 are self-anchors on its own H2 headings, 1 points to Alderson's earlier post "There are only four sensible ways to build a website," and 1 points to Google Search Central's JavaScript SEO basics. Neither external link was fetched for this analysis. The essay names Yoast, WordPress and Drupal; Reader's metadata gives no author bio, and this analysis doesn't assume Alderson's employment history. The vault's wp-governance wiki records Alderson's appointment to The WPOCC board in February 2026. The essay uses "they/their" for its example author, Jane, and this analysis does the same. No pronouns are assumed for Alderson. > # 🏷️ Title: Your website needs a brain > ## 🧭 Table of contents > - [📝 Summary](#-summary) > - [📖 Main content](#-main-content) > - [🗒️ Notes](#️-notes) > - [📚 References](#-references) > - [🗣️ Paraphrase](#️-paraphrase) > - [📰 Newsletter](#-newsletter) > - [✅ Action items](#-action-items) > - [🧪 Hypotheses](#-hypotheses) > - [📊 Methodology](#-methodology) > - [❓ Questions](#-questions) > - [🔮 Future research](#-future-research) > - [💡 Implications](#-implications) > - [🧠 Learning styles assessment](#-learning-styles-assessment) > - [📊 Accessibility assessment](#-accessibility-assessment) > - [🌍 DEIB assessment](#-deib-assessment) > - [✅ Logical validity](#-logical-validity) > - [🛡️ DARVO analysis](#️-darvo-analysis) > - [🎯 Conclusion](#-conclusion) > ## 📝 Summary > - **What happened.** Jono Alderson published "Your website needs a brain" on jonoalderson.com on 2026-10-04: 2,910 words, about an 11-minute read per Reader, in an introduction plus 8 H2 sections. It follows one running example, an author named Jane, through a site rebuilt page by page with an AI prompt instead of a CMS. > - **The claim.** Generating pages with AI reproduces what a site looks like but not the relationships behind it: shared records, dependencies between outputs, and publishing rules. A CMS holds that model. Replace the CMS and you either rebuild the model on purpose or rediscover it through broken behavior. > - **Why it matters.** The failures Alderson lists land on machine-readable outputs people rarely inspect: XML sitemaps, hreflang annotations, canonical URLs, schema, feeds, paginated archives and redirects. Those are what search engines, feed readers and LLM retrieval tools read. A site can look correct to a human visitor while telling machines something stale or contradictory. > - **Key stakeholders.** Site owners tempted to swap a CMS for prompts; teams building static or headless front ends; editors who change records without knowing every place they appear; SEO and structured-data practitioners; WordPress, Drupal and plugin maintainers (Yoast and multilingual plugins are named) whose accumulated behavior the essay credits; and anyone building AI checkers for websites. > - **Risks and tradeoffs.** Alderson concedes that a custom AI-built CMS can be the right call for a deliberately scoped organization with the expertise to maintain it. The essay offers no data on how often page-by-page builds fail, and its static-publishing options (full rebuild, scheduled rebuild, client-side fetch, dependency-aware pipeline) get qualitative costs only. It also grants that established platforms ship wrong defaults and conflicts. > - **Bottom line.** Before replacing a CMS, trace ordinary edits (product availability, an author update, a withdrawn translation, an indexing change) through the existing site and list every output that responds. Those behaviors are requirements, whether or not anyone wrote them down. The essay's closing test is one a team can run in an afternoon. > ## 📖 Main content > - **The setup (introduction).** A team escapes a frustrating CMS by building each page from a prompt: homepage, service pages, about, blog. An author profile and a per-post author box both get Jane's photo and biography. When Jane revises the bio, the profile updates and the author boxes don't, because the two copies were never linked. Alderson's diagnosis: page-by-page building reproduces everything visible "without recreating the connections which made it manageable." > - **Shared records (An author is more than an author box).** The fix is a reusable author component reading one stored record. That record then has to support a list of the author's articles, an archive, pagination, an author feed and the article's structured data. The same pattern applies to products, services, categories and assets. Product availability appears on detail pages, category listings, structured data and shopping feeds. A URL change ripples into navigation, breadcrumbs, related-content modules and contextual links. Titles, descriptions, social metadata, canonicals and schema often derive from the same records. The system needs to know where information belongs, which outputs depend on it, and where someone has supplied a deliberate override. > - **Identity and URL change (Then Jane changes their name).** Jane marries and changes surname. The shared record updates bylines and the profile, and structured data should keep identifying the same person. A new author URL means redirecting the old address, every paginated archive page (/author/jane-smith/page/2/ and onward), updating canonicals and the XML sitemap, regenerating pagination links, and keeping the author feed reachable for existing subscribers. The component can work while page 2 of the archive breaks and the sitemap lists the old URL. The person editing a colleague's profile may never think about paginated redirects. > - **Publishing architecture (You may also have changed how publishing works).** A database-backed CMS renders from current data and invalidates caches when records change. Static HTML holds whatever was true at build time, so updating Jane's record changes nothing already deployed. The options: rebuild everything on each change (fine small, costly as content grows), rebuild on a schedule (stale between runs), or fetch data in the browser (another network dependency, possible layout shift, and a crawling requirement; Google renders JavaScript, but crawlers and LLM retrieval tools that don't run it see the initial HTML). A dependency-aware static pipeline can work, but dependency tracking, timed rebuilds and cache refresh then belong in the architecture. Alderson links an earlier post arguing static builds suit "relatively simple, stable sites." > - **Sitemaps as the clearest case (The sitemap needs to follow the decision).** Noindex an article at 09:00 with a midnight sitemap rebuild and the sitemap advertises a URL the page says not to index for 15 hours. Hourly rebuilds shrink the gap but keep it. The fix doesn't require a database query per sitemap request: update the generated file or invalidate the cache as part of publication. Crawling your own site to build the sitemap reconstructs state the system should already hold; crawl to audit, not to discover. Noindex, withdrawal and login restriction are different decisions with different consequences for navigation, archives and feeds, and a URL list can't distinguish them. Hreflang works the same way: publishing or withdrawing a French translation changes what every sibling page should advertise, including pages nobody edited. > - **Checks need a model too (Checking every page still requires a model of the website).** Pre-publication AI checks and post-deploy crawls help, but a page can pass inspection and still contradict the system. Examples: a valid, resolving canonical that names the w 📄 **Full text:** [[Full Document Contents/Articles/Your Website Needs a Brain.md|Your Website Needs a Brain by Jono Alderson]] ## Highlights - That’s easy enough to fix. But it illustrates a problem with building websites one page at a time: you can reproduce everything you can see without recreating the connections which made it manageable. ([View Highlight](https://read.readwise.io/read/01m44965ktqhbjkvp66bbf494k)) - Note: [H1] Page-by-page builds copy visuals, not connections - Tags: atom/literature/h1 - Regenerating the file hourly reduces the delay but leaves the same inconsistency between runs. The decision has already been made, and the sitemap should reflect it as part of publication. ([View Highlight](https://read.readwise.io/read/01m4496851qj938jhtznj9xx06)) - Note: [H2] The sitemap should change when the decision does - Tags: atom/literature/h2 - Those checks are useful, but their effectiveness depends on what they know about the website. A page can pass a detailed inspection and still contradict the system it belongs to. ([View Highlight](https://read.readwise.io/read/01m4496ax6f17f6fna1jxdbd7k)) - Note: [H3] Valid pages can still contradict the site - Tags: atom/literature/h3 - Being able to implement a requirement is different from knowing that the requirement exists. ([View Highlight](https://read.readwise.io/read/01m4496dd70fj8hp07q29t7kjk)) - Note: [H4] Building a requirement differs from knowing it exists - Tags: atom/literature/h3 - Eventually, you had a bespoke CMS whose specification was largely a record of the problems you’d encountered so far. ([View Highlight](https://read.readwise.io/read/01m4496g5rgqagc2vawfhkb96p)) - Note: [H5] Bespoke CMS specs record past breakage - Tags: atom/literature/h3