How to Prioritize SEO Work with Claude or ChatGPT

An SEO audit can give you 200 recommendations. It rarely tells you which three deserve your time this week.

That is the harder problem. A missing meta description, an outdated buying guide, and a broken product page can all appear in the same report. Treating them as equally urgent turns SEO into a queue of tasks instead of a way to grow the business.

Start with this question: What is preventing the right people from finding—and using—our most valuable pages?

Use Claude or ChatGPT with RankParse to build an evidence ledger before choosing those three tasks. RankParse’s get_page_seo and get_site_health checks establish what the selected pages currently return; your business brief and supplied performance data establish why those pages matter. Then the assistant turns reviewed observations into assignments with owners and recheck methods. This guide walks through that process using fictional examples you can adapt to your site.

Give your assistant a business brief before asking for an audit

Connect RankParse through the Claude or ChatGPT setup guide, using the supported OAuth sign-in. Connector availability depends on your client and account; a marketplace listing is not required where a custom connector is supported. The documented web connector provides read-only SEO research. It does not change your website or automatically bring in Search Console and sales data.

Start with three inputs: the audience you want to reach, the action that matters to the business, and a short list of important pages. If you have Search Console results or conversion reports, provide a relevant, appropriately redacted export. A public page check cannot establish how many visitors became qualified leads.

Then give the assistant a bounded assignment:

Our audience is warehouse managers choosing inventory software.
Our goal is qualified demo requests, not maximum traffic.

Review these five URLs using the available RankParse page and site
checks. Use the Search Console export I provide for search demand.
Use backlink information only as additional context, and record its
snapshot date or mark the date unknown.

For each proposed task, return:
- affected page and the reader's problem
- evidence, source, and date
- likely business relevance
- confidence and missing information
- suggested action, owner, and verification step

Choose three priorities. Explain what you deferred. Do not invent
traffic, revenue, ranking causes, or implementation effort. If a
required source is unavailable, tell me what to supply.

This is a reusable prompt, not a record of a completed run. Use your own URLs and inputs. Keep the initial page list small enough that you can review the findings.

RankParse's documented on-page check can examine titles, headings, canonicals, and internal/external link counts on a supplied URL. Its site-health check adds evidence about redirects, HTTPS, and robots.txt. Those observations support investigation; they do not prove Google's selected canonical or indexing status. Confirm those in the appropriate Search Console view.

If the assistant finds a weak comparison page, a bounded backlink sample may add context about discovery and linking pages. That sample is a periodic snapshot, not the complete or current link profile. Use the finding to decide what to investigate, rather than allowing the model to turn a missing result into a confident diagnosis.

Build a RankParse evidence ledger before ranking tasks

The first deliverable is a small evidence table, not an audit score. Give the assistant a page inventory with url, page_role, desired_action, known_issue, and business_owner. Add template for a larger site so a product page is compared with other product pages rather than with the blog. Include an expected_behavior note for deliberate redirects or canonicals; otherwise a technically correct configuration can become a false alarm.

For five important pages, a useful first collection pass is one get_site_health call for the domain and one get_page_seo call per URL. Ask for check_credits first if you need to check the available balance. The page list in your prompt directs the assistant's scope; it is not an enforced execution or spending cap. Review the client's tool activity before expanding the investigation.

Use this more explicit collection prompt after the business brief:

Collect evidence before recommending changes.
Use get_site_health for [bare domain] and get_page_seo for only
these five public URLs: [URLs]. Do not expand to other pages yet.

Build one row per URL with:
- supplied page role and expected behavior
- final_url and target status_code
- title.text, canonical.url, robots.raw and robots.index
- headings.h1 and headings.h2
- links.internal and links.external as counts only
- tool name, check time, and any missing or failed result

Keep site-health findings in separate domain-level rows.
Do not classify a page as indexed, orphaned, or commercially
successful from this evidence. Return the ledger for review.

The page SEO response distinguishes the target's status_code from a successful API request. A completed tool call can still describe a page returning 404. Its title and description optimal flags assess length, not whether the copy persuades a buyer. Treat them as review cues, not automatic rewrite assignments.

Read the ledger before proceeding. Does final_url identify the intended page? Does the extracted title belong to your content, or to an access-denied screen? Does the canonical match the intended version? These checks prevent the assistant from producing a beautifully organized backlog about the wrong response.

Turn tool observations into a defensible priority

Here is an illustrative transformation with invented observations, continuing the warehouse example. It is not a recorded RankParse run.

The last row matters because the documented site-health check uses a heuristic for disallow_all; a rule disallowing only a subpath can trigger it. A rushed agent could promote this to “the entire site is blocked.” A reviewed ledger instead creates a five-minute verification task whose outcome determines urgency.

Now interrogate the candidate priorities:

Using the reviewed ledger and my business brief, create three queues:
verified fixes, investigations that could change priorities, and
optional improvements. For each row cite the evidence ID.

For the canonical discrepancy, state the two possible decisions:
what we do if intentional, and what we do if accidental. Do not
estimate revenue or effort. Mark estimates that require an owner.
Do not recommend internal-link destinations from anchor counts.

Suppose a human confirms the comparison page accidentally declares the overview canonical. The resulting assignment becomes: “Engineer corrects the comparison template's canonical; SEO owner rechecks the exact URL using get_page_seo, then reviews URL Inspection when available.” If it is intentional duplication, close that hypothesis and review whether a distinct comparison is justified. The same observation produces different work depending on intent.

Add get_page_performance only where slow interaction or loading is a plausible barrier. Record strategy and cached_at. Its reported metrics are Lighthouse lab measurements, while crux_data indicates field-data availability without supplying those field values. One low score does not establish that speed caused lost inquiries. Choose a representative template, inspect it manually on the relevant device, and ask engineering for a diagnosis before creating a sitewide performance project.

Repair incomplete evidence without inflating the audit

A failed fetch belongs in the ledger as “unverified,” not “broken page.” Check the URL, remove fragments, and inspect it in a browser. RankParse parses returned HTML; JavaScript-rendered content can be absent. If the browser shows a full comparison but the tool returns sparse headings, supply the rendered text or a browser observation and retain both sources. Do not ask the agent to reconstruct missing content from memory.

For a small team, stop collection when the top three decisions have enough evidence to act. For a larger site, group findings by template and verify another representative page before expanding the affected scope. Five checked URLs do not establish that every product page has the same fault. If you need complete internal-link relationships or affected-URL counts, provide a crawler export; page link counts cannot produce that inventory.

Save the reviewed ledger alongside the backlog. Each task should retain its evidence ID, investigation status, owner, dependency, and recheck method. This lets the next planning session distinguish “still important” from “still showing in the old audit.”

Separate emergencies from opportunities

Some problems should skip your normal prioritization process. If an important part of the site suddenly becomes inaccessible, you do not need a scoring spreadsheet before investigating.

Examples include:

• A release adds noindex to pages that should appear in search.
• An important product or signup page returns an error.
• A migration sends visitors to irrelevant destinations or redirect loops.
• A form stops working, so valuable visits can no longer turn into inquiries.

Verify the problem before treating it as an emergency. A crawler warning is a lead to investigate, not proof that users or search engines are affected. Check a representative URL, the intended behavior, and when the change happened. A traffic decline alone does not establish a technical cause.

Once immediate failures are handled, divide the remaining work into three groups:

These groups help explain the work. They are not a universal order: a technically healthy page with the wrong content may need a rewrite before anything else.

Give every recommendation a page and a reason

“Improve content” is too vague to prioritize. So is “build backlinks.”

A useful recommendation names a page or group of pages, the observed problem, and the decision it affects. For example:

Update the inventory-software comparison page because it describes features but does not help warehouse managers choose between deployment options. Search Console shows relevant comparison impressions, and sales keeps answering the same deployment question.

This is more useful than “add 1,000 words.” It connects an audience, a search opportunity, and a missing answer.

Write each candidate task in this format:

For [page and audience], fix [observed problem] so readers can [useful next step]. We believe this matters because [evidence].

If you cannot fill in the evidence, label the task as a hypothesis. That does not make it worthless. It means the first task may be research rather than implementation.

A competitor analysis can help you identify what readers expect, but competing pages are not a template to copy. Your page needs an answer that fits your audience and product.

Compare impact, confidence, and effort

You do not need a complicated score. Start with three judgments and write down why you made them.

Business impact: what becomes possible if this works?

Look beyond potential visits. A page that helps a small number of qualified buyers decide may matter more than a broad explainer that attracts people outside your market.

Useful signals include the page's role in a buying journey, relevant existing demand, and whether readers have an appropriate next step. For a publisher, that step may be another article or a subscription. For a software company, it may be a trial, a product explanation, or a consultation.

Avoid assigning revenue to traffic you have not earned. “High business relevance” is a defensible judgment; “this change will generate $20,000” needs evidence you may not have.

Confidence: how strong is the diagnosis?

A reproducible error offers stronger evidence than an intuition about a title.

For a content change, combine sources where possible: search queries, a manual page review, customer questions, and relevant search results. Each has limits. A page's low click-through rate might reflect its position or query mix rather than an unappealing title.

Use Search Console to find content opportunities, then inspect the page before deciding what to change. More impressions do not automatically mean more business value.

Effort: what will it take to ship and maintain?

Include research, review, design, implementation, and dependencies. A short article may still require a product expert who is unavailable this month. A technically small fix may affect thousands of pages and need careful testing.

Prefer ranges to false precision. “One to two working days, once the engineer is available” is more useful than pretending the job will take exactly six hours.

Maintenance matters too. A comparison full of plan prices creates a recurring verification task. A decision framework may need fewer updates, although its examples and recommendations still need review.

A worked example: choosing three tasks from an audit

Imagine a small inventory-software company with one marketer and occasional engineering help. The following observations are fictional; they illustrate a decision process, not measured results.

Its audit produces these candidates:

The company does not choose the three tasks with the biggest numbers. It fixes a real barrier, improves an important decision page, and makes that page easier to find.

The internal-link task also depends on the content task. Adding links to a weak comparison would send more readers to an answer that still does not help them. Order the work so improvements support each other.

Ask Claude or ChatGPT to turn priorities into finishable assignments

Ask your assistant to convert the selected rows into assignments, preserving the evidence and uncertainty. A priority list becomes an execution plan when each item has an owner and a definition of done. Review those assignments yourself; a read-only research connector does not implement them.

For the comparison rewrite above, the assignment could be:

• Reader: a warehouse manager deciding between cloud and on-premise inventory software.
• Deliverable: a revised comparison with deployment requirements, maintenance responsibilities, and an honest explanation of who each option suits.
• Evidence: current product documentation, recurring sales questions, and a review of relevant search results.
• Owner: the marketer, with a product specialist reviewing factual claims.
• Done when: the page answers the decision, the specialist approves the facts, links work, and the page remains accessible and indexable as intended.
• Measurement: relevant query movement and qualified demo activity, reviewed after enough time and data have accumulated.

Notice what is absent: a target word count, a guaranteed ranking, and an instruction to repeat the keyword twelve times. Those would not establish that the reader's problem has been solved.

For technical assignments, use a technical SEO audit checklist to specify the diagnosis and verification. Keep “we changed something” separate from “we confirmed the intended behavior.”

Set a review date before you ship

Choose what you will observe before making the change. Otherwise, it is easy to select whichever metric looks better afterward.

Record the affected URLs, change date, intended audience, baseline period, and expected direction of improvement. Keep deployment verification separate from performance evaluation:

Immediately after release: confirm that the intended content and functionality are live, links work, and no accidental access or indexing restrictions were introduced.

After search engines have had time to process the change: inspect relevant queries and pages. Compare similar periods and account for seasonality, brand demand, and other releases. Small samples need longer observation.

When there is enough evidence: decide whether to continue, adjust, or stop. A better average position with fewer impressions is not automatically a win. More visits without relevant engagement may mean you attracted a different audience.

A decision-focused SEO report should make those choices visible. Report what you learned and what you will do next, not just whether a line moved up.

Keep an explicit “not now” list

You will always find more SEO work than you can finish. The solution is not to keep every idea in the active queue.

Move tasks to “not now” when the audience fit is weak, the evidence is thin, a dependency is missing, or a more valuable problem needs the same person. Record what would change your decision—for example, a customer interview, a recurring indexing issue, or stronger demand for the topic.

That makes postponement a reasoned choice instead of a forgotten task.

Start your next planning session with three questions: What is broken? What valuable question are we failing to answer? What evidence would change our priorities? Build the week's work around those answers. A short plan that gets finished and reviewed is more useful than an impressive audit that never changes the site.