A template default is a claim you never decided to make

Every website starts from somebody else's decisions. A starter template ships with a site address, a social handle, a share image and a sitemap location already filled in, and each of those values is a statement your site makes in public. Launching means deciding every one of them, because a default you never replaced is still an assertion, published under your name, that nobody at your company chose to make. For seven weeks, ours told search engines that our sitemap lived at example.com.

What our site said that we never decided

Affinero was built from Payload's website template on 27 August. Until a fix went live on 15 October, our robots.txt and sitemap index pointed crawlers at https://example.com. Every post's Twitter card named @payloadcms as its creator. The share link on every post pointed at our homepage rather than at the post. The Finnish homepage offered a share image hosted on localhost, which is to say on a developer's laptop. No page carried a canonical tag, which we admitted in yesterday's post before the same fix shipped.

None of it was visible on the page. The blog read well and the posts rendered, and every review we ran looked at the part a human reads. The defaults lived in the head of the document, in robots.txt, and in the share card a reader only sees after pasting the link into a chat.

This is the same lesson as the fields nobody translates, one layer down. The machine-read layer is where review never looks, so it is where somebody else's decisions survive longest.

The worst defaults are the ones that only appear when something is missing

Most template values are visible placeholders, and a visible placeholder gets replaced. The example.com address was different. The template's sitemap configuration reads the site address from an environment variable and falls back to example.com when the variable is absent. On a developer's machine the variable was set and everything looked right. In the production build step it was not set, so the fallback quietly took over, and only there.

A fallback is a default with a trigger. It hides from exactly the person who would catch it, because it appears only under conditions they are not testing. The developer sees the correct value, the reviewer reads the page, and the production robots.txt says something neither of them has ever looked at.

Nothing downstream objects. Google's robots.txt specification says the sitemap line must be a fully qualified URL and adds that it "doesn't have to be on the same host" as the robots.txt file. A sitemap at example.com is therefore a perfectly valid instruction. Google's sitemap guidance says it will crawl the URLs exactly as listed. The placeholder was not a syntax error. It was a well-formed statement that happened to be false.

A share card is a claim about identity

The Open Graph protocol defines og:url as "the canonical URL of your object that will be used as its permanent ID in the graph." When every post declares the homepage as its permanent ID, every post tells the networks that read the tag that it is the homepage. The creator handle is a claim about authorship. Ours credited a CMS vendor with fifty-odd posts it had no part in writing.

These are small errors one at a time. We are not suggesting anyone lost a customer to a Twitter card. The point is that they were claims, they were wrong, and the tools that read them had no way to know.

An engine inherits every default once per page

A human-run blog that ships a bad default ships it on the twenty pages someone wrote that year. An engine that publishes every morning inherits it on every page it produces, at the speed it produces them. This is the case we made in auditing the rule rather than the page: an automated site's errors are policies, not slips, and a template default is the first policy any automated site runs.

The concession is that most defaults are fine. A template's spacing, fonts and admin layout are decisions you can happily accept unexamined. The audit is not about replacing everything. It is about knowing which fields make a statement to the outside world and deciding each of those on purpose, even when the decision is to keep the default.

Launch is the day you decide what your site says

The practical version is short. Read the production site the way a crawler and a share preview do, not the way a visitor does: robots.txt, the sitemap, and the document head of one page of every type in every language. Search the codebase for the template's placeholder values, the vendor's own name and any localhost address. And make missing configuration fail the build instead of falling back. Our fix replaced the fallback with a fixed origin, so a missing variable can no longer produce a plausible wrong answer.

A site goes live with hundreds of small public statements. The ones you wrote are the minority. Launch is when you take responsibility for the rest, because the reader, the crawler and the share preview cannot tell which ones you meant.