An SEO content audit reviews the pages you already have and records what should happen next. Keep a useful answer, update an inaccurate one, investigate overlapping pages, or review whether a page still belongs on the site. The decision should follow the page's purpose and evidence, rather than a traffic threshold.
This guide gives you a method, a copyable worksheet and an illustrative example. You can start without Search Console, provided you mark search performance as unknown and avoid treating missing data as zero.
What an audit should produce
A useful audit ends with a decision, a reason, an owner and a next step for each reviewed page. It also records what you could not verify.
An inventory lists pages. An audit evaluates them. A content refresh carries out an approved update. A technical investigation checks issues such as incorrect redirects, inaccessible pages or indexing directives. These tasks inform one another, but a technical fault does not automatically mean the article needs rewriting.
Start with a manageable section of the site. Choose a set you can read and review properly, such as one product's guides, rather than assigning decisions to hundreds of URLs from their titles alone.
Gather the pages before judging them
Build your list from the sources available to you:
- CMS or publishing inventory: what your team believes it has published, including pages absent from navigation.
- XML sitemaps: the URLs you submit for search discovery.
- A site crawl: reachable URLs and technical observations, within the crawler's scope and access limits.
- Navigation and existing records: important pages, old addresses, planned redirects and previously approved decisions.
Reconcile differences. A published guide missing from the sitemap may need a discovery check. A sitemap entry that redirects may need cleanup. An orphaned article can still deserve review even though a navigation crawl did not find it.
Google's sitemap guidance recommends listing preferred canonical URLs. A sitemap is an input to the inventory, not proof that you have found every page or that Google has indexed it.
Record the address you inspected separately from the intended canonical. Do not silently collapse different URLs until you understand their content and technical relationship. Note when your inventory is incomplete.
Review each page in six passes
1. State the reader's task
Describe who the page helps and what they should be able to do after reading it. “Help a team run an asynchronous standup” is a clearer purpose than “target standup keywords.”
Use a primary query family when it helps name the task. If you have no measured query evidence, label it a hypothesis. A useful support page, narrow reference or product explanation does not become disposable because you cannot assign it a popular search phrase.
Compare its role with related pages. The topic-cluster guide explains how related pages can serve different reader tasks. Use the audit worksheet below to record each page's role.
2. Read the answer and check consequential claims
Open the actual page. Check the instructions, examples, sources and limits. Identify anything that could lead a reader to make the wrong decision: an expired offer, unsupported percentage, obsolete product step or misleading policy explanation.
Record the specific passage and the evidence needed to correct it. “Improve quality” is difficult to act on. “The setup step names a retired menu option; verify the replacement against current documentation” gives the editor a concrete assignment.
Google's helpful-content guidance asks whether the page provides satisfying, trustworthy value. It does not prescribe a preferred word count. Adding words is not an audit outcome unless those words supply something the reader needs.
3. Add search and business evidence when available
If you have Search Console access, inspect the page and query dimensions over a relevant period. Record the property, date range, search type and filters alongside the export. Compare equivalent periods and consider seasonal demand or other site changes before attributing a decline to the content.
The Performance report documentation explains the report's dimensions and aggregation. Google also documents that performance data is generally assigned to its selected canonical URL. A variant with little reported traffic may therefore require a canonical check rather than a deletion decision.
Add business evidence if it is reliable: support usage, relevant conversions, links, or feedback from the people who use the page. Search clicks alone do not describe every page's value.
If these inputs are unavailable, write “not available.” Continue reviewing accuracy, scope and reader usefulness. Keep decisions that depend on missing evidence on hold.
4. Inspect possible overlap
Two pages appearing for the same query is a reason to compare them. It is not an automatic instruction to merge.
Ask:
- Do they serve the same reader and decision stage?
- Do they provide substantially the same answer, rather than complementary resources?
- Does either contain unique material that readers still need?
- Can one page satisfy the combined task without becoming confusing or losing a useful format?
A procedure and a reusable template can deserve separate URLs even when their queries overlap. Two procedures with the same steps and different keyword modifiers may warrant consolidation. Record the content evidence behind that judgment.
A search-results check can inform the review, but record the query, date and relevant context. Results vary. Do not represent a model-generated research suggestion as a live observation or a single search as a complete account of reader intent.
5. Separate technical diagnosis from editorial action
Check the status, indexing directives and canonical relationship when the tools are available. If you cannot, mark the technical state pending.
Google's Page indexing report explains that not-indexed statuses have different meanings. “Crawled, currently not indexed” does not by itself establish duplication or tell you to merge the page. An alternate page with an appropriate canonical can be expected behavior.
A useful page accidentally set to noindex needs a technical investigation. A wrong canonical needs a canonical review. Neither fault proves that the page's reader task is unnecessary.
6. Assign an action and a release gate
Use an action precise enough for the next person to carry out. Keep a separate technical flag, because a page can need both a factual update and a template repair.
| Action | When it fits | Next step |
|---|---|---|
| Keep | The page remains accurate and useful for a distinct task | Record review date and a sensible review trigger |
| Update | Its purpose remains useful, but a claim, example or section needs work | Brief the correction on the existing URL |
| Merge review | Two pages provide substantially the same answer and consolidation could improve it | Choose a survivor, preserve useful material and obtain approval for the URL changes |
| Retire review | The page no longer serves a useful purpose and no suitable update is justified | Assess reader dependencies and choose the appropriate technical treatment |
| Hold / investigate | Material evidence is missing or the diagnosis is unresolved | Name the missing fact, responsible person and condition for a decision |
These are editorial workflow labels, not Google ranking categories. “Merge review” and “retire review” are proposals until the necessary content and technical checks are complete.
Copyable content-audit worksheet
Use one row per inspected URL. Add fields only when they affect a decision or its execution. This worksheet is an editorial template, not a Blogoose application export.
Inspected URL:
Intended canonical / selected canonical if verified:
Inventory source and coverage limits:
Reader and main task:
Current format and unique value:
Query family and evidence status:
Performance source, date range and filters, or not available:
Business / reader evidence, or not available:
Accuracy issue and supporting source:
Closest overlapping URL and actual overlap:
Technical flag and evidence, or pending:
Proposed action:
Reason for action:
Merge target / material to preserve, if applicable:
Missing proof and release gate:
Owner and next task:
Approval / implementation status:
Review date and next review trigger:
For an update, use the SEO content brief to specify what the writer should change and what should stay. Keep the audit record linked to that assignment so the rewrite does not quietly become a different page.
Worked example: a product team's guide collection
This is a hypothetical teaching example, not a customer audit or measured search dataset. The paths below describe an illustrative site, not Blogoose URLs. No Search Console findings, traffic or outcomes are claimed.
| Illustrative page | Content observation in the scenario | Proposed action | Evidence or approval still needed |
|---|---|---|---|
/product-team-rituals |
Overview helps readers choose a routine and points to specific resources | Keep candidate | Practitioner review of advice and real destination checks |
/async-standups |
Procedure still serves its task, but a tooling step is obsolete | Update | Current tooling instructions and reviewed replacement step |
/async-standup-tips |
Repeats the procedure, with one useful troubleshooting passage | Merge review into the procedure | Confirm full overlap, preserve the passage and approve redirect/link changes |
/sprint-retro-questions |
Reusable questions provide a different format from the overview | Keep candidate | Facilitation review and confirmation that the resource remains useful |
/scrum-vs-kanban-six-person-team |
Proposed comparison lacks sufficient primary references and practitioner input | Hold | Comparison evidence before writing or release; do not treat it as published |
/agile-quotes |
Purpose and reader use are unclear from the initial review | Investigate | Read full content and check attribution, links and reader dependencies before retirement |
The standup procedure receives a scoped update rather than a new year-modified URL. The tips page becomes a merge candidate because of the inspected content overlap, not a fabricated shared-query report. The retrospective template stays distinct because the reader needs a reusable resource.
The comparison remains on hold, consistent with its missing evidence. The quotes page is not automatically deleted because its format seems less commercially useful. An unresolved purpose calls for investigation before an irreversible change.
Hand off consolidation or retirement carefully
Before a merge, name the surviving URL and move any useful, verified material into its approved copy. Check that the survivor answers the old page's relevant task. Record old-to-new URL mappings and the links that need updating.
For a permanent move, Google recommends permanent server-side redirects where possible. Ask the developer to test the old response, target, redirect chain and rendered destination. Use relevant destinations rather than sending every removed article to the homepage.
If duplicate versions remain available, review canonical URL handling. A canonical annotation is a signal for duplicate or very similar content; it is not a substitute for deciding whether two different articles should exist. Google's canonicalization guidance explains the available signals and their limits.
For retirement, choose the treatment that fits the page. A useful utility page may remain accessible while being excluded from search. A permanently removed article with no relevant replacement may need an appropriate not-found response. The robots-meta, redirect and soft-404 guides explain those separate technical cases.
Removing a URL from a sitemap does not prevent indexing. Google must be able to crawl a page to read its noindex directive. Indexing controls are also not privacy or access controls.
Validate implementation and monitor the relevant reports afterward. Processing can take time. An old URL still appearing shortly after a change is not enough evidence to declare the redirect broken or start another content rewrite.
Prioritize the decisions that matter
Correct known misleading information first. An inaccurate offer, unsafe instruction or unsupported claim can deserve attention before a page with declining clicks. Next, address broken access to useful content and clear overlap that confuses readers. Then improve incomplete answers and consider genuine gaps.
Do not use a deletion quota. A narrow page can be useful to a small audience. Google cautions against removing older content mainly to make a site appear fresh. Judge the page's value and dependencies rather than its age.
Record actual changes separately from recommendations. A spreadsheet marked “update” is not an updated page. A proposed redirect is not an implemented merge. Keep a change log so later observations can be compared with what really happened.
An audit can also identify unsupported or contradictory passages that you would not want reused in an AI-generated answer. Correct them because readers need accurate information. This review does not guarantee rankings, AI mentions or citations.
Put the review into your production process
Keep the worksheet and supporting evidence beside your draft. Verify the claims and intended destination before release. For the wider process, see the content workflow guide. If you are evaluating Blogoose, review current plans and publishing access.
Questions about content audits
How often should we audit content?
Set review triggers around what can change. Product instructions and prices need review when the underlying offer changes. A stable reference may need less frequent attention. Use a schedule your team can maintain, and bring known inaccuracies forward rather than waiting for the next batch.
Can a page be kept while its technical problem is fixed?
Yes. “Keep” can describe the editorial answer while a separate technical task repairs access, metadata or canonical handling. Record both states so a sound article is not rewritten to solve a template problem.
Does a page with no search clicks have no value?
No. First check whether the data is available, correctly filtered and associated with the expected canonical. Then assess the actual reader task and other reliable usage evidence. Low or unknown search traffic alone does not justify deletion.