set_author_profile: Agent-Applied Author Names and Bios

set_author_profile is the tool the Get AI Traffic agent uses to put a real name and a real bio on an author account after you approve a fix. It sets the account’s public display name and biographical info, then publishes through your site’s connection.

This page documents what the tool touches, what it refuses to touch, and how to undo it. For the decision of who should sign a page, and when nobody should, read No Author Schema Is a Trust Problem AI Can’t Ignore. That is a judgment call. This page is about the mechanics.

What it does

The tool targets one author account, identified by login, email, or numeric id, and sets either or both of:

• Display name. The name your site prints in the byline. This is the fix for a byline reading “admin” and for the author.name that renders as an email address.
• Bio. The biographical text on the author’s profile, which is what an author bio page shows and what an author.url in your schema points a machine at.

You have to supply at least one of the two. The tool moves no posts and touches only the account you name.

The full author fix is three tools

set_author_profile on its own gives a credentialed profile that nothing points at. The fix usually runs as a sequence:

1. reassign_author moves the posts off the generic account and onto a credentialed one.
2. set_author_profile gives that person a real display name and a real bio.
3. upsert_schema adds the Person markup on the article and ProfilePage markup on the bio, so machines can connect the byline to the human.

reassign_author is worth understanding before you run it. It moves every post the source author owns, across post types and post statuses, to the target. It does not delete the source account, it empties it.

It also runs in the background rather than inline. A large author cannot be reassigned inside a single call: the batched writes run for minutes, longer than one connection survives, which was confirmed on staging at 526 posts. So the tool returns a job_id immediately and the work continues on a durable queue. Poll cms_job_status with that id for progress, and for the ledger_id you will need if you want to reverse it. If the job is interrupted it resumes where it stopped.

What it will not touch

• Your content. Both tools change attribution and profile fields. Neither edits a word of an article body.
• Users that don’t exist. Neither tool creates accounts. The target author has to already exist on your site, or the call fails with “Target author not found.” Create the user first, then reassign to it.
• Scripts in a bio. Bio text is sanitized on the way in, so markup that doesn’t belong in a profile is stripped rather than stored.
• Anything, without the right permissions. These changes require an account with edit_others_posts and edit_users. Without both, the call is refused rather than partially applied.

Timing

The display name and bio are live on the next render of any page carrying that byline, so this is one of the few fixes you can verify immediately. A reassignment is not instant: it returns a job_id right away, then works through the posts in batches, which takes minutes for a large author.

Caching is the trap here. Because the change targets an author rather than a URL, the automatic edge purge that follows a URL-targeted apply does not fire. Your site purges its own page cache once after a batch, but if a Cloudflare-cached copy still shows the old byline, run purge_cache on the affected URLs.

Downstream, the usual lag applies. Search engines and AI engines re-read the byline and the markup on their next crawl, and trust signals are not a switch that flips. Nobody re-ranks you next week because a bio appeared.

Rolling back

Both tools capture the prior state before they write.

set_author_profile records the account’s previous display name and bio, and roll_back restores them on the same account. Because the apply and the reversal both target that one user, the rollback cannot land the old profile on the wrong person.

reassign_author records its reversal once, before the first post moves, with the full captured set of post ids. That ordering matters: if the job is interrupted halfway and resumed, the ledger still holds every post, so a rollback returns them all to the original author rather than the half that happened to move. Get the ledger_id from cms_job_status once the job reports done.

Related tools

• reassign_author moves posts between authors. It is the other half of this fix and is covered above.
• upsert_schema writes the Person and ProfilePage JSON-LD that turns a visible byline into a machine-readable one.
• cms_job_status reports progress and the resulting ledger_id for the background reassignment.
• purge_cache clears a cached page still showing the old byline at the edge.

Findings this tool resolves

• author_eeat: pages are attributed to a generic or admin account with no real, credentialed author behind them.