Updating a page from AI visibility

AI visibility shows which of your pages AI answers cite, and which pages they cite instead of yours. When the answer to a buyer question should be one of your pages, Viewfield proposes a change to that page and, when a manager decides, saves it to your CMS as a draft. Nothing goes live on its own.

Where a change starts

Prepare changes starts one, and it is offered wherever a page of yours should answer a question better:

• on a question's tray on Visibility, as Fix with the page's path ("Fix /pricing");
• on an Update suggestion for a question: the page the answers cite on it, the one they stopped citing, or the one your site has for it;
• on a page in Website AEO: Prepare in the list, or Prepare changes on the page's Optimize tab, for a question it should win;
• on a measured change in AI answers, under the page to rework;
• from a draft written to rework a page: Prepare changes from the draft, or, in the draft's publish tray, Propose as a change to that page. The draft becomes the change's source.

One rule picks the page: the page the answers cite, else the page you published for the question, else a page matched by its words, else none. Viewfield never proposes a second page beside one the answers already cite.

Proposing

Prepare changes reads the page as it is right now (through your CMS, or the public page) and asks for a small set of changes, at most eight, that would help AI answers quote it for those questions. It reads the questions the page should win, who the answers name on them, the pages they cite, what they say and what the engines searched for, your brand's name and other names, your claim rules and your voice. It costs one model call on your allowance, like a draft. Anyone on the team can propose; Ask Viewfield and agents over MCP can propose too.

Every proposed change is checked before you see it. A change is left out when its "before" is not the page's current text; when it states a number, a price, a name or a result that is not on your page or in the questions; when it breaks one of your claim rules; when it uses Viewfield's own words instead of yours; when it links away from your site; when it carries HTML, code or a template expression; or when it names a company on your list of who else gets named that your page does not already name (a comparison table excepted). Viewfield never proposes structured data or an llms.txt file.

Reviewing

A change opens as a sheet on its page. It leads with the question it is written to win, who AI answers name instead and the page they cite most. Each field shows its before and after, why it is proposed, whether you paste it yourself (Copy by hand; everything else your CMS saves), and how strong the evidence is for that kind of change:

Evidence	Changes	What it means
Strong evidence	An opening paragraph that answers the question first; a visible updated date; a section that adds a statistic with its source	The changes studies tie most closely to being quoted in AI answers
Correlational evidence	Title, H1, meta description, a comparison table, a new section	Pages AI answers cite tend to have these; no study shows the change causes it
Hygiene	An FAQ entry	Helps readers; studies have not found it makes AI answers cite a page

The tier comes from that fixed table, never from the model that wrote the change.

The fields a CMS can take

Viewfield talks about a page in the same fields whichever CMS holds it: the title, the meta description, the H1, the opening paragraph, a section, an FAQ, a comparison table and an updated date. Each page in a connection's list says which of those its CMS lets Viewfield write; anything else is a copy-ready handoff with the exact current text beside the new one.

• Payload writes the title, the meta description and the H1 where your collection maps them; the body fields (an opening, a section, an FAQ, a comparison table) are written only when the body is Markdown or HTML, and copied by hand when it is Lexical.
• WordPress writes the title, the H1 and the body; the meta description is always a handoff (Yoast and Rank Math keep it read only over the API).
• Webflow writes a CMS item's title, SEO fields and body; a static page takes only its SEO title and description. A static page's change is staged in Webflow by Save draft and goes live with your team's next site publish, anyone's: there is no Publish press for it in Viewfield (Viewfield never publishes a whole site), and Revert takes the change back out before then.
• HubSpot CMS writes the HTML title, the meta description and a blog post's title and body; on a site or landing page, the main rich text module.
• GitHub writes the file: frontmatter title and description, an updated date when the file has one, and the Markdown body, keeping every other line.

A CMS saves page changes from Viewfield only once its updates and publishing have been proven the way its drafts are: Payload and Webflow today. On any other CMS the change sheet offers Copy by hand and Mark done instead, and says "Saving page changes to (the CMS) from Viewfield is not open for your workspace yet."

Any other site (a CMS you have not connected) still works: Viewfield reads the public page the way an AI crawler does, and the change is copy-ready, with Mark as done for the day it went live.

Applying

A change opens with its chip (Ready to review, Draft in your CMS or Pull request open, Live, Measured, Needs attention, Rejected, Reverted) and one main press; the rest sit under More (…). Only a manager or owner sees the presses that write; a contributor reads "A manager saves changes to your site, publishes them and reverts them."

• Save draft in your CMS (or Open a pull request for GitHub) writes the change as the CMS's reviewable draft. Your live page does not change. Open the draft (or Open the pull request) takes you to it. If anyone edited the page after the proposal read it, the save is refused ("The page changed since the proposal read it. Refresh the proposal.").
• Publish to your domain puts the draft live, after you confirm, where your CMS has a draft Viewfield can promote. Only the draft Viewfield saved is promoted; if anyone changed it since, nothing goes live.
• Copy change copies every copy-by-hand change, with the text to find and the text to put instead; Copy changes copies every field's new text, for any CMS.
• Under More: Refresh reads the page again and proposes afresh; Reject closes a proposal never saved to the CMS; Mark as done records that the change is live, for one you pasted yourself, a pull request your team merged or a draft you published in the CMS; Revert takes it back out once a draft is there.

One change per page can be a draft at a time, because your CMS keeps one draft of a page. Viewfield never saves over edits someone has not published yet; it asks you to publish or discard them first. A change keeps the links, formatting and block settings of the text it rewrites; one that would drop a link or an embed is marked Copy by hand with the reason.

Viewfield also reads each open change's public page on its own: when every new text is on the page, it marks the change done; when the text it would replace is gone, it marks the change out of date; and a proposal left untouched for 21 days is read again. If your site's connection changes while a proposal is open, the proposal asks to be prepared again. When writes to websites are paused on Viewfield, the press says so, and your proposal is kept.

Reverting

Revert puts back exactly what the change replaced, byte for byte, the way the change went live: through a draft and a publish when Viewfield published it, as a draft or a pull request for your team when it went live outside Viewfield, and as your word for a change you pasted yourself. If someone edited one of those fields since, Revert does not overwrite their text: it names the field so you can put the original back by hand.

Reading the impact

Once a change is live, the sheet says when it will first be read. Fourteen days later, and again at twenty-eight, Viewfield compares the answers to the questions the change targeted with the fourteen days before it went live, and does the same for your other tracked questions as the comparison:

Since this went live, over 14 days, the questions it targets were answered with your site cited in 3 of 10 answers, from 0 of 10 in the 14 days before, and named you in 6 of 10, from 4 of 10; your other questions moved from 2 of 40 to 2 of 38 cited, and from 5 of 40 to 5 of 38 named.

The sheet also says how often the page itself was cited over the same windows. Counts come first because one AI answer is noise. This is an association, never proof: AI answers vary from run to run, and anything else that changed in those weeks counts too, which is why your other questions sit beside the numbers. A change reverted before its first read is not read.

Over MCP and in chat

list_site_pages, get_site_page (one page read now), propose_site_change, list_site_changes, get_site_change, and set_default_site (manager: which site Website AEO lists). Saving, publishing and reverting are a person's press in the app. See MCP overview.