Technical SEO Checklist: Fix the Foundations First

A technical SEO checklist is a structured audit of the infrastructure that determines whether search engines can find, crawl, and index your site correctly. It covers crawlability, indexation, site speed, structured data, mobile usability, and internal architecture. Get these foundations wrong and everything else, content, links, on-page optimisation, works against a ceiling you cannot see.

Most sites have more technical debt than their owners realise. The issues are rarely dramatic. They are quiet, compounding, and expensive to ignore.

Why Technical SEO Gets Deprioritised (and Why That Is a Mistake)

I have sat in enough quarterly planning sessions to know how technical SEO gets treated. It goes on the roadmap. It stays on the roadmap. It gets bumped when the content team needs developer resource for a campaign landing page. Six months later, someone wonders why organic traffic has plateaued.

The problem is that technical SEO does not produce the kind of visible output that gets celebrated in marketing reviews. You cannot show a Gantt chart of a fixed crawl budget the way you can show a content calendar. But the compounding effect of unresolved technical issues is real. Duplicate content splits link equity. Slow pages increase bounce rates. Broken internal links orphan pages that should be ranking.

When I was scaling the performance marketing operation at iProspect, one of the first things I learned was that the channel work, paid search, SEO, affiliates, could only perform as well as the site infrastructure allowed. We could drive qualified traffic but if the landing page took six seconds to load on mobile, we were pouring money into a leaky bucket. Technical SEO is not a separate workstream from commercial performance. It is the floor everything else stands on.

If you want to understand how technical SEO fits into a broader organic strategy, the Complete SEO Strategy hub covers the full picture from positioning through to measurement.

Crawlability: Can Google Actually Get to Your Pages?

Before anything else, you need to confirm that search engines can reach the pages you want indexed. This sounds obvious. It is surprisingly often broken.

Start with your robots.txt file. It should block crawlers from low-value areas like admin panels, staging environments, and internal search results pages, but it must not accidentally block CSS, JavaScript, or key content directories. A misconfigured robots.txt is one of the most common causes of sudden ranking drops, and it is also one of the most embarrassing to explain to a client.

Next, check your XML sitemap. It should list only canonicalised, indexable URLs. If your sitemap contains noindex pages, redirects, or URLs that return 4xx errors, you are sending mixed signals to Googlebot. Tools like the one in SEMrush’s technical SEO audit guide can surface these issues quickly at scale.

Crawl budget is a concept that gets glossed over on smaller sites but becomes critical as a site grows. Google allocates a finite amount of crawl capacity to each domain. If a significant portion of that capacity is being consumed by paginated archive pages, faceted navigation URLs, or session ID parameters, your core product and content pages get crawled less often. For e-commerce sites with thousands of SKUs, this is not theoretical. It is a real constraint on how quickly new or updated pages enter the index.

Practical steps for crawlability:

• Audit robots.txt and confirm it is not blocking critical resources
• Submit a clean XML sitemap via Google Search Console
• Use URL parameters settings in Search Console to manage faceted navigation
• Run a full crawl with Screaming Frog or a comparable tool and filter by status code
• Check for orphaned pages with no internal links pointing to them

Indexation: Are the Right Pages in Google’s Index?

Crawlability and indexation are not the same thing. Google can crawl a page and choose not to index it. It can also index pages you never intended to be public.

The quickest way to get a read on your indexation health is to use the Coverage report in Google Search Console. Look at the ratio of indexed to submitted URLs. Then look at the reasons Google is excluding pages. “Crawled but not indexed” is worth investigating. It often means the page has thin content, is too similar to other pages on the site, or lacks sufficient internal link authority to be considered worth indexing.

Noindex tags are powerful and easy to misuse. I have seen staging environments accidentally pushed to production with noindex tags on every page. I have also seen the reverse: a developer removes a noindex tag from a site section that was intentionally blocked, and suddenly hundreds of low-quality pages are competing with your main content for the same queries.

Canonical tags deserve their own section because they are frequently implemented incorrectly. A canonical tag tells Google which version of a URL is the authoritative one. The most common mistakes are self-referencing canonicals pointing to the wrong URL, canonicals on paginated pages that incorrectly point to page one, and cross-domain canonicals used without understanding the implications for link equity. When I run audits, I check canonical tags on a sample of at least 50 URLs across different page types. The errors are rarely uniform, which is what makes them hard to catch without systematic checking.

Key indexation checks:

• Review the Coverage report in Google Search Console weekly, not monthly
• Confirm noindex tags are only on pages you genuinely want excluded
• Audit canonical tags across product, category, blog, and tag page templates
• Use site:yourdomain.com in Google to spot unexpected indexed pages
• Check that hreflang tags on international sites are reciprocal and correctly implemented

Site Speed and Core Web Vitals: The Performance Floor

Google made Core Web Vitals a ranking factor because page experience matters commercially, not just technically. A slow page loses users before they convert. That is true whether or not you care about SEO.

The three metrics to focus on are Largest Contentful Paint (LCP), Interaction to Next Paint (INP, which replaced First Input Delay in 2024), and Cumulative Layout Shift (CLS). LCP measures how quickly the main content loads. INP measures responsiveness to user interaction. CLS measures visual stability, whether elements jump around as the page loads.

LCP is the one most sites struggle with. The most common causes are unoptimised hero images, render-blocking JavaScript, slow server response times, and no lazy loading strategy. For a client in the travel sector I worked with, reducing LCP from 4.8 seconds to 2.1 seconds on mobile had a measurable impact on both organic rankings and conversion rate within eight weeks. The two outcomes are not coincidental. They share the same root cause.

CLS is particularly insidious because it often looks fine on a fast desktop connection and falls apart on a slower mobile connection where resources load in a different order. Always test on real devices, not just emulated mobile in Chrome DevTools.

The Optimizely SEO checklist covers performance benchmarks worth comparing against. For deeper diagnostics, PageSpeed Insights and Chrome User Experience Report data are your primary sources.

Speed optimisation priorities:

• Compress and serve images in next-gen formats (WebP, AVIF)
• Implement lazy loading for below-the-fold images
• Minimise render-blocking JavaScript and defer non-critical scripts
• Use a CDN for static assets
• Audit third-party scripts. Tag managers, chat widgets, and ad pixels add up
• Set explicit width and height attributes on images to prevent layout shift

Mobile Usability: Not Just a Checkbox

Google uses mobile-first indexing for all sites now. The mobile version of your site is what Google crawls and evaluates. If your desktop experience is polished but your mobile experience is a compromise, you are being evaluated on the compromise.

Mobile usability errors in Search Console are worth taking seriously. Common issues include clickable elements that are too close together, text that is too small to read without zooming, and content that is wider than the screen. These are not cosmetic issues. They affect how Google scores the page experience and how users actually behave on the page.

Beyond the technical errors, check that your mobile pages are not hiding content behind tabs or accordions that are not rendered in the DOM. If Google cannot see the content, it cannot index it. This is a pattern that comes up frequently on sites that have been built to prioritise visual design over crawlability.

Site Architecture and Internal Linking: The Underrated Lever

Internal linking is the area where I see the biggest gap between what sites do and what they could do. Most sites have an internal linking structure that evolved organically rather than one that was designed to distribute authority and signal topical relevance.

The principle is straightforward. Pages that receive more internal links from high-authority pages are treated as more important. If your most commercially valuable pages are buried three or four clicks from the homepage with minimal internal links pointing to them, you are working against yourself.

When I was working on a large e-commerce account with hundreds of product categories, we ran a crawl and found that some of the highest-margin category pages were only reachable via the site’s XML sitemap, not through any navigational or editorial links. Fixing that, by adding contextual links from relevant blog content and cross-linking between related categories, produced meaningful ranking improvements within a standard crawl cycle. No new content. No new links. Just better architecture.

Architecture checks to run:

• Map click depth from homepage to key commercial pages. Aim for three clicks or fewer
• Identify orphaned pages with no internal links using a crawl tool
• Review anchor text on internal links. Descriptive anchor text carries more signal than “click here”
• Check for redirect chains. A link pointing to a URL that redirects twice before reaching the destination loses link equity at each hop
• Ensure your breadcrumb structure is consistent and uses structured data

Structured Data: Helping Google Understand What You Have

Structured data does not directly improve rankings in most cases, but it enables rich results in the SERP and helps Google understand the content and context of your pages. For certain content types, that distinction matters commercially.

FAQ schema, product schema, review schema, article schema, and breadcrumb schema are the most commonly implemented types. Each has specific requirements that Google enforces. Implementing structured data incorrectly is worse than not implementing it at all, because it can trigger manual actions for misleading markup.

Use Google’s Rich Results Test to validate your markup before deployment. Check the Enhancements section in Search Console after deployment to catch errors at scale. I have seen sites implement review schema on pages where the reviews were not visible to users, which is a violation of Google’s guidelines and a fast route to losing the rich result.

The structured data types worth prioritising depend on your site type. E-commerce sites should focus on product and review schema. Publishers should focus on article and breadcrumb schema. Local businesses should prioritise LocalBusiness schema. Do not implement every schema type speculatively. Implement what is relevant and implement it correctly.

HTTPS, Security, and Technical Trust Signals

HTTPS has been a confirmed ranking signal since 2014. If your site is still serving pages over HTTP, or if you have a mixed content issue where HTTPS pages load HTTP resources, you have a problem that predates most of the other items on this list.

Mixed content is the more common issue on established sites. A page served over HTTPS that loads an image, script, or stylesheet over HTTP will trigger browser security warnings and may cause resources to fail to load entirely. Run a crawl and filter for mixed content URLs. Fix them at the source rather than patching with Content Security Policy headers.

Check your SSL certificate expiry date and set a calendar reminder well in advance. An expired certificate takes your site offline from a user trust perspective and can cause significant ranking drops if it persists. This is the kind of technical failure that feels embarrassing to explain to a board, and rightly so, because it is entirely preventable.

Redirect Management: Where Good Intentions Create New Problems

Redirects are necessary. Redirect chains and loops are not. Every additional hop in a redirect chain adds latency and dilutes link equity. A chain of three or more redirects is a problem worth fixing, not a quirk worth tolerating.

The most common source of redirect chains is site migrations. A URL gets redirected once during a migration. Then the destination URL gets redirected again during a redesign. Then a third time during a replatform. Nobody cleaned up the chain because nobody had a complete record of the original redirects. This is why maintaining a redirect map in a version-controlled document is not bureaucratic overhead. It is operational discipline.

Check for redirect loops, where URL A redirects to URL B which redirects back to URL A. These prevent pages from loading entirely and are usually caused by conflicting rules in .htaccess or server configuration files. They show up clearly in crawl reports as errors.

Always use 301 redirects for permanent moves. Use 302 redirects only for genuinely temporary situations, such as a page under maintenance. Using 302 redirects for permanent changes means Google may not transfer link equity to the destination URL.

Duplicate Content: A More Nuanced Problem Than It Appears

Duplicate content does not automatically result in a penalty. Google is generally capable of identifying the canonical version of a page and consolidating signals accordingly. But “capable of” is not the same as “reliably does.” When you leave duplicate content decisions to Google, you give up control of which version gets ranked and which version accumulates link equity.

The most common sources of duplicate content are: HTTP vs HTTPS versions of the same URL, www vs non-www, trailing slash vs no trailing slash, URL parameters that create multiple versions of the same page, and print-friendly page versions. Each of these can be resolved with canonical tags, redirects, or parameter handling in Search Console.

Near-duplicate content, pages that are substantially similar but not identical, is a subtler problem. Thin product pages that share the same boilerplate description, location pages that differ only by city name, and tag pages that surface the same posts as category pages are all examples. The solution is not always to noindex or delete. Sometimes it is to add genuinely differentiated content. Sometimes consolidation is the right answer. The decision depends on the commercial value of the pages and the search demand they are targeting.

For a full picture of how technical SEO connects to content strategy, on-page signals, and link building, the Complete SEO Strategy hub brings those threads together in one place.

How to Prioritise a Technical SEO Audit Without Losing Momentum

The output of a thorough technical audit is usually a long list of issues. The mistake most teams make is treating all issues as equal. They are not. Some issues affect every page on the site. Some affect one page type. Some are critical blockers. Some are marginal improvements.

I use a simple prioritisation framework: impact multiplied by effort, adjusted for risk. A fix that improves crawlability across 10,000 pages is higher priority than a fix that improves structured data on 50 pages, even if the structured data fix is technically easier. A fix that requires a full deployment cycle from the development team needs to be batched and scheduled differently from a fix that can be made in the CMS in an afternoon.

The SEMrush technical SEO audit framework is a useful reference for categorising issues by severity. The categories, errors, warnings, and notices, give you a starting point for triage even if your final prioritisation takes commercial context into account that an automated tool cannot.

One thing I have learned from running audits across dozens of sites: the most valuable part of the process is not the list of issues. It is the conversation about which issues are worth fixing first given the resources available. A 200-item audit report that sits in a shared drive is worth less than a 20-item prioritised fix list that gets actioned within a sprint cycle.

For reference on broader SEO audit approaches across channels, the SEMrush off-page SEO checklist is worth reviewing alongside your technical work, because off-page signals interact with technical health in ways that are easy to overlook when auditing in silos.

The Ongoing Maintenance Reality

Technical SEO is not a project with a completion date. Sites change. CMS updates introduce new issues. Developers make changes that affect crawlability without realising it. Content teams create new page types that need schema. Redirects accumulate. Performance degrades as third-party scripts multiply.

The discipline is in the monitoring cadence. Set up automated alerts in Search Console for coverage errors, manual actions, and security issues. Run a full crawl monthly on large sites, quarterly on smaller ones. Review Core Web Vitals data in the Search Console Performance report after every significant site change. Treat technical SEO the way you treat financial reporting: not as a one-time exercise but as an ongoing accountability mechanism.

The teams that maintain technical SEO health consistently are the ones that do not need to explain unexpected ranking drops to their stakeholders. Prevention is cheaper than recovery, in SEO as in most things.

About the Author

Keith Lacy is a marketing strategist and former agency CEO with 20+ years of experience across agency leadership, performance marketing, and commercial strategy. He writes The Marketing Juice to cut through the noise and share what works.

Frequently Asked Questions