Check responses before polishing metadata
Start with your homepage, main services, location pages and contact page. A page returning an error cannot be repaired by rewriting its title. Confirm the final address after redirects and note whether the response is successful. If an old service URL is gone, decide whether there is a genuinely equivalent replacement. A redirect to an unrelated homepage can confuse visitors and is not a universal remedy for retired content.
- Inspect the final URL and observed response.
- Fix customer-facing errors before minor wording issues.
- Retest links that point to any changed URL.
Review discovery and crawl access
Important pages should be reachable through useful internal links. Review robots.txt, sitemap availability and obvious access restrictions as separate signals. A sitemap can help discovery, but it does not promise indexing. A robots.txt restriction can prevent a crawler from reading a page without reliably keeping its address out of search results. If a page should be private, use appropriate access controls instead of treating robots.txt as a security feature.
Inspect page information and consistency
Review the source title, description and heading structure for each important page. The title should identify that page's service or purpose; the description should describe what a visitor can actually find. Check for conflicting declarations and canonical signals that point to the wrong destination. Missing structured data is not automatically a failure. If structured data exists, start with valid syntax and truthful, visible content before considering a particular search feature.
- Give distinct service pages descriptive titles.
- Resolve conflicting canonical declarations carefully.
- Use headings to organize the page for readers.
Record links and human checks separately
Check internal destinations, especially navigation, service cards and contact buttons. A public source audit can verify many link targets, but it does not reproduce every JavaScript interaction. Add manual checks for opening the mobile menu, completing a form and finding your phone number. Browser speed measurements are also separate evidence. They require an actual performance test; a quick server response alone does not establish that the visible page loads quickly.
Turn the checklist into a small repair plan
Run the free ColbySEO report to gather a bounded public sample, then compare its evidence with this checklist. Prioritize blocked customer tasks, repeatable technical failures and important-page clarity. Assign an owner and a way to verify each change. Keep the saved report or PDF as the starting record. After publication, recheck the affected URLs and request a new report where appropriate rather than assuming a code change reached the live website.
Common questions
Does every checklist item contribute to the Technical score?
No. The score uses a defined subset of eligible, conclusive checks. Judgment-based reviews and separate performance evidence can still matter even when they are outside that calculation.
Should I repair every warning before promoting the website?
First resolve issues that prevent visitors reaching important pages or contacting you. Review remaining findings in context; not every warning requires the same urgency or the same remedy.
Can this audit tell me whether Google indexed a page?
The public report cannot confirm Google's indexing decisions. A verified Search Console property and its URL Inspection tools provide separate evidence for that question.