Refresh old WordPress posts with Search Console queries and Claude

WPShout's workflow starts in the Search Console Performance report: compare the last three months with the previous three, and look for posts where clicks and impressions fall while average position still sits between 5 and 20. A post at position 12 can realistically reach the top five, and the click difference between those spots is large.

Unstale sorts posts into four buckets from the same three numbers, clicks, impressions and average position, read over twelve months: high traffic, declining traffic, no traffic but still relevant, and no traffic with no value. Its warning is the useful one: do not automate deletions, and read the last bucket one post at a time.

Linkeddit's striking_distance view applies the first filter for you, and its ctr_opportunities view finds the posts that already rank well but are under-clicked, where a title and description fix can be enough.

The ranking guides (WPShout, Enfra, Blogr, Unstale) all say the same sequence: find decaying posts, audit what is out of date, rewrite for current intent, republish without breaking the URL. They stop at advice. None connects the query list to the edit, so the step where you map a query to its post and a post to its blocks stays manual.

That is where an AI client in the middle helps. Linkeddit supplies the queries. The WordPress.com connector supplies content search, posts.get and block-level edits. Claude does the matching and the drafting, and you approve every write.

Unstale adds a point most guides skip: a spreadsheet only knows pages that were clicked, so posts that bring nothing never enter it. The WordPress.com connector can list every post with posts.list, which lets Claude compare your full post list against the queries Linkeddit returns and flag the posts that no query points to.

One limit to know: WordPress.com's own statistics.get returns site totals and views for a date range, and the vendor says it does not include top posts, referrers or per-URL breakdowns. Per-query data has to come from Search Console, which is why Linkeddit sits in this workflow.

Unstale lists five things never to do to a post that ranks: change the URL or slug, rewrite it from scratch, take it offline or noindex it while you work, automate deletions, or strip the sections that already answer the query. A backlink points at an address, so the same URL keeps every link.

Block-level editing fits those rules. WordPress.com's post-sections.replace swaps one top-level block and leaves the rest untouched, and the vendor states that posts.update with a status of publish goes live immediately, so keep Claude on show-before-after.

On dates, Unstale quotes John Mueller's 2019 Search Central post: if you update a page significantly, also update the visible date, and you can show both dates when they are visually clear. Move a date only when the content behind it moved.

Enfra's walkthrough suggests measuring at 30, 60 and 90 days, and Unstale notes that asking Search Console to recrawl guarantees nothing, it is only the fastest way to tell Google the page changed. Do not judge a refresh after a week.

In Linkeddit, re-run the same striking_distance and ctr_opportunities views and compare each query's position, impressions and clicks with your baseline. If a query moved from position 14 to 8 you have a result. If impressions rose and clicks did not, the title and description are the next edit.

This connector is WordPress.com's. The vendor documentation says Jetpack-connected self-hosted sites use the same server and tool catalog, and does not describe a route for a self-hosted site with no Jetpack connection.