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  If you’ve spent years fighting with a content management system, the prospect of replacing it with a prompt is understandably appealing. All those plugins, awkward templates, and conversations about why a straightforward design change requires three days of development can disappear into a chat window. You describe what you want, adjust the result, and publish it before somebody would previously have finished estimating the work. You start with the homepage, then work through the service pages, the about page, and the blog. Each can look exactly how you want, without having to accommodate whatever decisions somebody made when they built your theme five years ago. While building the blog, you ask for an author profile and provide Jane’s photograph and biography. Later, when you’re working on the article template, you ask for an author box underneath each post, using the same information. A few weeks later, Jane sends over a revised biography. You ask for their profile to be updated, but notice that the author boxes underneath their articles still contain the previous version. In the old CMS, those appearances drew on Jane’s author record. In the replacement, their biography has been stored separately in the profile and the article template. Updating one leaves the other untouched, because the shared relationship was never built. 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. #### [An author is more than an author box](https://www.jonoalderson.com/conjecture/your-website-needs-a-brain/#h-an-author-is-more-than-an-author-box) The sensible next step is to create a reusable author component, with Jane’s information stored somewhere that both their profile and their articles can access. That gives you a consistent way to display their details and a single place to update them. If they change their photograph, you replace it in their record. If they revise their biography, you edit it there. The articles reference Jane, rather than containing independently maintained descriptions of them. You might also want their profile to list everything they’ve written. That requires a relationship between the author and their articles, which can support an archive, pagination, and an author feed. The structured data on each article can use the same record to describe who wrote it. These are ordinary requirements, and the AI can help you implement them. But you’ve already moved beyond building an author box into deciding how content is stored, connected, and published. The author example is a convenient place to start, but the same problem applies to products, services, categories, assets, and the metadata which describes them. A product’s availability might appear on its detail page, in category listings, in structured data, and in a shopping feed. Changing it to “out of stock” needs to reach all those outputs. A revised service description might need to appear on the service page, relevant landing pages, and shared promotional modules. If each contains an independent copy, updating the service page leaves the others untouched. Internal links have similar dependencies. Changing a product or service URL affects navigation, breadcrumbs, related-content modules, and contextual links wherever that address is used. A redirect can keep an old link working, but the website should also know how to generate the current one. Titles, descriptions, social metadata, canonicals, and schema often derive from those same records. A page can display the current product information whilst its metadata continues describing an earlier price, availability, or offering. The system needs to know where information belongs, which outputs depend on it, and where somebody has deliberately supplied an alternative. Otherwise, every additional appearance becomes another maintenance responsibility. #### [Then Jane changes their name](https://www.jonoalderson.com/conjecture/your-website-needs-a-brain/#h-then-jane-changes-their-name) Jane gets married and changes their surname. Because you’ve given them a shared record, updating the name used in their bylines, profile, and author boxes should be straightforward. Their structured data should reflect the change whilst continuing to identify them as the same person, with the same articles. They also decide that they’d like their author URL to use their new surname. Now the old address needs to redirect to the new one. Links from their articles should use the new address, as should the archive’s canonical URL and its entry in the XML sitemap. Jane has been writing for years, so their archive has several pages. `/author/jane-smith/page/2/` needs an appropriate redirect, along with page three and everything after it. The pagination on the new archive needs to generate the correct links, and their feed needs to remain accessible to anybody who subscribed using the previous address. The author component can handle its part correctly whilst the second page of the archive breaks and the sitemap continues listing the old URL. You can ask the AI to fix those problems, provided you know they exist. Somebody updating a colleague’s profile may have no reason to think about paginated redirects or feed addresses, particularly if their previous CMS handled that behaviour without involving them. That’s a substantial part of what you inherit when you replace a publishing system. The visible features are relatively easy to reproduce; the less obvious requirements tend to emerge through use, often when something has already gone wrong. #### [You may also have changed how publishing works](https://www.jonoalderson.com/conjecture/your-website-needs-a-brain/#h-you-may-also-have-changed-how-publishing-works) Even with Jane’s information stored correctly, changing their record doesn’t necessarily update what visitors receive. In a conventional database-backed publishing system, the application can use current information when it generates an article. Caching avoids repeating that work unnecessarily, with mechanisms for refreshing affected output when the underlying records change. If your replacement generates HTML and deploys it as static files, those files contain whatever information was available when they were built. Updating Jane’s record doesn’t change the bylines in the HTML already being served. The affected pages need to be generated again and the replacements published. You may have set out to improve the editing experience and inadvertently changed the website’s publishing architecture. As I argued in [there are only four sensible ways to build a website](https://www.jonoalderson.com/conjecture/four-ways-to-build-a-website/), static approaches can make considerable sense for relatively simple, stable sites. But a business which regularly publishes, translates, reuses, and retires content still needs a process for coordinating those changes. You could rebuild the whole website whenever anything changes. That may be manageable for a small site, but becomes a more expensive way to update a biography as the content grows. You could rebuild on a schedule, accepting that the published version will remain outdated between runs. Or you could fetch changing information in the browser after the page loads. That adds another network dependency and can delay content or introduce layout shifts. Google can render JavaScript, but relying on that introduces [additional requirements for crawling and indexing](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics). Crawlers and retrieval tools which don’t execute the required JavaScript won’t see that information. An LLM-based service using those sources may receive an outdated product description from the initial HTML, miss its current availability, or encounter structured data which contradicts what a human visitor sees. A well-designed static publishing pipeline can keep those outputs coordinated. It needs to understand which pages depend on the changed record, rebuild them at the appropriate time, and refresh the relevant caches. Those requirements belong in the architecture, alongside the components and layouts. #### [The sitemap needs to follow the decision](https://www.jonoalderson.com/conjecture/your-website-needs-a-brain/#h-the-sitemap-needs-to-follow-the-decision) XML sitemaps make this problem particularly clear. Suppose you noindex an article at nine in the morning, but your sitemap only regenerates at midnight. For the next fifteen hours, the page tells search engines not to index it whilst the sitemap continues including it among the URLs you want considered for indexing. 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. That doesn’t mean querying the database for every sitemap request. Updating a generated file or invalidating a cached response can work, provided the mechanism reliably follows the change. If you instead crawl the website overnight to discover which URLs belong in the sitemap, you’re reconstructing information which should already be available. Crawling is useful for auditing the result, but using it to discover your own publishing state introduces delay and another process to maintain. The indexing decision also needs to remain distinct from other publishing decisions. A noindexed article may still belong in navigation, author archives, and feeds. Withdrawing it from publication has different consequences, as does restricting it to signed-in users. A list of URLs won’t tell you enough to handle those cases correctly. Hreflang depends on similar knowledge. Publishing a French version of an English article changes the available language relationships. The relevant switchers and annotations need to reflect the new version, including on pages you haven’t otherwise edited. Withdraw the French article later, and the surviving versions need to stop advertising it as an available alternative. The editor removing the translation shouldn’t have to open every sibling page to make that happen. In both cases, the publishing system needs to understand how a decision affects the rest of the website. That knowledge should already be available when the change is made. #### [Checking every page still requires a model of the website](https://www.jonoalderson.com/conjecture/your-website-needs-a-brain/#h-checking-every-page-still-requires-a-model-of-the-website) A reasonable response is to add checks before publication. Have the AI inspect the page, confirm that the required markup exists, and correct any SEO issues before deployment. Run regular crawls afterwards to catch whatever slips through. 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. A canonical URL can be syntactically valid, resolve successfully, and identify the wrong preferred version. Hreflang annotations can contain valid language codes and working destinations whilst the corresponding pages fail to reciprocate. Schema can validate whilst describing a product’s availability incorrectly or giving Jane a different identity from the one used elsewhere. The presence of image dimensions and a `srcset` doesn’t establish that the available image sizes suit the placement, or that the `sizes` attribute describes the layout correctly. A page can contain a title and description without those values following the intended rules for its content type, locale, or inherited defaults. To assess those things reliably, the checker needs an authoritative account of what the answer should be. It needs to know which URL is preferred, which translations belong together, what the product’s current state is, and which image behaviour applies to the component. If those decisions exist only in independently generated pages, the checker has to infer intent from outputs which may already disagree. There’s also a problem with when the checks run. Publishing a translation changes what its siblings should advertise. Changing a service URL affects links elsewhere. Revising a shared image component can alter the markup on hundreds of previously approved pages. A check attached only to the page being edited misses those consequences. Expanding it to cover the affected pages requires dependency information; checking the entire website after every edit creates a much larger reconciliation process. AI can perform sophisticated checks across a site, including checks which go well beyond syntax. But doing that reliably requires much of the same content model, policy information, and dependency tracking that a coherent publishing system needs in the first place. That knowledge should also inform how the output is generated. A shared canonical rule can determine the correct value for every applicable page. An image component can consistently produce the required variants and markup. Metadata can follow defined templates with explicit overrides, whilst schema draws on the same records as the visible content. You still test those rules and inspect the published result. Shared logic can contain bugs, and requirements change. But when a rule is wrong, you have a defined place to correct it for existing and future pages. If every page independently implements the same decision, every page is another opportunity to get it wrong. Correcting one instance leaves the process which produced it largely untouched. That’s how generating pages and inspecting them afterwards can become a permanent game of whack-a-mole, even when both stages use capable AI. #### [The requirements you never had to learn](https://www.jonoalderson.com/conjecture/your-website-needs-a-brain/#h-the-requirements-you-never-had-to-learn) There are plenty of other dependencies which belong in that model. Moving the final article out of a category may leave an empty archive. Its indexing and sitemap eligibility need to follow the rules you’ve established for that state. Archive pagination may need to shrink, and category feeds should reflect the new membership. Making an article private requires more than a login form on its page. Its content may still be available in a feed, a public endpoint, a cached response, or an attached document at an unrestricted address. The access decision needs to apply across the routes through which the material is delivered. Even apparently minor features have surrounding behaviour. A taxonomy archive can have pagination, feeds, feed-discovery links, metadata, and URL-handling rules. You might never subscribe to a category feed, or inspect what happens when its archive loses a page, but that behaviour still needs to be intentional. WordPress, Drupal, and their ecosystems contain years of decisions about these sorts of requirements. In a WordPress setup, the work might be shared between core functionality, the theme, Yoast, a multilingual plugin, and other integrations. The implementation can be messy. Some defaults will be wrong for your site, and some parts may conflict. An established platform offers no guarantee that everything has been configured correctly. But it gives you access to accumulated experience which doesn’t depend on your team having encountered every problem personally. Much of its value consists of behaviour you’ve never needed to specify, because somebody dealt with it before you arrived. That makes the replacement harder to scope than it appears. Your engineers and your AI can reproduce the workflows you describe, but the specification may omit requirements which nobody knew to describe. The checks can share those omissions. If an author feed never appears in the implementation plan or the test plan, both can look complete without anybody checking what happens to existing subscribers when an address changes. Being able to implement a requirement is different from knowing that the requirement exists. #### [AI can build a CMS, too](https://www.jonoalderson.com/conjecture/your-website-needs-a-brain/#h-ai-can-build-a-cms-too) There’s a legitimate counterargument here. You can ask an agent to design the content model, establish shared publishing rules, track dependencies, coordinate deployments, and test relationships across the website. You can impose architectural constraints and require subsequent changes to follow them. For an organisation with deliberately scoped requirements and the expertise to maintain the result, that may be a good decision. AI reduces the cost of building custom software, and a focused publishing system may fit the business better than a large platform with years of accumulated baggage. By that point, however, you’re building your own content management system. It might use a chat interface, store records in files, and publish static output. It might have no dashboard which resembles WordPress. It still takes responsibility for managing content, its relationships, and the consequences of publication. Those responsibilities need to be specified, implemented, tested, and maintained. AI can assist with all of that, but it doesn’t establish that the specification is complete simply by producing working software. For anybody who built websites in the late nineties or early 2000s, the progression is familiar. You started with pages, extracted repeated elements into shared includes, added a database, and built some forms so that somebody else could edit the content. Permissions, previews, uploads, redirects, and exceptions followed as new requirements emerged. Eventually, you had a bespoke CMS whose specification was largely a record of the problems you’d encountered so far. AI makes that process faster. It can also help identify requirements earlier, if you ask the right questions and give it the right context. But the decision to build a replacement still needs to account for discovering what must be built, alongside the cost of writing the code. Otherwise, the missing requirements become an ongoing research project conducted through broken behaviour, audits, and user reports. #### [Build for the next edit](https://www.jonoalderson.com/conjecture/your-website-needs-a-brain/#h-build-for-the-next-edit) Your website needs an authoritative model of the things your business publishes: products, services, people, articles, categories, and assets, together with their relationships and publishing rules. That includes the information used to describe and connect them. Availability, service descriptions, internal links, metadata, and structured data need to follow the appropriate shared records and policies. When something changes, the system should know which outputs are affected and carry that change through to the live website. There’s still plenty of room for bespoke layouts and rapid experimentation. Sharing a product record doesn’t require every page mentioning the product to look identical, and reliable publishing rules can make experimentation easier by reducing the number of decisions each new page has to implement. Before replacing your CMS, follow a few ordinary edits through the existing website. Change a product’s availability, update an author, withdraw a translation, and revise an indexing setting. Identify what else responds, including the feeds and machine-readable outputs you rarely inspect. Include those behaviours in the requirements for the replacement. Use AI to help discover and implement them, and use checks to verify that the resulting system behaves as intended. The people maintaining the site should be able to change Jane’s details or withdraw a service without knowing every place that information appears. If each edit requires another investigation into what the rest of the website ought to contain, the ease of generating the pages has left a substantial part of the publishing job unresolved., Your Website Needs a Brain, Jono Alderson, 01m448qveamcs1nv7dx315zssz.