Two technical SEO fixes from our own websites

A merged change is not necessarily a live change. A redirect that works for an article can still fail for the homepage. We encountered both problems while reviewing our own websites on September 29, 2026.

This is a first-party implementation case involving two websites we operate: IndieDevWilliam and SimpleBibleReader. It records observable technical repairs. We have not measured a search-ranking, AI-citation, traffic or revenue improvement from either repair.

The two findings

Website	Before	Repair	Verified result
IndieDevWilliam	The robots and sitemap URLs returned homepage HTML instead of the intended discovery files. The repository already contained a merged change that had not reached production.	Corrected the sitemap namespace, added a homepage canonical and deployed the public site files to the associated Cloudflare Pages project.	robots.txt returned 200 with text/plain; sitemap.xml returned 200 with application/xml and the correct sitemap namespace; the homepage contained the intended HTTPS canonical.
SimpleBibleReader	The bare-domain homepage redirected to a literal /:path* URL and ended at a 404. The www homepage worked, and a nested path redirected correctly.	Added a Cloudflare 308 redirect from the HTTPS bare domain to www, preserving paths and query strings.	The homepage redirected to the working www root. A query parameter and a nested Bible URL were preserved. The destination returned 200 and rendered in the browser.

Case one: inspect the response, not just the status

An HTTP 200 means the request succeeded at the HTTP layer. It does not mean the response contains the document the URL promises.

On IndieDevWilliam, requesting the discovery endpoints returned HTML. That is a common way a website fallback can conceal missing files: an ordinary visitor still sees a page, but the robots or sitemap consumer receives the wrong content.

We compared the live files with the current source and confirmed the domain's hosting project before deploying. We also corrected the sitemap's XML namespace to http://www.sitemaps.org/schemas/sitemap/0.9. A filename ending in .xml is not a substitute for a valid XML document.

After deployment, ordinary HTTP requests confirmed the response status, media type and body of each discovery file. The browser blocked a direct robots-file navigation in our test environment, so that browser attempt is not part of the successful verification claim. We retained the HTTP evidence separately.

This repair makes the intended discovery documents available. It does not establish that a search engine has fetched them, indexed the site or changed its rankings.

Case two: test the empty path

The initial symptom on SimpleBibleReader looked like a missing homepage. Following the redirect chain changed the diagnosis.

The www homepage returned the real page. The bare-domain root returned a 308 response with a malformed destination ending in the literal placeholder /:path*. Following that address produced the 404. A nested Bible URL, however, redirected to its correct www counterpart.

That difference mattered. Rebuilding the homepage would have targeted the wrong problem. We repaired canonical-host routing at Cloudflare and checked these cases independently:

• The bare-domain root redirects to the www root.
• The root with a query parameter preserves that parameter.
• A nested content path preserves both path and query.
• The www destination returns 200 and renders the homepage.

The application's existing production checker covered a nested redirect, which would not catch the root-specific failure we observed. An explicit root check belongs in the next application release. The immediate repair is an edge rule; we did not replace the application or claim to have proved the underlying adapter bug.

A repeatable release check

For a small marketing site, keep a short list of expected URL contracts: the canonical homepage, alternate host, representative content page, robots file, sitemap and one intentionally missing page. For each, record the expected status, destination or media type, and one meaningful body check.

Run that list against production after publishing. Include both root and nested paths when checking redirects. Open the main customer journey in a browser as well: a correct HTTP response alone does not prove the page is usable.

These checks complement content work. They help ensure that readers and crawlers can reach the pages you have actually published. They are not a special GEO format or a guarantee of an AI recommendation.

What comes next

The next measurement step is to review authorized search indexing data and establish a consistent baseline for visits and meaningful actions. Until that evidence exists, our result is precise: discovery responses and a broken entry path were repaired and verified.

For another example of work on our own business, see our service pricing implementation case. If your site needs a similar review, our audit scope and pricing explain the deliverables and limits.