The half of search we own

• One canonical address per page

  Every page states its own permanent URL in its own markup, so a crawler never has to pick between two copies of the same page.

• A sitemap, rebuilt every deploy

  A machine-readable list of every route — 87 of them today — regenerates fresh on every build, never a copy left over from an old one.

• A robots file naming the sitemap

  The first file a crawler checks allows the whole site and points straight at the sitemap above.

• A title and a description sized for the results page

  Every page keeps its title to 60 characters or fewer and its description between 110 and 160, so a result is not cut off mid-sentence. The build fails when a page breaks these numbers. A short snippet is not a ranking promise, and a search engine may still rewrite it.

• A page fast enough to fetch

  80 of those 87 routes ship no JavaScript at all, and every route stays inside a measured, enforced page-weight budget — see Performance for the receipt.

1. 1

   robots.txt

   The first file a crawler checks. It allows the whole site and names where the sitemap lives.

2. 2

   Sitemap

   A list of every page, fetched next and rebuilt fresh on every deploy.

3. 3

   Fetch

   The crawler requests a page the same way a browser does, at the address the sitemap named.

4. 4

   HTML

   The page arrives as real markup — a title, a description, and the content itself, not a blank shell waiting on a script.

5. 5

   Index

   A search engine or an answer engine stores what it found, against the one canonical address the page itself named.

Two of the address rules that keep that trail intact:

Permanent redirect (301)

Tells a browser and a search engine that a page has moved for good. Both update where they point. Use this when the old address is never coming back.

A real 404

A page that genuinely doesn't exist returns your own not-found page, with a real 404 status code attached — not a blank error document from somewhere else.

• Static sites

  Every page is already built. A crawler reads the exact HTML a visitor gets, served straight from the edge.

• Dedicated instances

  Your app renders the page before it leaves the instance, so a crawler still meets finished HTML rather than a template.

• Custom stacks

  An app that draws its own text in the browser, after the page loads, is a different case. A crawler that does not run that script meets an empty page — that is your code's problem to solve, not a hosting one.

1. 1

   TTLs lowered ahead of time

   Shortens how long resolvers hold onto the old answer, before anything about the records themselves actually changes.

2. 2

   Rehearsed against the standing copy

   Checked against a working copy of the site or app first — the switch itself isn't the first time it's been tried.

3. 3

   The old host keeps serving through the window

   Nothing is torn down until traffic has actually moved — a visitor whose resolver is slow to catch up still reaches a working site, just from wherever it was before.

4. 4

   Rollback is the same move, reversed

   Pointing the records back is not a special procedure — it is this same change, run the other direction, on the same propagation timeline.

• A machine-readable site directory

  A plain list of every one of the 87 routes on this site, in the shape an answer engine expects to read — not a bot bolted onto the page.

• A feed for the long-form guides

  The Field Manual publishes as a feed, so a reader or an aggregator picks up a new guide the moment it ships.

• A social card per page

  Sharing a link renders its own title and image, drawn from that page's own copy rather than one generic placeholder.

• A plain-text copy of every page

  Every one of the 86 pages on this site has a Markdown copy at its own address plus ".md" — no HTML to parse, and nothing rendered. The whole site is also available as one file, at llms-full.txt. This does not promise a better ranking or a spot in any answer — it only removes the parsing work.

• A staging copy gets indexed

  CustomHosted

  Not linked from anywhere on your live site, not submitted to a search engine, and left out of the sitemap. Reaching it is a matter of knowing the address and being allowed in — access is controlled, not just unlisted.

• A move ships with no redirect map

  CodeHerder

  Points a batch of old addresses at their new ones after a move. Without it, pages a search engine already ranked start returning nothing.

• A page is too slow to finish fetching

  You, briefed through CodeHerder

  A crawler gives up on a page the same way a visitor does. See Performance for what makes a page slow and the measured budget every route here stays inside.

• The text needs JavaScript to appear

  You

  A crawler that doesn't run your app's script meets an empty page — see "By hosting shape" above for which shapes this actually affects.

The 17 checks that run against this build, including this page's own:

• check:anchors

  Every hub page's "On this page" index still matches its own numbered bands, in order.

• check:a11y

  Every route is crawled for accessibility faults, at two sizes, in both themes.

• check:ledger

  The public build-history page still matches what this repository's own history says.

• check:llms

  The machine-readable site directory lists every route exactly once, and every link actually resolves.

• check:perf

  Every route stays inside its own published page-weight budget.

• check:security-txt

  The security-contact file is present, and not expired.

• check:supply-chain

  The dependency-safety rules — locked versions, no install scripts, a release cooldown — are still in place.

• check:seo

  Every route carries one canonical URL, one title, one description, and valid structured data — and nothing meant to stay out of the index does.

• check:forms

  The form page's own field caps, its POST-only check, its honeypot field, and its log retention still match the real contact-form terraform.

• check:images

  Every image stays under its published weight ceiling, and every picture carries alt text, its dimensions, and a loading value.

• check:limits

  Every module that publishes a limits array is collected on /limits, and its published count matches what the page actually renders.

• check:logins

  No password input exists anywhere on the site, every form carries a known id with no off-site action, and /logins' own worked artifact still renders.

• check:compliance

  No affirmative compliance or certification claim appears anywhere on the site, and /your-data's residency and deletion bands still render.

• check:spacing

  No run-together word slipped past a stripped space next to a link or other inline element, on any route.

• check:reveal

  Every section that fades in on scroll actually appears, on a phone-sized screen as well as a desktop one.

• check:twins

  Every route's Markdown twin exists, starts with the page's real heading, carries no stray HTML, and is linked from the page exactly once.

• check:quotes

  No published quote bills an add-on its plan already includes, and the estimator prices only through the same code as the quote form.

• A title, a description, or a redirect map is a briefed change

  Fixing a page's title, its description, or the old-URL map behind a move goes through the same loop as any other change — the Agentic iteration — CodeHerder add-on ($25/mo). Brief a change in plain words. An agent opens a pull request, a person reviews it, and the same pipeline ships it.

• Writing the content itself is not a priced line here

  What a page actually says stays yours to write. We ship the change once you brief it; we do not write the copy for you.

A metadata fix travels the same path as any other briefed change — the one Patching already walks through for a flagged dependency:

1. 1

   A routine scan flags a dependency

   The same kind of check that watches the infrastructure layers above, run against your application’s own dependency list.

   CustomHosted

2. 2

   It's triaged as application-level, not infrastructure

   A library your own code imports isn't ours to patch silently — it can change how the app behaves.

   CustomHosted

3. 3

   Briefed as a change

   Written up the same way any other change request is — this is what the Agentic iteration — CodeHerder add-on covers.

   CustomLabs

4. 4

   An agent opens the pull request

   The upgrade lands as a real pull request against the repository, with the test suite run against it.

   CodeHerder

5. 5

   A human reviews and merges

   Someone reads the diff before it goes anywhere near production — nothing here is auto-applied blind.

   CustomLabs

6. 6

   It ships through the same pipeline

   The same pipeline that deploys everything else on your stack ships this too — no separate process to babysit.

   CustomHosted

7. 7

   You're told it's done

   A note confirming what changed and that it merged, in the same shape as every other note on this site.

   CustomHosted

• No ranking, position, or traffic promise

  A crawlable, fast, correctly marked-up site is what we can prove. Where it ranks depends on your content, your market, and a search engine's own algorithm — none of which we run.

• Field Core Web Vitals

  The numbers above are a lab measurement of the build itself — bytes over the wire, not what a real visitor's device and connection actually experienced. We don't run the traffic yet to publish that honestly.

• No keyword research or content strategy

  Choosing what to write about, and which words to use, is your call. We keep the technical side clear; we do not plan your content.

• No backlink building

  Earning links from other sites is an outreach effort, not a hosting one. We do not run that campaign for you.

1. 01Will hosting here improve my search ranking?

   We can't promise that, and won't. What we can prove: a crawlable, fast, correctly marked-up site with nothing broken in its way. Where it ranks depends on your content, your market, and a search engine's own algorithm.

2. 02Do you do SEO?

   Not as a service. We own the technical foundation — the address, the sitemap, crawlability, structured data, and speed. Content, keywords, and backlinks are yours to run, or to brief someone else for.

3. 03Can a search engine find my staging site?

   No. Not linked from anywhere on your live site, not submitted to a search engine, and left out of the sitemap. Reaching it is a matter of knowing the address and being allowed in — access is controlled, not just unlisted. See Environments for the standing staging environment in full.

4. 04Will I lose rankings when I move my site here?

   Not if the redirect map ships with the move. Points a batch of old addresses at their new ones after a move. Without it, pages a search engine already ranked start returning nothing. See Delivery for the full rule set and Migrations for the cutover itself.

5. 05What about Core Web Vitals?

   The numbers above are a lab measurement of the build itself — bytes over the wire, not what a real visitor's device and connection actually experienced. We don't run the traffic yet to publish that honestly.

6. 06My app renders its own text in the browser. Is that a problem?

   It can be. A crawler that doesn't run your app's script meets an empty page on that shape — see "By hosting shape" above for which ones this actually affects.

7. 07What does fixing a title tag or a meta description cost?

   Nothing on its own if it's part of a wider briefed change — a metadata fix goes through the same loop as any other change, under Agentic iteration — CodeHerder ($25/mo).

8. 08Can I see this page proving its own claims?

   Yes. Every claim above is checked against this exact page's own built output — see "Worked artifact" above for the 17 checks that run on every deploy.