How to verify AI SEO recommendations before making changes

“Merge these pages.” “Disavow these domains.” “Rewrite your titles.” An AI-generated SEO audit can make consequential changes sound like routine housekeeping.

Before acting, ask a more useful question than whether the recommendation sounds sensible: what evidence would make this the right change for this site?

A verified recommendation connects an observed problem to a proposed action, explains why the action should help, and acknowledges what might make the diagnosis wrong. That standard applies whether the advice comes from an assistant, an automated audit, or a person.

Use RankParse in Claude or ChatGPT to retrieve the page and link records behind a claim, then check whether those records justify the proposed change. The workflow below turns that review into an evidence ledger and an act, investigate, or reject decision. Spend the most scrutiny on actions with a large scope, uncertain reasoning, or a difficult rollback.

Start by extracting the actual claim

AI output often mixes three things in one sentence:

These pages compete for the same keyword, which is hurting rankings, so you should merge them.

That sentence contains an observation, a causal explanation, and a proposed change. Each needs a different check.

• Observation: multiple pages appear for a query. Verify the query-to-page data, reporting period, and filters.
• Explanation: the overlap is harmful. Examine intent, page roles, performance patterns, and alternative explanations.
• Action: a merge is the best remedy. Consider what useful content, conversions, links, or distinct journeys could be lost.

The observation can be accurate while the explanation and action are wrong. Two pages can serve different needs around the same topic. A guide and a product page do not automatically need consolidation because both receive impressions for a broad query.

Rewrite the advice into those three parts before you evaluate it. This alone exposes many unsupported leaps.

Use a small evidence ledger

For recommendations likely to enter your backlog, keep a record that another person can inspect without reopening the entire chat.

Do not treat a citation as a completed check. Open it. Confirm that it supports the specific claim, describes the relevant product or search behavior, and has not been used outside its context.

For a metric, inspect the source report or returned record. A screenshot or summary can omit filters, mix reporting periods, or confuse a domain with a particular page. If the underlying evidence is unavailable, the recommendation remains unverified.

Match the source to the claim

A source can be trustworthy and still be unsuitable for the question.

A public browser can inspect accessible page content. It cannot establish your private organic click history. A backlink index can identify observed relationships, but it cannot prove that every link is still present. A current HTML fetch can reveal a canonical declaration, but it does not prove Google's selected canonical.

Connected tools do not remove those boundaries. They require the appropriate account authorization, and their datasets have their own coverage and freshness limits. In RankParse, public link data is served from a periodic snapshot; confirm the dataset date before relying on its freshness. Live page checks and stored rank tracking observations have different collection behavior. The secure OAuth connector does not expose Search Console; that integration is available through the API-key endpoint with authorization configured. See the MCP documentation when checking a claimed capability.

When an assistant says it “checked” something, ask what it actually retrieved. A failed connection, inaccessible page, or empty result must not become evidence of absence. Unknown is a valid result.

For a broader source-selection framework, see SEO MCP versus AI browsing.

Run a claim review with RankParse

Keep the original recommendation intact so the assistant cannot quietly weaken it after seeing contrary evidence. For this exercise, suppose an audit says: “The guide has no useful internal links and a poor title. It is not indexed. Merge it into the product page.” That is four claims, with very different evidence requirements.

Use a configured RankParse OAuth connector in Claude or ChatGPT; the MCP setup guide covers connection prerequisites. This procedure uses read-only tools and supplied evidence. It cannot publish edits, redirect pages, send messages, or fetch private Search Console reports through the web connector.

Prepare the review packet

Supply the recommendation verbatim, the exact affected URL, the proposed destination URL, and the original audit or excerpt. Add the audit's collection date and known coverage. Include the page owner's intended purpose for each URL and any relevant product requirements.

If the claim depends on search performance, supply the authorized property report, reporting periods, query/page dimensions, device and country filters, and export limitations. If it depends on Google indexing, ask the property owner for the relevant URL Inspection evidence and its observation date. Neither a sitemap entry nor a successful HTML fetch answers that indexing question.

Give the assistant this first stage:

Review this recommendation without changing its wording: [paste it].
Targets: [guide URL] and [proposed destination URL].
Split it into factual observations, causal explanations, and actions.
For each, state the minimum evidence that could verify or contradict it.
Map public page claims to RankParse get_page_seo.
Map search performance or Google indexing claims to the supplied
owner reports, if present. Mark missing private evidence unavailable.
Do not decide whether to merge until the claim table is complete.

Retrieve the facts and retain their scope

For each of the two URLs, run get_page_seo. Preserve the returned final_url, status_code, title.text, title.optimal, canonical.url, robots.raw, robots.index, headings.h1, headings.h2, and links.internal. Record the retrieval time yourself rather than implying every tool returns a collection timestamp.

These fields answer narrower questions than an audit often suggests. title.optimal is a length heuristic, not an evaluation of intent or writing quality. robots.index: true reflects the absence of a parsed noindex directive in the robots meta tag; it is not proof of Google indexing. links.internal counts outgoing anchors whose host matches the final page host. It does not tell you whether useful links point into this guide or where its outgoing links lead.

Use get_page_seo on the two supplied URLs and keep the raw records.
For each original claim, quote the relevant returned field and value.
Use verified, contradicted, or unresolved for factual observations.
Give causal claims their own row; do not mark causation verified merely
because the associated observation is true.
If content appears blocked or unrepresentative, mark the check unresolved.
List the smallest additional browser or owner-report check required.

Check the original tool responses, not just the assistant's table. The Page SEO documentation explains that the tool parses raw HTML; JavaScript-rendered content is outside that response. A 200 response containing a challenge screen can produce a technically valid audit of the wrong content.

Interpret an illustrative record

The following values are invented examples, not measurements from a run:

The wording matters. “No internal links” can be contradicted by a count. “No useful internal links” needs a qualitative check. An assistant that swaps one for the other can make a weak audit look verified.

Ask for a repaired recommendation after checking the actual page:

Revise the proposal using only the verified claims and owner requirements.
Keep unresolved claims visible. Explain which original claims were withdrawn.
Choose act, investigate, or reject for the proposed merge.
Return one decision card with evidence IDs, missing checks, owner,
smallest justified change, rollback approach, and validation method.
Do not generate a redirect mapping unless consolidation is justified.

An illustrative decision card could read: “Investigate the merge; no approval to redirect. The page check contradicts the absence of outgoing internal anchors, but it cannot evaluate link usefulness or indexing. Editor to review actual destinations; property owner to supply URL Inspection evidence. Retain both URLs while reviewing their distinct purposes. Consider an accurate title edit only after editorial review.” The outcome is useful even when the original recommendation is rejected.

Check link claims without creating false corroboration

If the merge proposal claims the guide has no backlinks, use get_backlinks for its domain with a stated limit and sort: recent, then inspect the returned to_url values for the guide. Keep matching from_url, anchor_text, rel, and crawled_at. A matching record supports a historical observed relationship; absence from that bounded sample cannot verify “no backlinks.” Open selected source pages when preservation depends on their current placement.

For a domain-level risk recommendation, get_link_audit can identify records worth investigating, but running another tool that uses the same link graph is not independent confirmation of a penalty. A domain authority score is neither a Google ranking factor nor a verdict on the business. Keep the original acquisition history and appropriate owner-supplied evidence in the review.

Work through the recommendation, not just the wording

Consider a hypothetical retailer selling ergonomic office furniture. An assistant recommends three changes after reviewing a limited export. The findings below are illustrative; no site or account was tested.

Recommendation 1: Merge two standing-desk pages

The assistant notices that a category page and a buying guide both receive impressions for “standing desks.” It calls this cannibalization and recommends redirecting the guide to the category.

What to verify: inspect query-to-page patterns over a suitable period, then compare the pages' purposes. The category may serve people choosing a product; the guide may help people compare desk types and dimensions. Check relevant conversions or assisted journeys where your measurement supports them, along with existing links and unique useful content.

What could change the decision: if both pages target the same purchase task, repeat the same information, and regularly alternate for the same relevant query segment, consolidation may deserve investigation. Even then, overlap alone does not prove that consolidation will improve performance.

Possible outcome: retain both pages, clarify their roles, and add a contextual path from the guide to the category. If a merge is justified, plan redirects, preserve useful content, update internal links, and verify the result. A URL deletion should not be the default response to a spreadsheet overlap.

Recommendation 2: Rewrite a title because CTR is low

The assistant sees a low aggregate click-through rate and proposes a more dramatic title.

What to verify: break the report into comparable query, device, country, and position groups where the available data supports it. A page receiving more impressions for broad informational searches may have a lower overall CTR without having a worse title. Search-result features and changing intent can also affect click behavior.

Open the page and inspect the title. If you review public search results, record the context and remember that the observed title may differ from the HTML title and may vary across searches.

What could change the decision: a vague or inaccurate title that fails to describe the page provides a concrete editorial reason to revise it. A title that is accurate and useful should not be replaced solely to meet a universal CTR benchmark.

Possible outcome: make a limited, accurate title improvement, record the date, and review comparable segments after enough data accumulates. Avoid promising a particular uplift or attributing every later movement to that edit.

Recommendation 3: Disavow links labeled risky

The assistant converts an automated risk score into a removal list.

What to verify: examine the actual source pages, link context, acquisition history, and any relevant Search Console manual-action information available to the property owner. Automated scores are triage signals, not evidence that Google penalized the site.

Google describes disavowal as an advanced feature that most sites do not need. Its official disavow guidance gives the circumstances to consider and warns that incorrect use can harm performance.

Possible outcome: reject the bulk action and request a qualified review if the site's link-building history or manual-action evidence warrants one. A low authority score or unfamiliar domain is not enough. The guide to evaluating backlink quality provides a more useful editorial assessment.

These examples share a pattern: the initial signal is worth checking, but the proposed action outruns the evidence.

Set the review depth by consequence

A typo correction and a sitewide canonical change should not follow the same review process.

The boundary should be explicit before an assistant has tools that can execute changes. “Investigate why these pages declined” authorizes research in the agreed scope; it should not silently become permission to publish rewrites or remove URLs.

Keep the proposed change reviewable. A diff, URL mapping, or clearly scoped ticket makes it easier to judge than a broad instruction to “optimize the site.”

Ask for contradictions before asking for confidence

A model's confidence score is not a substitute for source quality. A more revealing request is to ask what would disprove the recommendation.

Review this SEO recommendation before we approve it.
Separate the observation, causal explanation, and proposed action.
For each factual claim, identify the source and its scope and date.
Mark anything unsupported or unavailable as unknown.
List the strongest alternative explanation.
State what evidence would make you withdraw the recommendation.
Propose the smallest useful next check and a proportionate validation plan.
Do not publish, redirect, submit, or change settings.

If the assistant cannot name a plausible alternative or a disconfirming observation, ask a reviewer with the relevant expertise to examine the reasoning. Repeating the same question in a new chat may produce different wording without providing independent evidence.

For large changes, seek an independent source or a direct reproduction. Another summary of the same underlying report is not independent confirmation.

Handle failed checks explicitly

A verification workflow should produce a useful disposition even when evidence is incomplete.

For one page, an editor can own the entire ledger. For a template-wide change, assign a technical reviewer and keep a sample register with exact URLs and reproduction results. Do not convert the number of checked examples into a count of every affected page. Use a crawl export for full link relationships and document its coverage separately from live RankParse spot checks.

Verify the implementation separately from the outcome

After an approved change, first check whether it was implemented correctly. Does the redirect reach the intended destination? Does the edited title appear in the served page? Did internal links change as planned? This is implementation validation.

For an approved title or canonical edit, repeat get_page_seo on the same URL and compare the changed field, final_url, and status_code with the saved baseline. Open the page to confirm the user experience. For internal-link edits, inspect actual anchors or a fresh crawl export; unchanged link counts cannot establish that the intended destination was added.

Then evaluate whether the business or search outcome improved using a suitable time horizon and comparable data. Some technical checks can happen immediately; search performance may take longer to interpret. Seasonality, concurrent releases, and competitor changes can limit what you can attribute to one action.

Record both results. “The redirect works” and “the consolidation helped readers and search performance” are different claims with different evidence requirements.

What to build next

Put the evidence ledger beside your SEO backlog. Require it for consequential recommendations, and keep lightweight checks for small editorial fixes. Use SEO audit prioritization to decide which verified opportunities deserve time first.

The final decision can be to act, investigate further, or decline the suggestion. All three are useful outcomes when the evidence supports them.