How to Run a Content Audit: Inventory, Decisions, and Review

A content audit is a systematic review of a defined set of website pages and the evidence about them. Its purpose is to decide what to retain, improve, consolidate, redirect, remove, or defer. The deliverable is not a URL list or a single content score. It is a set of traceable page decisions, owners, implementation tasks, and follow-up checks.

For example, a help article may receive search impressions while containing outdated instructions. A useful audit connects the URL to the relevant search period, confirms the live page and its purpose, records the evidence and uncertainty, assigns an update owner, and verifies the result after release.

Run the work in order: define the question, reconcile the inventory, collect evidence at its natural grain, review each page, approve an action, and track implementation. This guide focuses on that operating process rather than promising rankings, traffic, or conversion gains.

Choose the audit scope and success criteria

A content audit evaluates page purpose, usefulness, accuracy, completeness, intent fit, and performance evidence. An SEO audit also examines search visibility and on-page factors. A technical audit focuses more heavily on crawling, indexability, status codes, redirects, and site behavior. These areas overlap, but separating the questions makes the findings easier to interpret.

Before collecting data, write a one-sentence audit brief. Name the website property, page types in scope, reporting period, objective, exclusions, and accountable decision owner. Decide explicitly whether to include product, support, legal, media, parameter, staging, and non-indexable URLs. An exclusion is a scope decision, not evidence that those pages do not exist.

Make the objective specific enough to determine which evidence you need. Useful examples include finding pages with substantial Search Console impressions but weak click-through rate, reviewing dated product guidance, or identifying possible overlap among pages serving the same user need. These are diagnostic objectives, not guaranteed outcomes. Google Search Console provides search-performance reports and URL Inspection, but it is not a complete content-audit system. See the Search Console feature overview.

Keep the evidence dimensions separate instead of blending them into a universal score:

• Technical eligibility: status, redirects, indexability directives, robots rules, and canonicals.
• Search opportunity: clicks, impressions, click-through rate, average position, and query-to-page fit.
• Business value: configured conversions or key events, product or support role, and strategic relevance.
• Content quality: accuracy, completeness, clarity, originality, and fit with the user’s need.
• Architecture and experience: relevant internal links, page role, accessibility, mobile behavior, and available performance observations.

Build and reconcile the URL inventory

Gather candidate URLs from sources that answer different questions. A sitemap lists URLs the site owner has chosen to submit. A CMS export identifies managed records. A crawler finds pages and technical observations it can access. Search Console reports search data and information about Google’s indexed version. Analytics landing-page reports reflect configured measurement. These are not interchangeable inventories, so compare them and investigate meaningful differences.

Normalize URLs before joining observations. Resolve redirects, but retain three separate values: the URL found or crawled, the final URL after redirects, and the canonical URL declared by the page. Preserve meaningful query parameters when they represent distinct content variants, and exclude tracking or test parameters according to the audit brief. Do not silently choose between a sitemap entry, redirect target, canonical, noindex directive, or robots rule when they conflict. Flag the disagreement for technical review.

Use URL Inspection for page-specific information about Google’s indexed version. A sitemap entry is not proof that a URL is indexed, and an unsuccessful inspection should be recorded as unavailable rather than converted into a negative indexing conclusion.

A practical page inventory can include page_id, property_id, normalized_url, final_url, canonical_url, HTTP status, indexability directives, page type, owner, purpose, topic cluster, funnel stage, title, H1, last-modified date, and audit status. Keep inventory rows separate from observations. One page can have many crawl runs, Search Console rows, analytics observations, PageSpeed runs, citations, and decision versions.

Screaming Frog SEO Spider’s free version supports crawling up to 500 URLs per crawl and can export onsite SEO elements such as URLs, titles, meta descriptions, and headings. The free version has other feature restrictions. The vendor currently lists a paid license at £199 per user per year, with currency-specific pricing shown on its pricing page. Check the SEO Spider overview and current pricing and feature comparison before selecting a crawl method.

Collect evidence without collapsing different signals

Match evidence to the audit objective. Search Console can provide clicks, impressions, click-through rate, and average position for requested dimensions and periods. Analytics can provide configured events and key events. Crawlers provide technical observations. Editors assess accuracy, usefulness, and intent fit. Every observation needs its source, scope, and period.

Search Console API data is aggregated according to the dimensions requested. Google documents a limit of 50,000 rows per day per data type and property, and API access is subject to quotas. Retain the request dimensions and date range with the export. A partial or differently grouped export is not a complete page inventory. Review the Search Console API export guidance when planning collection.

GA4 is event-based, so conclusions about conversions depend on event and key-event configuration. A page with no recorded key events may have had no qualifying events, or the relevant event may not have been configured or captured. Verify the property setup before using the data to prioritize pages. If no observation is available, record it as unavailable or unconfigured, not as zero. Google’s documentation on GA4 and Universal Analytics processing explains the measurement context.

For PageSpeed Insights, distinguish Lighthouse lab results from field data drawn from the Chrome User Experience Report when sufficient data exists. Field data may be unavailable at page level and may instead be reported at origin level. Store the URL, strategy, run time, categories, field-data availability, and page-versus-origin scope. The PageSpeed Insights methodology explains the distinction, while the API method documentation describes request parameters rather than a ready-made audit pipeline.

Do not turn editorial conventions into universal ranking rules. Google does not require a keyword in an H2 or a fixed minimum number of internal links per page. Use descriptive headings and relevant links that help people and make the site structure understandable. Descriptive alt text supports accessibility and gives Google context about an image alongside other signals. See Google’s SEO Starter Guide and image guidance.

Define each record by what one row represents:

• Page inventory: one row per normalized page identity within a property.
• Crawl observation: one row per page and crawl run.
• Search Console observation: one row per returned date and requested dimension combination.
• Analytics observation: one row per page, event or key event, property, and reporting period.
• PageSpeed run: one row per URL, strategy, category, and run.
• Citation: one row per cited evidence item, not one row per page.
• Audit decision: one row per page decision version.
• CRM event: a separate record for a contact or deal event, never a substitute for a page metric observation.

Store fields such as source_system, source_record_id, observed_at, data_period_start, data_period_end, extraction_method, and parser_version with observations. Keep calculated summaries in their own records with a defined period, segment, and method. An aggregate visibility score is not an atomic page event.

Review each page and choose an action

Use the same sequence for every page: verify the page identity and purpose; check status, redirect, canonical, and indexability; compare available search and configured business evidence; assess accuracy, completeness, intent fit, and overlap; then document a decision and rationale.

Use distinct action labels so an implementation owner knows what to do:

• Retain: keep the page and record why it remains in scope.
• Update or rewrite: revise the current URL and identify the accuracy, completeness, or intent issue.
• Consolidate: combine useful material into a named destination after reviewing intent and evidence.
• Redirect: point a retired URL to a relevant, stable destination and verify the redirect after release.
• Remove: retire the page after deciding whether a replacement or redirect is required.
• Defer: name the missing evidence, owner, and next review date.

Low traffic alone is not a deletion rule. Check the page’s purpose, backlinks, configured conversions or assisted value, support or product role, legal obligations, and strategic relevance. A page that redirects should be reviewed at its final destination. A canonical conflict should be flagged. Treat overlapping pages as consolidation candidates only after an editor reviews the user need, page quality, business role, and available evidence.

A useful decision record contains page_id, recommended_action, evidence_summary, destination_url_if_any, review_status, reviewer, decision_timestamp, and implementation_status. Store the previous decision version rather than overwriting it.

Use AI only for bounded editorial assistance

Put AI after URL collection and deterministic checks. It can summarize a fetched page’s purpose, suggest a topic or funnel label, identify possible overlap candidates, or draft an update rationale from supplied evidence. It should not resolve redirects, decide canonical status, infer missing analytics, or approve deletion. Keep AI output advisory and separate from CMS changes.

For an overlap review, provide two successfully fetched, in-scope pages with stable page IDs, titles, URLs, and text excerpts. Ask the model whether the pages may address overlapping user needs, which supplied passages support that possibility, and what question an editor should answer. Do not ask it to decide consolidation or redirection.

The following is a proposed response contract, not a vendor standard. Its evidence spans must resolve to the fetched page text:

{
  "audit_run_id": "audit_2026_10_example",
  "page_id": "page_101",
  "candidate_overlap_page_ids": ["page_205"],
  "recommended_action": "review_for_overlap",
  "recommendation_reason": "Both pages address planning an editorial calendar, but intent and scope require editor review.",
  "evidence_spans": [
    {
      "page_id": "page_101",
      "text": "Exact excerpt from the supplied page text."
    }
  ],
  "confidence": 0.78,
  "review_status": "pending"
}

Validate the schema, allowlisted action values, numeric confidence range, page IDs, HTTPS source URLs where used, and evidence spans before placing the suggestion in a review queue. Reject malformed output or excerpts that cannot be matched to fetched content. A named editor or SEO owner then approves, revises, defers, or rejects the suggestion. Destructive actions and consequential factual claims require explicit human approval.

Use a stable audit_run_id and a stable property-scoped page identity. Version decisions rather than overwriting them. For concurrent jobs or retried events, use a database-enforced unique key or transactional upsert, not a lookup-then-create sequence that can race.

Three illustrative implementation patterns

The following patterns describe proposed architecture. They are not verified Make, Zapier, CMS, CRM, or vendor-module recipes.

Trigger and input	AI job	Validation	Action or fallback
Scheduled audit run with sitemap, CMS, crawler, and Search Console exports. Each record includes a property and source URL.	None for URL normalization, redirect resolution, status checks, or canonical conflicts. AI may later summarize page purpose.	Confirm final URL, retain crawled, final, and canonical URLs, and flag robots, noindex, redirect, and sitemap disagreements.	Upsert one page identity per normalized URL within the property. Send technical conflicts to the SEO owner and unexpected content to the CMS owner.
Completed Search Console export for a property, search type, requested dimensions, and reporting period. Store clicks, impressions, CTR, and position as one observation at that grain.	None for fetching, aggregation, thresholds, or sorting. Optionally summarize why a deterministic rule flagged a page.	Preserve the request dimensions and period, verify the property and quota state, and distinguish no row from zero metrics.	Route the observation to editorial review. If dimensions or access are invalid, retain the failure record and request a corrected export rather than inventing a page result.
Editor requests overlap review for fetched pages with stable page IDs and content excerpts.	Suggest possible overlapping user needs, supporting excerpts, and an editorial question. Do not choose consolidation or redirect.	Require schema-valid output, allowlisted actions, bounded confidence, and evidence spans that match fetched text.	Keep status pending until a human checks intent, accuracy, business role, backlinks, and destination suitability. Failed fetches return to collection.

For proposed identifiers, use a unique normalized URL within a property for page inventory; property, date, search type, and requested dimensions for Search Console observations; URL, strategy, category, and run ID or timestamp for PageSpeed runs; audit run, page, and citation ordinal for citations; and page ID plus decision version for decisions. Do not use only URL plus date for PageSpeed results when multiple strategies or runs are possible. Do not use only page URL plus audit date for citations when a page can have several sources.

Select tools by job, not by feature count

A lean setup may use a crawler for URL and page-element observations, Search Console for search performance and URL Inspection, GA4 for configured user events, PageSpeed Insights for lab and available field performance, and a spreadsheet or database for ownership and decisions. Start with the smallest set that supplies the evidence in the audit brief. Test a representative export and field mapping before scaling collection.

Ahrefs and Semrush offer paid SEO research and audit capabilities, with plan limits and features that can change. Ahrefs currently lists Lite at $129 per month on its pricing page, while Semrush lists its SEO Toolkit Pro plan at $139.95 per month in its official plan documentation. These figures are time-sensitive and may depend on billing terms. Consult Ahrefs pricing and Semrush plan documentation before publication.

WooRank offers website reviews, technical audits, keyword tracking, competitive analysis, reporting, and agency or API solutions. Its current pricing and plan structure were not established in this review, so verify those details before using the product in a budget or implementation plan.

HubSpot’s SEO audit kit landing page advertises a checklist, Excel or Google template, and nine-step SEO guide. The downloadable files were not inspected, so treat the page as a description of a gated SEO resource, not as a verified ready-to-use content-audit workbook.

Tool integrations and dashboards do not automatically create a complete audit dataset or write approved decisions into a CMS. Confirm account access, exports, quotas, plan limits, field availability, and required permissions before designing automation.

Turn decisions into owned work and measure completion

For each approved action, record an implementation owner, priority rationale, due date, destination or task reference, and status. Keep editorial approval distinct from technical implementation when different people own the work. After release, have the implementation owner record completion and the reviewer confirm the live page, redirect, or other change.

Store the next search or analytics observation with its own source and reporting period. Use the same definitions when comparing later data, and record relevant changes such as a redesign or tracking update. A change observed after implementation is not, by itself, proof that the audit caused it. Close the work item when the live result is verified and the next observation is saved.

Teams that need help designing handoffs, ownership, and records can explore workflow and systems consulting. For a reviewable AI-assisted process, see AI agent services.

Frequently asked questions

Should I delete low-traffic content?

Not on traffic alone. Review its accuracy, backlinks, configured business value, purpose, and strategic or legal role before deciding whether to retain, update, consolidate, redirect, or remove it.

Does every page need three internal links or a keyword in an H2?

No universal minimum or keyword-placement rule is established in Google’s current guidance. Use relevant links and descriptive headings that help readers understand the page and site structure.

How often should a content audit run?

Set the cadence according to publishing volume, change rate, content risk, and available review capacity. A fast-changing support library may need more frequent checks than a small set of stable reference pages. There is no single interval for every site.