How to Build an AI Workflow That Flags Low-Performing Pages for Refresh

You have a few hundred pages and no idea which ones are quietly slipping. Checking them by hand takes a week you do not have, so it never happens. Good news: you can let AI flag pages for refresh on a schedule, so the list comes to you instead of you going hunting for it.

This guide is for the marketing lead who owns a content library and wants a low performing pages workflow that runs itself, not another spreadsheet audit. By the end you will have seven steps: a page inventory with jobs attached, a daily data collection loop, fair baselines, named signal patterns, a transparent score with an AI triage layer, a human check, and a queue that keeps improving.

One promise up front. We are building the detector, not the repair shop. This workflow tells you which pages deserve a look and why. Deciding what to rewrite stays with you.

Step 1: Give every page a job before you judge it

Any AI content monitoring system is only as good as the list underneath it, so start with a list, not a metric. Pull every canonical content page from your CMS or sitemap and keep one row per page.

Then strip out what should never be scored: redirects, duplicate URL variants, test pages, noindex pages, and utility pages. A redirect problem is a technical case, not a refresh case.

Now the part most teams skip. Give each page a job. Is it there to win organic visitors, answer an awareness question, support a consideration decision, or generate a signup? Add the intended audience, topic, funnel stage, target queries, owner, publish date, last meaningful update, and the one success event that matters for that page.

Last, write down your decision labels before any data arrives. Something like: monitor, investigate, refresh candidate, technical fix, intent or demand issue, consolidate or redirect, prune, and insufficient data. Naming the outcomes first stops the system from turning every finding into "rewrite it."

How to tell it is done: every eligible page has a role, an owner, a target intent, a success event, and a canonical identity. You can now judge a page against its own job instead of the site average.

Where people go wrong: treating "old" as a failure condition. Age is a reason to look, not proof of a problem. A five-year-old evergreen page can be perfectly healthy, and a page published last month can be weak from day one.

Step 2: Connect your data sources and collect on a schedule

Keep the stack small and auditable. The required layer is page-level search data plus page-level analytics. Everything else is a useful add-on.

Google Search Console. Pull Search Analytics by date and page. Store clicks, impressions, CTR, and average position. Add query, device, and country dimensions when you are diagnosing one page.

GA4. Pull the Landing page report for the same page identity, filtered to organic search. Mixing every acquisition channel into an SEO diagnosis will send you chasing ghosts.

Your CMS or sitemap. Pull title, canonical, publish date, last meaningful update, content type, topic, and owner. That update date has to represent a real change, not a cosmetic timestamp bump.

Technical checks. Use URL Inspection for current crawl, index, and serving status. Use the Core Web Vitals report for real-world field experience, remembering it groups similar URLs rather than reporting each one.

AI visibility, if you track it. This is the layer most AI content monitoring misses. DeepSmith AI Visibility tracks the prompts your buyers ask, shows which of your pages AI actually cites, which prompts drive those citations, and which competitor pages win instead. It gives you mention rate, citation rate, and share of voice as a separate signal alongside your Google data. It does not replace Search Console or GA4, and it is not a detector of Google traffic decline. Treat it as the answer-engine half of the picture.

Store raw daily snapshots and a normalized page table. Never overwrite history. Every row carries its collection date, its source, and the connector's status.

A few collection rules that will save you from bad conclusions:

• Collect daily, but score only complete windows. Search Console data is typically available after two to three days, and the newest data can still change. End your scoring window several days before today.
• Query one day at a time when you are building a daily store, and check the last ten days grouped by date to see which date is actually final.
• Search Analytics returns a maximum of 50,000 rows per day per search type, sorted by clicks, and detailed page-and-query rows can be dropped. A missing low-click row is not proof the page had no impressions.
• Store canonical page identity separately from the raw landing-page string. Search Console attributes data to the canonical URL Google picked. Analytics may hand you query strings, trailing slashes, and redirect paths. Normalize before you join, or your whole model is comparing two different pages.

How to tell it is done: a daily run produces a timestamped raw snapshot, a normalized page table, a connector-health record, and a clear "data complete through" date. Pick one test page and trace it from source row to normalized record.

Where people go wrong: scoring live, incomplete data, and joining analytics paths to Search Console canonicals without normalizing first.

Step 3: Build fair baselines instead of chasing daily noise

Here is where most alerting systems fall apart. They compare this week to last week and fire constantly.

Use equal-length rolling windows instead. A solid starting configuration is the current 90 days against the previous 90 days, recalculated weekly from your latest complete date. Add a 28-day comparison for fast-moving cohorts like news or product pages.

For seasonal topics, compare the same period a year earlier. A holiday buying guide measured against an ordinary month will look like it is dying every February.

For low-volume pages, lengthen the window or compare against a peer group. Two clicks becoming one click is a 50 percent decline and it means nothing. New pages get labeled insufficient data until there are enough observations to build a baseline.

Build your peer baselines by content type, topic, funnel stage, and intent. A product comparison page should not be judged against a glossary page's CTR.

The core calculations stay boring on purpose:

click_change = current_clicks - prior_clicks
click_change_rate = click_change / prior_clicks, when the prior count is large enough
impression_change_rate = (current_impressions - prior_impressions) / prior_impressions
ctr = clicks / impressions
ctr_change = current_ctr - prior_ctr
position_change = current_average_position - prior_average_position
engagement_change = current_engagement_rate - prior_engagement_rate
key_event_rate = key_events / sessions

Two things to keep straight. A positive position change means the number got bigger, which means the position got worse. And always keep the denominator and the window next to every rate you store.

It helps to know what these metrics really are. Clicks are visits from Google Search. Impressions are appearances in results. Average position is the average position of your topmost result across impressions, not a fixed rank everybody sees. On the GA4 side, an engaged session is one that lasts longer than 10 seconds, has a key event, or has two or more page views. Engagement rate is the share of sessions that qualify. Average engagement time measures how long your site was in focus, which is context, not proof the page answered the question.

Track the rate of your key event, not the raw count. Raw counts go up and down with traffic volume and tell you nothing about the page.

How to tell it is done: every page has a current window, a prior window, peer context, denominators, a data-completeness status, and a written reason for its comparison period.

Pro tip: start with 90-day comparisons, then tune the window and the minimum-volume rule per cohort. There is no universal Google threshold that turns a page into a refresh candidate, so yours will be site-specific by definition.

Step 4: Turn signals into diagnostic branches

A single metric is never a diagnosis. Before you ask AI anything, name the patterns you expect to see and what each one usually means.

Published guidance offers useful starting patterns. One practical refresh guide treats a decline of more than 20 percent in organic traffic over 90 days, a loss of more than five positions on target keywords, falling CTR with stable impressions, and declining AI citations as investigation triggers, with higher priority when two or more fire together. Another method compares the last three months with the same months a year earlier and checks whether a decline followed a content change.

These are publisher recommendations, not Google standards. Say that out loud to your team so nobody starts quoting 20 percent as a rule.

Then set your branch logic:

1. Hard technical defect present? Label it technical fix and stop short of any refresh recommendation.
2. Two or more corroborating performance signals with adequate data? Label it refresh candidate or investigate content and intent.
3. One strong signal? Label it investigate.
4. Sparse data or a confounded period? Label it monitor or insufficient data.

How to tell it is done: every alert names the signals that fired, the comparison window, the page's role, the likely branch, and what evidence is still missing.

Common mistake: calling every decline "content decay." Falling CTR with stable impressions is a click-earning problem. A canonical error is engineering work. A seasonal dip may need nothing at all.

Step 5: Score with transparent rules, then let AI classify

Now you can automate content audit with AI without handing over the steering wheel. This is the step where you actually let AI flag pages for refresh. Deterministic gates handle the numbers. The model handles synthesis and explanation. It never gets to change a metric definition or fill in a missing value.

Your starter rule set can be small:

• Organic decay: more than a 20 percent traffic decline over 90 days against the comparable prior window.
• Ranking: more than five lost positions across the page's target query set, read from the query-level distribution rather than the blended average.
• CTR: a CTR decline while impressions stay broadly stable, with a minimum sample rule.
• AI visibility: citation rate or page share falling for the same tracked prompts across repeated collections.
• Engagement: engagement rate or key-event rate falling clearly below the page's own or its peers' baseline, with enough sessions to mean something.
• Technical: a current index, canonical, redirect, or Core Web Vitals issue. This one routes separately and raises urgency without raising the refresh score.
• Freshness and quality: dated claims, changed product behavior, obsolete screenshots, broken references. A date by itself is not enough.

Score with visible categories, not a mystery number. Add one point for each evidence category that has real support: search decline, CTR or query opportunity, business-outcome decline, quality or freshness evidence, AI-visibility loss, and peer or competitor evidence. Keep the technical flag separate. Then route:

• High priority: two or more independent categories with adequate data and real business value, or a severe technical defect.
• Investigate: one strong category, or two weak ones.
• Monitor: one weak signal, low volume, a new page, or a confounded period.
• Insufficient data: a missing source, an unstable join, or too little evidence.

This rubric is yours to tune, not an industry standard. Keep the raw evidence visible so anyone can override the score.

Then hand the model a structured record: page role, topic, funnel stage, target queries, owner, last meaningful update, current and prior Search Console values with the changes, query winners and losers, GA4 sessions and engagement and key events, index and canonical and Core Web Vitals status, AI prompt and citation data if you have it, and annotations for seasonality, core updates, migrations, redesigns, and tracking changes.

Ask for a strict output shape:

{
  "decision": "monitor | investigate | refresh candidate | technical fix | intent or demand issue | consolidate or redirect candidate | prune candidate | insufficient data",
  "priority": "high | medium | low",
  "signals_fired": [],
  "evidence": [],
  "most_likely_diagnosis": "",
  "alternative_explanations": [],
  "missing_evidence": [],
  "recommended_next_check": "",
  "confidence": "high | medium | low",
  "human_review_required": true
}

Give the classifier hard rules too. Use only the supplied fields. Quote the measured change and its window in the evidence array. Separate observation from diagnosis and say "investigate" when the cause is not established. Never recommend changing a date without a substantive update. Never recommend a refresh only because traffic is low or citations are few. Return missing evidence instead of guessing. Route technical defects away from content work.

If AI search is part of your goals, this is where DeepSmith fills the ai-visibility category for you. Its Pages view shows which of your pages AI pulls into answers and which it ignores, its competitor citations view shows whose page won instead, and Opportunity Agents read that data and return ideas with the specific data point that justifies each one. That is evidence for one signal category. It is not evidence that an AI score predicts a Google traffic recovery, so keep the two lanes separate.

How to tell it is done: the same input record produces the same decision twice, every decision points at stored evidence, and the model is genuinely able to return insufficient data.

Where people go wrong: asking a chatbot "which pages should we refresh?" with no baseline, no denominators, and no page role. You get confident prose. You do not get a monitoring system.

Step 6: Validate the flag before it reaches the queue

The automation runs up to a reviewable recommendation. A human closes the loop. That is not a weakness in the design, it is the design.

The good part: your reviewer checks the evidence, not the whole site. A well-built alert takes a few minutes to approve or reject.

Here is the check:

1. Open the page and read it against the target query and audience. Does it finish the job the reader came for?
2. Run the people-first questions. Is there a real audience for this? Does it show first-hand expertise? Does it offer original information or analysis? Is the explanation substantial and complete? Does it add value beyond restating other sources?
3. Ask what changed since the page performed well. A decline right after an edit is a different case from a decline with no edit behind it. Sometimes an edit removed the part that was working.
4. Inspect top queries, lost queries, device and country splits, the title and snippet, internal links, dated claims, and what competitors now cover.
5. Check crawl, index, and serving status with URL Inspection. Not indexed or wrong canonical means technical review, full stop.
6. Read Core Web Vitals in context. It is grouped field data and a sample of indexed URLs, so treat a poor group status as a lead, not a per-page verdict.
7. If AI search matters to you, read the tracked prompt answers and the citation history. Compare the competitor page that won: what does it cover that you do not? Do not infer a Google ranking cause from an AI result.
8. Record the verdict: keep monitoring, refresh candidate, technical fix, intent or demand issue, consolidate or redirect, prune, or false positive.

One warning worth repeating to anyone who touches the queue. Google explicitly asks whether a site changes page dates to look fresh without substantial change. Record a real update, and never move the date on its own.

How to tell it is done: a reviewer can decide quickly because the alert carries the page's role, the exact signal, the comparison window, the data-completeness state, and the next check. Every rejected flag has a reason attached.

Common mistake: treating an AI diagnosis as the final editorial decision. The model can compare patterns and organize evidence. It cannot prove a competitor caused your decline, or that a rewrite will win the traffic back.

Step 7: Route it, alert gently, and improve the detector

You are nearly there. The last step is what makes this a system instead of a project.

Send approved cases to a queue, never straight to a publishing tool. Each row carries page identity, priority, decision label, owner, signal summary, both windows, the evidence, what is missing, the suggested next check, the reviewer's verdict, and the date it was last evaluated.

Use a weekly digest for content leads. Save instant alerts for severe technical or business-critical cases only. A digest turns this into a prioritization tool. Constant pings turn it into noise everybody mutes by week three.

Keep an immutable run log: inputs, rule version, model version, output, reviewer decision, and any outcome later. This is how you find out whether the detector is actually any good.

After a page gets reviewed or changed, resist declaring victory from a two-week bump. Re-evaluate against an equivalent complete window and write down the result.

Review false positives monthly and sort them into buckets: low-volume noise, seasonality, tracking errors, technical cases misrouted as content, competitor or SERP changes, and pages that were simply healthy. Then tune cohorts and thresholds. That monthly hour is what turns a noisy first version into something your team trusts.

Keep your AI-search monitoring separate from your Google-search monitoring, and show both on the page record. A page losing Google clicks while gaining AI citations deserves a very different decision from a page losing both.

How to tell it is done: the team gets a ranked, explainable queue on a predictable cadence, knows which rows need human review, can see why every page was flagged, and can measure the false-positive rate over time.

Where people go wrong: building alerts that fire on every week-over-week wobble. Collecting continuously is not the same as intervening continuously. Collect often, act only when the evidence is comparable and meaningful.

What to do next

You do not have to build the whole low performing pages workflow this month. Pick one cohort, maybe your top 30 blog posts, and run just the collection loop for a few complete windows. That alone will surface pages needing update sooner than any audit you keep postponing. Let the data pile up before you write a single rule.

Then add baselines. Then add the gates. Then add the classifier, and let it flag pages for refresh in a queue you review. Each layer is useful on its own, and each one gets better because the layer under it exists.

If AI search is part of your growth plan, the visibility half of this model is the piece you cannot get from Search Console. DeepSmith tracks the prompts your buyers ask, shows which of your pages get cited, and connects those gaps to the content that closes them. Start a free trial and see what your pages look like inside AI answers before you build another spreadsheet.

Take it one cohort at a time. Momentum matters more than a perfect first version.