GEO
A real publishing-script example shows why current usage instructions and historical release notes need different information.
A command can still run and still be the wrong instruction to recommend. In the SeoGeo Tech repository, the README’s WordPress publishing section shows an unscoped publish command. Our repository’s AGENTS.md, under “WordPress publishing,” records a different operating rule: publish one selected article or standalone page at a time by default, and require an explicit request for a full-site publish. This is a project rule, not a restriction enforced by the script; the broader publishing path still exists.
I checked the README, publishing script, and Git history for this revision on October 16, 2026. They illustrate a documentation problem more concrete than a generic “GEO-friendly docs” template: a reader needs today’s safe operating instructions, while a maintainer may need the history of how those options arrived.
The instruction I would give someone publishing one article
The current script accepts --only=<article-slug> for an article and --only-page=<page-slug> for a standalone page. It rejects a request containing both options, and it checks the supplied slug against the generated content export. The article and standalone-page branches each return after handling their selected target.
The README’s “Then run” block contains these exact commands. This is a quotation of the inspected instructions, not the recommended command for a single-article update. With valid credentials, the second command invokes the broader publishing path; it is not a dry run.
npm run build
npm run publish:wpFor a single-article usage note, I would instead make the target and mode explicit. The following commands build the export and preview publishing this article only. They do not perform a live publish:
npm run build
npm run publish:wp:dry -- --only=geo-for-technical-documentation-changelogsThe build creates the export the publisher reads. The dry run reports the selected assets and target without making WordPress changes. It does not verify credentials or prove that the eventual live page will render correctly. A real publish requires the configured WordPress credentials and a separate decision to proceed.
The README’s unscoped command is not an invalid command: the script still has a broader publishing path. The problem is the missing boundary. Someone intending to update one article should not have to discover that boundary by reading the implementation. The publishing walkthrough covers the full architecture; a usage note only needs to make the immediate action unambiguous.
What belongs in the historical record instead
Commit b601912, dated July 25, 2026 in the repository history, added the standalone-page selection option. The diff adds onlyPageSlug, the mutually exclusive option check, and a dedicated standalone-page branch. The article selection option was already present in the preceding version.
The commit subject is “Add AI search content gap analyzer.” That subject alone does not explain the publishing change. A reader-facing release note could extract the relevant detail like this:
July 25, 2026 — standalone-page publishing added. The publisher gained
--only-page=<page-slug>for selecting a standalone page from the export. Article selection continues to use--only=<article-slug>. Do not supply both options in one invocation.
This is a release-note example written from the saved diff, not a claim that a release note was published on that date. The commit records that date in Git history; it does not establish when a server deployment happened or when every operator adopted the option.
The current usage instructions need not retell that history before every command. Conversely, the historical entry should not silently become an October instruction while keeping a July date. Readers use those two documents for different questions: “What should I do now?” and “What changed in this version?”
A date cannot repair a stale instruction
Updating a page’s date would not resolve the README mismatch. The actual command guidance needs to change. This article revision documents that finding; it does not itself edit the README or change the publisher. The inspected behavior is a source-code observation, not a new release performed for this article.
When technical documentation is quoted or summarized, I want the environment and action to remain together: this repository, a generated export, one selected target, and a dry run rather than a live operation. That is the GEO concern here. I have not run an answer-engine experiment showing that a particular layout preserves those details better.
Historical documentation can remain useful when it clearly names the behavior it describes. Private operational records are different. Passwords, tokens, and sensitive deployment details should stay behind access controls or be removed from public material; noindex controls search indexing, not who can retrieve a public URL.
The useful update is not another universal documentation template. It is a usage instruction that names its scope, paired with a historical note that accurately describes the code change. Neither needs an invented API example, an extraction score, or a claim that the format earns AI citations.