An audit can hand you hundreds of warnings. Your first job is to decide which ones are getting in the way.
A broken enquiry link deserves attention before a missing social preview image. An accidental instruction to keep a service page out of Google deserves attention before polishing its description. And a page you published on Monday needs a different diagnosis from one that lost traffic after years of steady visits.
This technical SEO checklist helps you make those calls. It is written for business owners and marketers who can inspect a website and hand a specific repair to a developer. You will need access to Google Search Console for the index checks; a browser and PageSpeed Insights cover much of the remaining first pass.
Choose the audit scope before counting issues
Start with the homepage, the pages that explain your main offers, a representative article and the route to your intended conversion. For a larger website, add examples from each important page template. Record which URLs were actually retrieved, the test date and any blocked or timed-out pages. A sample can reveal a template problem, but it does not establish that every page passed.
Keep four outcomes distinct: checked and passed, checked and needs work, not applicable, and unable to check. An unavailable result is not a zero score. Assign an owner to each confirmed issue and prioritize problems that prevent access or interrupt an important visitor task.
| Priority | Examples | Acceptance condition |
|---|---|---|
| Access and essential paths | A failed product page; an unintended noindex; a broken contact link | The intended page can be reached and the specific blocker is removed |
| Discovery and interpretation | A missing contextual link; conflicting canonical signals; misleading page title | The page and its signals consistently describe the intended destination |
| Experience and maintenance | Slow template; shifting layout; stale sitemap entry | A comparable recheck confirms the intended improvement |
The technical SEO audit checklist
1. Check the actual HTTP response
Open each important URL and inspect its response status. A page intended for indexing should deliver usable content with a successful response, rather than an error page disguised as success. Follow redirects to the final destination and check that it is the right page. A deliberate redirect or a genuine missing-page response is not automatically a defect.
Recheck: load the exact public URL after release and record the status and final destination. Google's technical requirements distinguish eligibility for indexing from a guarantee of inclusion.
How to check: in Chrome, open Developer Tools → Network, reload the page and select the main document request. Read its status and final URL. Then look at the page itself.
Make the call: a public service page returning 500 needs repair. A retired offer returning 404 may be correct. A 200 response showing “page not found” still needs investigation. If a page moved permanently, point its old URL to the closest appropriate replacement, then update links that still take the detour.
2. Review crawl access and indexing directives separately
Check robots.txt rules, page-level robots metadata and HTTP X-Robots-Tag headers. Confirm that any restriction matches the page's purpose. Public landing pages and private account pages have different requirements; do not remove every exclusion to make an audit look clean.
Blocking crawling is not a reliable way to keep a URL out of search. Google needs to retrieve a page to see its noindex instruction. For a public URL you want indexed, inspect both crawl access and indexing permission in Search Console. See Google's technical SEO guidance.
How to check: inspect the exact URL in Search Console. If access is blocked, identify the matching robots.txt rule. If indexing is disallowed, look for noindex in the page's robots tag or X-Robots-Tag response header.
A common launch mistake: a staging site's noindex setting survives the move to production. Remove it from the intended public pages, check the live response, and leave private pages protected. Do not change a rule until you know which URLs it affects.
3. Compare the live test with Google's stored index record
Use URL Inspection for a specific page. Save its last crawl date, fetch result, indexing status and canonical information. Then use the live test if you need to check the current page. A successful live test confirms current availability; it does not mean the URL is already indexed. Google's URL Inspection documentation explains the two views.
Recheck: resolve a demonstrated blocker, verify the current page, and later inspect the stored index record. Avoid claiming that submitting an indexing request caused a ranking improvement.
| Result | Your next step |
|---|---|
| Unknown or discovered, not indexed | Check the launch date, useful internal links and sitemap. Run a live test to look for an actual access problem. |
| Crawled, not indexed | Google has retrieved the page. Inspect its purpose, useful content and duplicate versions before assuming a crawl block. |
| Indexed, few impressions | Investigate query fit, competition and page age. Repeated indexing requests do not answer those questions. |
| Live test passes | The current page is available. Check the stored record later to learn whether Google included it. |
4. Align canonical URLs, redirects and internal references
For duplicate or substantially similar URLs, choose the version you want visitors to use. Check that canonical annotations, sitemap entries and internal links support that choice. Do not point unrelated useful pages at the homepage as a shortcut.
A canonical is a signal, not a command. Google can select another version. A missing annotation alone also does not prove a page cannot be indexed. Review Google's canonical guidance, then verify both the declared and Google-selected canonical where available.
How to check: find rel="canonical" in the page source or rendered head. Open that destination. Compare it with the URL in your sitemap and the Google-selected canonical in URL Inspection.
Example: if a useful /services/roof-repair page names / as its canonical because a template copied the homepage setting, investigate and correct that mismatch. A tracking-parameter copy pointing to the clean service URL may be intentional.
5. Make important pages reachable through useful links
Link from a relevant existing page to each important new destination. Use descriptive anchor text that helps a visitor decide whether to follow it. Check that links use an actual URL in an anchor's href attribute, rather than depending entirely on an unsupported click handler. Google's link guidance covers crawlable markup and anchor text.
Recheck: follow the link from its source page, confirm the destination and inspect the final response. Test navigation, in-content links and the main next-step CTA—not just the homepage menu.
How to check: start at the homepage or a relevant hub and find a normal route to the page. Then test its links to the next useful action. Use a crawler's internal-link report to extend this check across a larger site.
A useful repair: add a link to a new installation guide from the matching product page, with an anchor such as “installation requirements.” That helps a customer and gives the guide a discovery path. Adding the same link to every footer is not a substitute for context.
6. Keep the sitemap consistent with the public site
Include canonical URLs you intend to make discoverable. Remove obsolete entries and avoid publishing private account routes in the public sitemap. Check that listed URLs resolve as intended and that modification dates represent meaningful changes rather than an automatic daily refresh.
A sitemap helps communicate URLs to Google; it does not guarantee crawling or indexing. Follow Google's sitemap instructions and compare the published file with your actual page inventory.
How to check: find the sitemap in Search Console or the Sitemap entry in robots.txt. Open several listed URLs, including a new page and an older page. Check that they are the public versions you intend to promote.
After a repair: retrieve the published sitemap again. Confirm the changed entry, rather than relying on a successful save in the CMS. Keep a sitemap submission separate from proof that Google has crawled its URLs.
7. Check the content visitors and crawlers can retrieve
For a JavaScript site, compare the initial response with the rendered page. Confirm that the main explanation, important links and page signals remain available after rendering. Investigate failed scripts or blocked resources that prevent useful content from appearing.
Client rendering is not inherently an indexing failure. Google's JavaScript SEO documentation explains how crawling and rendering interact. Record what was actually visible in the tested environment instead of inferring the result from the framework name.
How to check: view the rendered HTML and screenshot available from Search Console's live test. Look for the page's main offer, important facts and next-step link. Compare them with a real phone visit.
Separate two problems: if Google cannot retrieve the main content, investigate rendering and resource access. If the content is present but a mobile overlay hides the enquiry button, fix the visitor experience. Both matter, but the evidence and repairs differ.
8. Review titles, headings and page purpose
Read the title, main heading, opening explanation and description together. They should identify the same offer or question and distinguish the page from close neighbors. Check that important service details are visible text and that internal anchors describe their destinations.
Read the title aloud without looking at the page. Would someone know what they would get by clicking? Google's title guidance favors descriptive, concise titles and explains why the displayed search title may differ from your title tag.
Example: “Services | Acme” says little. “Commercial roof repair in Tampa | Acme” is more useful if that is what the page actually offers. The heading and body should substantiate the same service and location.
Make the call: improve an unclear title or a repeated template title. Do not stuff several close synonyms into it. Keep a practical guide and a product page distinct even when their keywords overlap.
9. Validate relevant structured data
Check markup against the page's visible, accurate content and the requirements of the feature you intend to support. Test eligible markup with Google's Rich Results Test. A warning for a field that does not apply to the page is different from broken syntax or a misleading claim.
Do not add invented ratings, prices or credentials to satisfy a checker. Passing validation does not guarantee a rich result. Google's structured data policies explain those limits.
How to check: submit the URL to the Rich Results Test. Open each detected item and distinguish an error from an optional recommendation. Compare the values with the visible page.
Make the call: a product page with an incorrect published price needs attention. A service page should not acquire a fictional Offer merely to remove a warning from a generic audit tool. Check the relevant schema type before changing anything.
10. Measure performance in a comparable context
Test representative templates on mobile and desktop. Record the page, device and test conditions. Separate controlled lab measurements from field data about real visitors; a page may have too little field data to report.
Use loading, responsiveness and visual stability findings to identify work that improves the experience. Retest the same page under comparable conditions. Google's Core Web Vitals guidance explains the metrics and makes clear that good scores alone do not guarantee top rankings.
How to check: enter a representative URL in PageSpeed Insights. Read the real-user section separately from the lab diagnosis. Note whether field data is for the specific URL or the wider origin, and whether it is available at all.
Choose a repair from the diagnosis: an oversized hero image may delay the main content; a late-loading banner may shift it; a heavy script may delay interactions. Save the evidence, make one focused change and repeat the test. Use several comparable lab runs before calling a small difference an improvement.
| Metric | What it describes | Good threshold |
|---|---|---|
| LCP | Main content loading | 2.5 seconds or less |
| INP | Response to interactions | 200 milliseconds or less |
| CLS | Unexpected layout shifts | 0.1 or less |
Thresholds apply at the 75th percentile of real page visits, assessed by device category. A Lighthouse lab score is not an INP measurement. Source: web.dev. PageSpeed's field data covers a trailing 28-day period, so it will not immediately reflect a fix published today. About PageSpeed Insights.
What if the page launched this week?
Record publication date, first observed crawl and first impressions separately. A report covering several months of site history does not give a three-day-old page several months of exposure.
A newly published service page may pass a live test before it appears in Google's stored index record. That tells you the current page is accessible; it does not establish whether Google has selected it for search. Check the publication date, discovery links and current response before deciding that something needs repair.
We check discovery weekly and investigate persistent non-indexing after roughly two to four weeks, sooner if there is an actual blocker. Google says crawling can take days to weeks and that repeated requests will not make it faster. Read Google's recrawl guidance. Our review interval is a working schedule, not an indexing deadline.
For content performance, make a first review around 30 days after launch, then revisit at 60 and 90 days. Include the first indexed date and the number of impressions. Ten impressions cannot tell you as much as a sustained pattern of relevant searches.
Worked example: repair a broken enquiry path
Illustrative scenario: a service page's “Request a quote” button still points to a retired enquiry form. The current form works, but visitors following the old link reach a missing page. Here is how to turn that finding into a repair someone can complete and verify.
- Page to inspect
/services/commercial-roof-repair- Problem
- The quote button points to
/enquiry-old, which returns a missing-page response. - Proposed change
- Update the button to the current
/request-a-quotepage. Check for other links using the retired destination. - Acceptance test
- Open the service page on desktop and mobile. Follow the quote button, confirm the intended form loads, and test validation. Complete a clearly identified test submission only with the form owner's approval.
- Evidence to record
- The original destination, updated link, final response, test date and any remaining form errors.
- When to close the issue
- After the agreed checks pass on the public site. Record any untested submission step separately.
The repair brief connects a technical finding to a customer task. Verifying that the path works closes that issue; measuring any effect on enquiries or search performance is a separate follow-up.
Turn the audit into work someone can complete
Use this brief for each confirmed issue. Keep uncertain findings open for investigation instead of automatically assigning a repair.
- URL and scope: the exact page, template or retrieved sample.
- Observed problem: what happened, when and in which tool.
- Impact: the visitor task or retrieval step affected.
- Change and owner: the smallest supported correction and the responsible person.
- Acceptance test: the exact result that would verify the repair.
- After evidence: the public URL, test date and result after release.
“Fix technical SEO” is not a workable assignment. “The contact link on this service page opens a missing URL; update it to the current contact page and confirm the full path works on mobile” is. Download the editable brief and use one issue block per repair.
Site Health brings together Site Analysis, Page Speed and Link Analysis for supported page and capped site checks. Use the recorded scope, then carry supported findings into Fix Center and verify the published change. Use Search Console separately for Google's index record.
When you need a deeper audit
These ten checks are a useful foundation for a business website. A large store, migration or multilingual site needs additional work. Ask for a specialist review when filters create thousands of URL variants, a redesign changes many URLs, international pages need language/region targeting, or important content depends on complex rendering. Server logs, crawl comparisons and template-level investigations can then answer questions a small page sample cannot.
What can wait?
Leave intentional private-page exclusions alone. Do not rewrite accurate titles merely because a tool prefers another length. Do not add irrelevant schema properties to eliminate optional warnings. And do not respond to a newly published page's lack of impressions by repeatedly changing its URL and starting over.
Finish the highest-impact repair, verify it, and move to the next one. Keep unresolved questions on the list with the evidence you need to answer them.
How does technical SEO relate to GEO?
Retrievable pages, clear facts and useful links support a sound publishing foundation. They do not establish that an AI service recommended your business. Our GEO vs. SEO guide explains the overlap; AI Visibility observes grounded answers to configured buyer questions as a separate measurement.