set_content: Agent-Applied Page Content Changes

set_content is the tool the Get AI Traffic agent uses to change a page’s main body content after you approve a fix. It replaces the body HTML of a single page and confirms the new copy actually landed.

For whether a given page is worth expanding, or whether its heading really needs fixing, read the problem articles: Thin Content Is Why AI Won’t Cite You, H1 vs H2: A Page With No H1 Is a Page With No Title, and Inline CSS Is Quietly Bloating Your Pages. Those are content and business calls. This page is about the mechanics.

What it does

set_content writes new HTML into a page’s main body. What happens next depends on one setting: whether your site requires human approval for content changes.

• Approval off (the default). The tool captures the page’s current body to the ledger, writes the new HTML, then re-reads the page to confirm the content landed. If the read-back comes back empty, the write is reported as a failure rather than left half-applied.
• Approval on. The tool does not touch the live page at all. It stages the proposed content as a draft clone and records a pending change for review. You open a side-by-side of the live page next to the proposed version and approve or reject it in the Get AI Traffic app. Nothing goes live until you approve.

The content is written as server-rendered HTML, because that is what AI crawlers and search engines read: they do not run JavaScript, so copy that only appears after a script runs in the browser is invisible to them. This tool puts the words in the served HTML.

What it will not touch

• Scripts, iframes, and unsafe markup. WordPress runs your HTML through wp_kses_post on the server before it saves, so a <script>, an <iframe>, or any tag outside WordPress’s allowed set is stripped. This tool writes content, not code. That is also why it is safe to run: it cannot inject anything executable into your page.
• Anything but the page’s body. It replaces the content region of one page. The title tag, meta description, canonical, redirects, and robots rules are separate mechanisms with their own tools. Rewriting the body leaves those alone.
• Content that loads with JavaScript. It writes into the server-rendered HTML. If a page looks thin because the real copy is injected client-side after load, this tool is not the fix, because it works on the HTML the server sends, not what the browser builds afterward.

Timing

A content change lands immediately on the page, unlike a robots.txt edit that waits for the next crawl. After the write, purge_cache runs automatically so a cached copy at the edge does not keep serving the old body. The page itself updates now.

The AI payoff does not. Re-crawl and re-indexing by the AI engines take time after the page changes, so a rewrite pays off over weeks, not the same afternoon. On sites with approval turned on, nothing is live until a human approves the staged clone, so the clock starts at approval, not when the tool runs.

Rolling back

On the default path, the prior body is captured in the ledger before the write, so roll_back restores the previous content exactly. One detail worth knowing: WordPress sanitizes and reformats HTML as it saves, so the copy that lands is never a byte-for-byte match of what was submitted. The tool records what actually landed as the new value, which keeps roll_back‘s drift check from falsely blocking a reversal on a normal sanitized write.

On the approval path there is nothing to roll back, because the live page was never changed. Rejecting the proposal in the app discards the draft clone.

Related tools

• read_page_content reads the page’s rendered, shortcode-expanded content. Run it first so a rewrite preserves the existing copy and intent instead of inventing new text.
• propose_content stages a change as a draft clone for side-by-side human review without touching the live page, which is the same behavior an approval-on site gets automatically.
• purge_cache runs after an apply so the edge does not serve a stale body. It is also available on its own.
• set_title and set_meta_description handle the title tag and meta description, which are separate from the body this tool writes.

Findings this tool resolves

• thin_content: a page too thin for an AI engine to pull a citation from. The fix expands the body with the real substance a reader or a model needs to act.
• missing_h1: the page’s main heading is tagged as something other than a single H1. The fix rewrites the body so the title is a real H1 with a clean heading hierarchy beneath it.
• inline_css_bloat: the page’s body carries a large inline <style> block. Rewriting the body without the inline styles removes that render-blocking weight from the HTML.