Content and links get most of the attention in SEO, but neither can perform if search engines struggle to access your pages. A short technical review before any campaign protects the investment that follows. This is the checklist we use as a starting point.
1. Can search engines crawl the site?
Crawling is how search engines discover pages. Start with your robots.txt file at the root of your domain and make sure it is not blocking important sections. A single misplaced Disallow: / left over from a staging environment can block an entire site.
Remember that robots.txt controls crawling, not indexing. A blocked URL can still appear in search results if other pages link to it. If you want a page kept out of results, it needs a noindex directive — and it must remain crawlable so that search engines can see that directive.
Then check internal links. Important pages should be reachable through normal HTML links, not only through search boxes, scripts or forms.
2. Are the right pages indexable?
Google Search Console's page indexing report shows which URLs are indexed and why others are excluded. Look for:
- Important pages marked with
noindexby mistake - Pages reported as "Crawled – currently not indexed", which can point to thin or duplicate content
- Server errors and soft 404s
- Redirect chains that slow discovery
Use the URL Inspection tool to check individual priority pages and see how Google renders them.
3. Is your XML sitemap accurate?
An XML sitemap helps search engines find the URLs you care about. It should list canonical, indexable pages that return a 200 status — not redirects, error pages or URLs marked noindex. A single sitemap file can contain up to 50,000 URLs; larger sites should use a sitemap index. Submit the sitemap in Search Console and reference it in robots.txt.
4. Are canonical tags consistent?
Canonical tags tell search engines which version of a page you prefer when similar versions exist, such as URLs with tracking parameters. Each indexable page should usually reference itself. Watch for canonicals pointing to redirected or non-indexable URLs, and remember that canonicals are a strong hint rather than a command.
5. Is everything served over HTTPS?
Every page should load over HTTPS, and the HTTP versions should redirect permanently (301) to their HTTPS equivalents. Check for mixed content — images or scripts still loaded over HTTP — which can trigger browser warnings.
6. How do Core Web Vitals look?
Core Web Vitals measure real-user experience. Google's current thresholds for a "good" experience are:
- Largest Contentful Paint (LCP): 2.5 seconds or less
- Interaction to Next Paint (INP): 200 milliseconds or less
- Cumulative Layout Shift (CLS): 0.1 or less
Field data from real users, available in Search Console and PageSpeed Insights when enough data exists, matters more than a single lab test. Large unoptimised images, render-blocking scripts and content that shifts as ads or fonts load are frequent causes of poor scores.
7. Is structured data valid?
Structured data helps search engines understand entities such as organisations, articles, products and breadcrumbs. Validate it with Google's Rich Results Test and make sure it describes content that is visible on the page. Marking up content that users cannot see is against Google's guidelines.
8. Do mobile pages contain the same content?
Google predominantly uses the mobile version of a page for indexing. Check that important text, links, images and structured data are present on mobile, not only on desktop.
What to do with the findings
Not every issue deserves immediate attention. Prioritise by impact and scale: an indexing problem affecting a whole template matters more than a missing alt attribute on one image. Document each fix with clear acceptance criteria so developers know when it is done — then verify it after release.
A technical review will not guarantee better rankings on its own, but it removes the obstacles that would otherwise limit every other improvement.