---
title: "A website built to be read by machines as well as people"
url: "https://toddpaulbrownjr.com/writing/a-website-for-machines-and-people/"
author: "Todd Paul Brown Jr."
description: "Adroit's website rebuilt with a machine-readable layer: 74 pages updated, 17 created, JS from 103 KB to 2 KB, Markdown twins and llms.txt live."
kind: "article"
updated: "2026-09-26T02:50:23+00:00"
---

# A website built to be read by machines as well as people

I rebuilt Adroit's website — the same visual system people see, now served in parallel with a second format built for how AI systems and crawlers actually read a page. 74 existing pages and posts updated, 17 new pages created, JavaScript from 103 KB to 2 KB, eight plugins retired, and a Markdown twin plus llms.txt for every page.
Then I did the same thing to this site.

## Why it matters

The rebuild had to keep every one of Adroit's live URLs working, so the machine-readable layer was retrofitted onto existing WordPress and Elementor-authored pages rather than designed in from scratch. For a business, that is the difference between being findable by a search box and being findable by whatever people ask instead of searching now.

This was my own company's site. I could have torn the whole thing down and started clean. I didn't, because most businesses can't afford to throw away their existing content and URLs every time the distribution layer shifts. The constraint was the point.

## The machine-readable layer

Every refreshed page and post serves a Markdown twin at three paths: `/<path>/index.md`, `/<path>.md`, and `/<path>/?format=md`. The site prints `/llms.txt` and `/llms-full.txt` following the llms.txt convention, with `rel=alternate` links to the Markdown format in every page's head, and AI-crawler allowances added to `robots.txt` on indexable environments.

Structured data — JSON-LD schema markup — went into the source across the site: `Service` schema on 40 service and capability pages, `SoftwareApplication` schema on the two product pages, and `FAQPage` schema parsed from Markdown headings on pages with two or more question-and-answer pairs, 18 questions total.

The applier that wrote all of this back to WordPress was idempotent and kept a revert path. Zero errors across 91 pages.

## The numbers, measured

I measured these on the home page, compressed:

- JavaScript: 103 KB to 2 KB
- CSS: 78 KB to 10 KB  
- HTML: 79 KB to 34 KB

Eight plugins retired in favor of native theme code: Happy Elementor Addons (plus Pro), Elementor Designer Powerup, Performance Lab, Hummingbird, Smush, Cookie Law Info, Redirection, plus one unused header template removed. Native replacements built for forms and scheduling, redirects, the cookie notice, and CDN image optimization.

The site is live at adroitmktg.com as of 23 September 2026, and [Sadyr](/builds/sadyr/) — the knowledge-base chat assistant — has been answering visitor questions on the live site since the same day.

## The same system on this site

This site runs the same architecture. Every page you see has a Markdown twin; the llms.txt file points to all of them. The only difference is that toddpaulbrownjr.com was built in Markdown from the start, so the machine-readable format is the source format. No retrofit required.

The Adroit rebuild proved the retrofit path works. This site proves the same layer can be designed in from day one with no visual compromise and no CMS required.

## What broke and how I fixed it

The first version of the Markdown renderer hard-coded the site's navigation into every output file. When a new page went live or a menu item changed, every Markdown file on the server was stale until the next full rebuild. I caught it during staging review and rewrote the renderer to generate navigation at request time from the WordPress menu API.

The llms.txt generator initially tried to describe every page's purpose in the manifest. Half the descriptions were generic rewrites of the page title. I stripped them out and let the page content speak for itself; the manifest now lists URLs, titles and modification dates only.

Schema markup for the FAQ pages depended on a strict Markdown heading convention: `## Question text` followed immediately by answer paragraphs. Two older pages had nested subheadings under the answers, which broke the parser. I flattened the heading structure on those pages and the schema came out clean.

## The layer thesis

A company website can be made machine-readable without a redesign. The thesis is that simple, and this rebuild is the receipt.

You keep the visual system your visitors see. You add a second, parallel format — Markdown, structured data, llms.txt — built for the systems reading your site when somebody asks a question in plain English instead of typing keywords into a search box.

The constraint I gave myself was real: every live URL had to keep working, and the visual design could not change. If the machine-readable layer required burning down the existing site, most businesses would never do it. The fact that it didn't is the point.

## What is next

Adroit's site is live and the machine-readable layer is serving. The next step is measuring whether it actually moves the needle on how often the site appears in AI-mediated answers — not search rankings, but the answers Claude, ChatGPT and Perplexity give when someone asks a question Adroit's knowledge base can answer.

I am not running that measurement yet, because the site has only been live in this form for a few weeks and I need a longer baseline. When I have one, the data will go on the [receipts](/receipts/) page with the same discipline as everything else: what was measured, when, and what it shows.

This site is the same. The Markdown layer is live, the llms.txt manifest points to every page, and the structured data is in place. The difference is that this site exists to document what I build, not to convert visitors into clients, so the success metric is whether the people who care about this work can find it when they ask the systems they already use.

Both sites answer the same question: can a website be built to serve people and machines equally well, without a redesign and without breaking what already works? The answer is yes, and the work is live.
