Why does the publish path matter?
The publish path matters because it decides who can put content on your site, how a mistake is caught, and how it is reversed. An AI that writes well but publishes through a route nobody reviews is a liability regardless of the writing.
For Next.js sites there is no built-in content management system, so the choice is between treating articles as code and treating them as data delivered to an endpoint. Both can be made safe; they suit different teams.
Path one: how do pull requests work?
In the pull request path, the Content & SEO Engineer FTE drafts each article as MDX in a branch and opens a pull request with the content, metadata, and structured data. A team member reviews the diff and merges, and the existing build publishes it.
The FTE needs permission to open pull requests and nothing more. It does not need merge rights, and it should not have them by default. The merge is the approval, made by a named person, and a revert commit undoes a mistake.
Path two: how does the signed endpoint work?
In the endpoint path, the site owner installs a small package that adds a receiving route to their Next.js site. When a manager approves an article in the workspace, the Search Visibility FTE sends it to that route with a signature the site verifies before writing anything.
The package is installed from its public repository, and its exported types are the whole contract, so a mismatch between what is sent and what is expected fails visibly rather than losing data silently. The approval still happens in the workspace; the endpoint only receives what a person has already approved.
- Pull request path: content as code, merge is the approval, revert is the undo
- Endpoint path: signed delivery to a route you host, approval in the workspace
- Both: no merge rights or admin access for the AI, a named approver per publish
How is a bad publish caught?
Both paths are designed so a bad publish is caught rather than hidden. In the pull request path, review happens before anything ships. In the endpoint path, the package verifies its own installation and checks for cached 404 responses, so an article that appears to publish but does not actually resolve is reported as a failure rather than a success.
That last detail matters because the quiet failure is the dangerous one. A publish that silently produced nothing would otherwise show up weeks later as a page that never ranked, with no one sure why.
Which path should you choose?
Choose the pull request path when your team already reviews changes in the repository and wants content held to the same standard. It fits developer-led companies where the marketing site and the product share a codebase.
Choose the endpoint path when content should ship without a code review, or when the people approving articles are not the people who merge code. It keeps the approval with the content owner and the delivery with a route the engineering team controls. Either way the AI never holds the keys to production.
What does the audit trail record for a published article?
For an article published through either path, the audit trail records the whole chain. The topic proposal with its worth-it verdict. The draft versions with their sources. The fact-gate results, including any claims that were blocked and how the revision resolved them. The approval in the workspace with the approver's name, the date, and any edits or send-backs with reasons. The publish event: for the pull request path, the repository, the branch, and the pull request reference, with the merge recorded in the repository's own history; for the endpoint path, the destination, the confirmation the customer's site returned, and any cached-not-found detection afterwards.
It also records the tokens consumed at each stage from the immutable ledger. A content lead asked why a page says what it says, an engineer asked how it reached the site, and a compliance reviewer asked who approved a claim can each read the answer from the record. The two paths differ in mechanism and are identical in this respect: nothing goes live on its own, and every step from topic to live page leaves a trace the customer owns.