A useful technical SEO checklist helps you decide what needs attention and how to confirm a fix. Start with the pages that matter to your business, define their intended behaviour, then compare that expectation with evidence. Prioritise observed problems without assuming every change will improve rankings or traffic.
Start with the pages that matter
Choose a manageable sample: your main service or product pages, an article and examples of other important templates. Include pages that should remain publicly accessible but stay out of search results.
For each page, record:
- Whether it should appear in search.
- What visitors should see on mobile and desktop.
- Which URL should represent it.
- What action visitors should be able to complete.
Each finding needs an affected URL, expected behaviour, observed evidence, proposed change, owner and acceptance check. “Investigate indexing” is too vague for a development ticket. “Check why this service page contains an unintended noindex rule” gives the team a specific question to answer.
Separate crawl access from indexing controls
For Google, blocking crawling does not reliably exclude a URL from search. Googlebot must access a page to read its noindex rule. A robots.txt block can hide that rule, and the URL may still appear in results through links elsewhere. Google supports noindex in an HTML meta tag or HTTP response header, but not in robots.txt. See Google’s noindex documentation.
Illustrative decision: A publicly accessible campaign page should stay out of Google Search. Use a readable noindex rule and allow the crawl needed to discover it, following Google’s guidance on access and noindex.
Use the robots.txt tester for a supporting rule check. Record crawl access and intended indexing separately in the ticket.
Check the page that is actually delivered
Use URL Inspection to examine the HTML Googlebot received and confirm whether the intended noindex rule is present. This follows Google’s documented noindex debugging process.
Inspect the actual rendered page on mobile and desktop as well. Work through it as a visitor would:
- Read the main heading and body text.
- Open navigation and follow important links.
- Check images, forms and calls to action.
- Compare the visible content with the intended page content.
Record missing content or broken interactions with screenshots and reproduction steps. Separate the observed problem from its suspected cause. If text is missing, investigate where delivery fails before prescribing a framework change or rendering approach.
Make the acceptance check specific: the affected content appears, the relevant interaction works and the indexing rule matches the page’s intended behaviour. “Rendering fixed” leaves too much room for interpretation.
Keep sitemap URLs and modification dates accurate
For Google, list absolute URLs for pages you want in search, choosing the preferred URL where duplicates exist. Keep each sitemap within both limits: 50,000 URLs and 50 MB uncompressed. See Google’s sitemap guidance.
Check how your CMS generates lastmod. Google uses it when consistently and verifiably accurate. It should represent a significant update, such as a change to main content, structured data or links. A copyright-date change does not qualify. Google ignores priority and changefreq. These distinctions appear in Google’s XML sitemap notes.
Compare several sitemap dates with actual page edits. Investigate dates that change whenever the sitemap regenerates, even when those pages have not changed significantly.
Submission is a hint; it does not guarantee Google will download or use the sitemap for crawling. Record submission without treating it as proof of discovery, following Google’s submission guidance.
Validate structured data against visible content
Choose markup that describes visible page content and meets the requirements of the relevant Google Search feature. Google generally recommends JSON-LD, while also supporting Microdata and RDFa. See Google’s structured-data introduction.
Use the schema generator as a drafting aid, then compare every populated field with the page. Leave out invented ratings, unsupported details and information visitors cannot see.
Google recommends the Rich Results Test for validation and URL Inspection to confirm it found the markup. Treat feature eligibility as a condition for possible enhanced display, rather than a promised appearance, following Google’s implementation and validation guidance.
Make the acceptance check about accurate, valid markup on the intended page. Assess later performance separately. Do not attach promises of rankings, clicks or AI citations to the implementation ticket.
Turn findings into a practical fix list
Prioritise by the importance of the affected page, the strength of the evidence and the effort required to resolve the issue.
Illustrative prioritisation: Your main service page has an unintended noindex rule, while an article could receive additional optional markup. Investigate the service-page rule first because it conflicts with the page’s intended search availability. Keep the optional markup in the backlog with separate acceptance criteria.
Close each ticket after checking the changed page against its acceptance criteria. Repeat relevant checks after template, CMS or configuration changes, and record what changed and when. Review search performance separately from technical completion.
For help turning findings into an implementation plan, see technical SEO support. Bring the affected pages, evidence and intended behaviour so the discussion starts with concrete decisions.
Further reading: How to prioritise SEO work after an audit.
