What does an actionable audit finding look like?
Illustrative finding: an important service page is listed in the sitemap but its live HTML contains noindex. Expected: a public search page without that exclusion. Actual: noindex observed on the tested URL. Owner: developer. Fix: remove the unintended directive from the approved template. Retest: inspect the response and live rendering, then review later indexing evidence. This is an example, not a test result from your site.
Block indexing with noindex · URL Inspection tool
How do you decide what to fix first?
Fix confirmed blockers on important pages before cosmetic improvements. Keep assumptions separate from observations, and record confidence when the affected scope is still being investigated.
- Critical: an active security issue or widespread failure affecting important public pages.
- High: a confirmed access, indexing or task-completion defect on important pages.
- Medium: a localized clarity, linking or experience problem with a defined fix.
- Blocked: evidence or authority is missing; name the dependency.
What should happen after the audit?
Choose the next approved fix, keep its original evidence and rerun the acceptance test after the change. An audit is complete when the scoped findings and limits are documented; that does not mean every issue is fixed or rankings will improve.
What are the steps in an SEO audit?
Firstly, define the URL sample, access and baseline. Secondly, inspect important indexing and technical exceptions. Thirdly, review page usefulness and experience. Finally, prioritize supported findings, assign owners and define the retest. Keep uncertain causes labeled until the evidence supports them.
How do you audit a small-business website?
Start with the homepage and the real service, product, location and contact pages that matter to the business. Inspect each important template and the visitor’s main action. You may be able to check every important URL on a small site; record what you actually reviewed instead of claiming comprehensive coverage from a tool score.
What determines the cost of an SEO audit?
Audit cost depends on the URL count and templates, access to evidence, JavaScript or platform complexity, specialist requirements, and whether implementation and retesting are included. Ask for the scope, sample, deliverables and exclusions before comparing quotes. This checklist provides no market price estimate and does not sell an audit service.
What should an SEO audit scope include?
An audit scope states what will be inspected, why the work is being done and which decisions the findings should support. Without it, a long report can appear comprehensive while missing the business-critical pages or investigating features the website does not have.
Name the production host, relevant subdomains or sections, important page types and the actual visitor tasks. Record the available accounts and the person who can authorize changes. Note planned exclusions such as private account pages, a separate application or markets outside the assignment. An exclusion is a scope decision, not evidence that the omitted area is healthy.
Define the deliverable in practical terms: an issue backlog, a page-level revision list, a release readiness decision or an investigation of a specific symptom. State whether the assignment includes implementation and retesting. If it does not, include enough acceptance criteria for the next owner to verify the fix.
The table provides a reusable outline. It is a planning method, not a search-engine requirement. Adjust it to the site rather than filling every field with generic language.
How do you choose a representative audit sample?
A useful sample covers the different ways the site is built and used. Start with the inventory of templates, then add pages whose business role, recent change or known symptom makes them important. A homepage alone does not represent a product detail page, a filtered category, a translated page or a JavaScript application route.
Within a shared template, inspect both an affected example and a comparison page where possible. If one product page has an unexpected canonical target, ask whether the rule is shared, data-dependent or specific to that record. The comparison helps you choose the next test; it does not automatically establish the cause.
Include the edge cases that exist on this site. Those might be a moved URL, a discontinued item, a page with no optional image, or a localized variant. Do not manufacture edge cases to make the audit look larger. For a genuinely small website, reviewing every important URL can be simpler than sampling.
Record tested counts separately from inferred scope. A repeated defect across the examples supports a template-level hypothesis, but the report should still say which pages were actually checked. Expand the sample when results differ or when a proposed fix could affect a wider area. Stop calling the finding sitewide if the evidence only covers one directory.
Search Console indexing reports can supply examples of reported categories, while the site inventory establishes which URLs ought to matter. Use both perspectives. A page omitted from an example list is not thereby proven unaffected, and every non-indexed URL is not necessarily an error.
Page indexing report
How do you separate an SEO symptom from its cause?
A symptom is the observed difference. A cause is an explanation supported by evidence. Keep them separate in the issue log so that an early guess does not become a promised solution. The examples below are diagnostic starting points, not conclusions about your website.
Begin with what is known: a page fails to load, a report changed, or a search engine selected another canonical. Then gather the evidence that can distinguish plausible explanations. Record when the evidence comes from the live site and when it comes from an older crawler or report snapshot.
When observations conflict, preserve both and compare their timing and scope. A live fix may be correct even while an older indexed record still describes the original problem. Conversely, an indexed page can currently return an error. The next action should resolve the discrepancy, not simply choose the more reassuring report.
Debugging search traffic drops · URL Inspection tool · Web Vitals
What does a small, useful audit backlog look like?
The following backlog is entirely illustrative. The URLs, observations and assignments are invented to demonstrate the format. There are no claimed customer results, traffic losses or measured gains. Replace the example evidence with observations from your authorized audit.
Notice that each row identifies a different kind of work. The first concerns an unintended indexing exclusion. The second concerns a visitor path. The third records uncertainty rather than treating missing access as a technical failure. Keeping those distinctions makes it possible to prioritize and assign work without overstating what is known.
A useful ticket can be brief when its evidence is precise. Attach or reference the response or inspection record, describe the expected result and specify what must be checked after the fix. If a template change affects multiple URLs, list the tested examples and the reason for expanding the retest rather than copying the same ticket repeatedly.
Priority should remain adjustable. A broken link on the only contact path can matter more to the business than a low-impact metadata issue affecting many pages. A broad tool category can also contain intentional exclusions. The audit owner should explain the consequence instead of inheriting every automated severity label.
Block indexing with noindex · URL Inspection tool · Crawlable links and descriptive anchor text
How do you review overlapping pages without deleting useful work?
Overlap is a reason to investigate, not an automatic instruction to remove a page. Compare the visitor task, audience, actual content and available search evidence for the candidate URLs. Two pages can share vocabulary while serving genuinely different purposes. Two differently titled pages can also repeat the same answer.
Write the useful role of each page in one sentence. If the distinction depends only on a synonym, ask what a visitor gains from having both. If one page is a guide and the other is a product or service destination, preserve that difference when the content follows through. Do not make consolidation decisions from a similarity percentage alone.
Before changing a live URL, review its existing links, search observations and role in navigation. Record whether the proposed action is to improve, merge, redirect, retain or investigate further. A content recommendation does not authorize deleting published pages, and a canonical declaration is not a substitute for deciding what visitors should see.
After an approved consolidation, test the destination, incoming links and any intended redirects. Keep the earlier evidence and the reason for the decision. Search performance after the change needs its own comparable observation; do not promise a gain just because the inventory is smaller.
Creating helpful, reliable, people-first content · Consolidate duplicate URLs · Redirects and Google Search
Should an SEO audit include backlinks and promotional activity?
Include off-site context when it is relevant to the audit question and you have suitable evidence. Begin with activities the organization actually controls or commissioned: paid placements, listings, partnerships, syndicated material and past link campaigns. Record the source, purpose and relationship rather than treating every unfamiliar incoming link as a problem.
A third-party link report is an inventory from that tool, not a definitive account of how a search engine evaluates the site. Use inspected examples and known campaign context. Do not diagnose a manual action from a tool’s risk label; the relevant Search Console report is a different source of evidence.
If a known campaign relies on manipulative links, document the actual practice and route it to the responsible owner. Avoid promising that a blanket removal or disavow exercise will improve performance. The audit should identify a supported concern and the decision required, not turn an uncertain label into a destructive recommendation.
Keep legitimate references connected to real audience value. An accurate business listing or a genuinely useful cited resource has a different purpose from a mass-produced placement created only to pass ranking credit. The distinction belongs in the evidence and recommended action.
Google Search spam policies · Manual actions report
How do you hand an audit to the person who will fix it?
A handoff should let the next owner reproduce the problem without replaying the entire audit. Start with the affected URL or template, the expected behavior and the actual observation. Include the test method and date, then link the supporting evidence in an authorized location. Name the person or role responsible for the next action.
Describe the fix direction without pretending that an untested implementation is certain. If the cause is confirmed, identify the relevant rule or template. If it is still a hypothesis, explain which test will distinguish it from alternatives. A developer should not have to infer whether a screenshot shows a browser problem, a search report or an editor preview.
Define closure before implementation. For a broken link, closure is the corrected live path. For a directive mismatch, it is the approved directive in the production output. For a report-access blocker, it is the required evidence becoming available. Subsequent crawling, indexing or traffic observations can remain open as separate follow-ups.
The final audit summary should identify the scope reviewed, the most consequential confirmed findings, unresolved dependencies and the next decisions. Include what was not checked. A concise summary with an actionable backlog is more useful than pages of tool screenshots that have no owner, interpretation or retest.
URL Inspection tool
How do you reconcile different URL inventories?
Different inventories answer different questions. A CMS export can describe content records the organization manages. A sitemap describes the URLs the site has chosen to present for discovery. A crawl shows what that crawler reached under its configured starting points and settings. A search report describes what the search engine reports within its own scope. None should silently replace all the others.
Keep the source and date of each inventory. Normalize obvious presentation differences carefully, but preserve meaningful parameters, host variants and redirects for investigation. If you merge everything into one list without provenance, you can lose the reason a URL appeared in the audit in the first place.
Compare important exceptions. A preferred URL present in the CMS but absent from useful links may need a discovery investigation. A removed route still present in the sitemap may need a generation-source correction. A URL found only in a historical search report may no longer represent the intended live inventory. These are prompts for tests, not automatic defects.
Explain the reconciled scope in the report. State which sources were available, what was omitted and whether the counts describe raw records, unique URLs or inspected pages. Do not combine these quantities into a misleading total of pages audited. Keep the working inventory so the next reviewer can reproduce the selection.
Build and submit a sitemap · Page indexing report
How should you handle uncertain or conflicting audit evidence?
Use confidence to describe the finding, not to decorate it with a guessed percentage. A directly reproduced response mismatch is different from a tool warning that has not been inspected. A pattern observed across several examples is different from a complete inventory check. Say which type of evidence supports the conclusion.
When two tools disagree, compare their inputs and observation conditions before choosing a winner. They may have different crawl dates, rendering settings, URL scopes or authentication states. A report can be accurate about an earlier version while a live test is accurate about the current page. Record the difference and run the test that answers the actual question.
If a necessary test is unavailable, keep the issue blocked or uncertain. Do not convert it into a pass because no error could be observed. Equally, do not convert missing access into a technical failure on the website. Name the missing dependency and the person who can resolve it.
The report should distinguish what is confirmed, what is a plausible explanation and what remains unknown. That distinction can change the next action: implement a fix, expand the sample, request evidence or leave an intentional behavior unchanged. It prevents confident wording from outrunning the actual inspection.
URL Inspection tool
Which audit warnings deserve a second look?
A warning deserves interpretation when the flagged condition can be intentional. Not every URL should be indexed. A removed page can correctly return a not-found response. A duplicate variant can correctly point to another preferred URL. A page without a relevant structured-data implementation does not automatically need arbitrary markup.
Read the warning alongside the approved purpose of the URL. Ask what the visitor should receive, whether the page is meant for search and which behavior the site owner actually intended. Then test the relevant output. If the behavior is correct, record why the item is not an issue rather than leaving a recurring unexplained warning in every report.
Be careful with quantity-based alerts. A title-length warning may identify a place to review clarity, but an exact character threshold is not a universal Google requirement. A large number of excluded URLs may reflect filters, duplicates or private areas rather than a sudden failure. A valid schema test establishes technical properties, not a promised search appearance.
Do not use these exceptions to dismiss a real defect. An intended public page with an accidental exclusion still needs investigation, and an irrelevant redirect is not made correct by being labeled intentional. The point is to compare actual behavior with a defensible policy and useful visitor outcome.
Page indexing report · Title links in Google Search · General structured data guidelines
How do you prioritize without inventing an SEO score?
Write the consequence of the finding in plain language. Identify which important pages or visitor tasks are affected, how confidently the defect is established, and whether another task depends on its resolution. Then consider implementation effort and the risk of the proposed change. Those factors explain a sequence better than an unexplained combined score.
For example, an unintended sitewide exclusion on important public pages is a different kind of issue from a local wording improvement. A shared navigation defect may have broad consequences, while a template change proposed to fix it may also require careful regression testing. The priority record should show both the problem and the change risk.
Keep effort separate from importance. A quick edit can be worth doing soon without becoming the most consequential issue. A difficult fix can remain important even while a safe temporary mitigation is investigated. When access is missing, prioritize the dependency according to the decision it blocks rather than marking the website as failed.
Revisit the ordering as evidence improves. A supposedly broad problem may turn out to affect a narrow edge case; a small observed defect may reveal a shared rule. Explain material priority changes so the owner understands why the plan moved. Do not attach promised traffic gains to the ranking just to make the recommendation look quantitative.
What should the final audit report say?
The final report should answer the owner’s original question and make the next decision easier. Start with the actual scope and the most consequential confirmed findings. Separate recommendations ready for implementation from investigations that still need evidence. Keep the detailed task records accessible without forcing every stakeholder to read every test.
A practical summary can state the objective, inspection date, inventories and page types reviewed, access limits, highest-priority findings, responsible owners and acceptance conditions. Describe any important exclusions. If a commercial quote is being compared, state whether implementation, specialist review and retesting are included rather than treating differently scoped audits as equivalent.
Use examples to explain the pattern and link to the supporting issue record. A screenshot can be useful when it preserves a specific observation, but it needs context: what page or report it shows, when it was captured, what is unexpected and what action follows. Remove private identifiers before sharing outside the authorized audience.
End with the next approved action and the condition for reviewing progress. The audit can be delivered even when fixes remain open, provided that status is explicit. A completed document is not the same event as a corrected website, a fresh crawl or a performance improvement. Keeping those outcomes separate makes the report credible and easier to maintain.
