GEO
My build produced llms.txt, but its public URL returned an article. The response checks that exposed the deployment gap, and how I verified the uploaded file.
I expected the llms.txt URL on SeoGeo Tech to return the reading map produced by my build script. When I checked it on October 11, 2026, it redirected to this article instead. The local file existed; the public endpoint served a different kind of document.
That distinction matters if you are adding llms.txt to a WordPress site. A guide about the file does not serve the file. After a separate file upload, I verified the public endpoint on October 24. The earlier response below shows why checking the local build alone was not enough.
The response that changed the task
I requested the public endpoint without following redirects. These are selected fields from the response, with unrelated headers omitted:
HTTP/2 301
content-type: text/html; charset=UTF-8
location: https://seogeo.tech/articles/llms-txt-ai-readable-docs/Following that redirect returned HTTP 200 with text/html; charset=UTF-8 and this guide’s page content. A successful final status alone would have hidden the problem: the request completed, but it did not return the Markdown reading map.
These two commands separate the initial response from the final destination. They discard the body so that a full HTML page does not obscure the result:
url='https://seogeo.tech/llms.txt'
curl -sS -o /dev/null -w 'status=%{http_code}\ntype=%{content_type}\nredirect=%{redirect_url}\n' "$url"
curl -sSL -o /dev/null -w 'status=%{http_code}\ntype=%{content_type}\nfinal=%{url_effective}\n' "$url"A redirect is not automatically a failure. I would follow it and inspect what it serves. In this case, the destination was an explanatory HTML article, which is why I could not describe the endpoint as a deployed llms.txt file.
What the local build actually produces
In this project, renderLlmsTxt() in scripts/build.mjs assembles a Markdown document and the build writes it to dist/llms.txt. Its sections include “Start here,” “Technical SEO implementation,” and “Operations and editorial workflow.” The article-link helper reads titles and descriptions from the content registry; several introductory and navigation descriptions are written directly in the generator.
This is one line from the locally generated reading map inspected for this revision. It is local output, not a quotation from the public endpoint:
- [Metadata and Canonical URL Check: A Live Example](https://seogeo.tech/articles/metadata-canonical-url-examples/): A live SeoGeo Tech example of checking title, meta description, canonical URL, and Open Graph output before making edits.The current title is useful here because it tells a reader what the linked page now does. However, sharing a registry does not keep every sentence current: a hard-coded section introduction or link note can still describe an older version. I would review those descriptions alongside the selected destinations, rather than assume that rebuilding makes the entire map accurate.
The WordPress publishing script uploads selected media and sends article content to the Pages API. It does not upload dist/llms.txt to the web root. That explains a gap in the deployment process; it does not identify which server or plugin setting created the redirect. I have not inspected that configuration.
What llms.txt is for—and the Google Search boundary
The llms.txt proposal describes a Markdown entry point with context and links for agents using a website. A client that supports it can use that map to find relevant material. Publishing the file does not establish that a particular client fetched or used it.
Google’s generative AI search guidance explicitly says Google Search ignores llms.txt for visibility and rankings. I would therefore maintain it for an identified documentation or agent use case, not treat it as a missing Google ranking requirement. I have no usage logs or controlled observation showing an AI citation benefit from this site’s file.
For a small site, I would settle the practical question first: who will consume this map, and what will it help them find? If there is no clear answer, improving the linked pages and their normal navigation takes priority.
The three files have different jobs
robots.txt provides crawl instructions to supporting crawlers. A sitemap supplies URLs and related discovery information. llms.txt proposes a guided reading entry point for supporting clients. Adding a URL to the reading map does not grant access to a private page or make it indexed. Because llms.txt is public, avoid listing private or sensitive URLs that you do not want to disclose. The robots and sitemap inspection covers the search-discovery checks separately.
October 24: the public URL returns the file
We uploaded the generated file to the site’s web root through the hosting file manager, separately from publishing this article. A fresh request to the public llms.txt URL returned these selected response fields, without a redirect:
HTTP/2 200
content-type: text/plainI compared the response body with the reviewed local file: both were 9,128 bytes and matched byte for byte. The body decoded as UTF-8 and contained the Markdown reading map, not an HTML page. I also checked its 38 linked destinations; all returned HTTP 200 after any redirects. The sitemap link, for example, resolves through the site’s sitemap index.
The map is a curated entry point, not a list of every URL on the site. We corrected outdated descriptions and removed a feed link that returned 404 before uploading it. This closes the file-serving problem documented above. It does not yet tell me which agents use the file; that would require a recorded client request or usage evidence.
The useful lesson from this inspection is small and testable: check what the public URL returns before documenting a generated file as deployed. The local-build-to-WordPress walkthrough explains where this project’s two outputs separate.