1. Record the starting position

List your priority services or product ranges and the pages intended to support them. Record the review date, recent website changes and any available search or enquiry data. Compare equivalent periods where possible, noting seasonal demand and changes in stock or availability.

Keep a simple findings table with the page, observation, supporting evidence, proposed action and owner. An automated score can prompt an investigation, but it is not the finding itself.

  • Identify important landing pages and contact destinations.
  • Record which data sources are available and which are missing.
  • Save a dated baseline before making changes.

2. Check access and page identity

Visit representative pages and inspect whether each returns the expected content and response. Check internal links, indexing instructions, canonical signals and sitemap entries for contradictions. Use Search Console inspection where you have access, distinguishing a live test from evidence of indexing.

Do not remove crawl rules or noindex instructions in bulk. Some pages are deliberately excluded, and staging environments may contain unpublished material. Establish the purpose of a restriction before proposing a change.

3. Review the decision and the next step

Read a priority page as a potential customer. Is the offer specific? Are coverage, suitability and exclusions clear? Does the title describe the page? Can the visitor find a relevant next step without guessing which service or product is intended?

Then test the journey on a mobile and with a keyboard. Look for unreadable text, unstable layouts and broken interactions. With permission, test delivery to the intended destination; opening an email application alone does not prove receipt.

4. Turn observations into a short work list

Prioritise by consequence, confidence and effort. An unavailable service page or incorrect contact destination usually needs attention before a minor wording preference. Give each task an acceptance check, such as confirming that an old URL reaches its intended replacement without an unnecessary chain.

After release, repeat the relevant checks and record the change date. Review search and enquiry evidence later over suitable periods. A technical fix can be verified promptly; its commercial effect may remain uncertain or need more data.

Common questions

Can a free audit tool finish this checklist?

It can surface useful signals, but it cannot reliably confirm your business facts, customer needs or whether an enquiry reached the right person.

Should I delete pages with little traffic?

Not automatically. Check their purpose, links, seasonality and business value first. Low traffic alone does not establish that a page is unnecessary.

What should a developer receive?

A reproducible example, affected URLs or templates, the intended behaviour, relevant constraints and a clear test for completion.