Technical SEO Checklist | WebManics

If you want more organic traffic, technical SEO is the bit you can’t ignore. It’s the work that makes your site easy for Google to crawl, understand, and trust, so your content actually has a chance to rank.

This guide focuses on the technical levers that move the needle: crawlability, indexing, site speed, and Core Web Vitals, plus a practical checklist you can run through without turning it into a six-month project.

What is technical SEO?

Technical SEO is the work that improves how search engines crawl, render, understand, and index your website. It’s the foundation underneath content and links. If the foundation is weak, everything else underperforms.

In practical terms, technical SEO includes:

• Site architecture and internal linking
• Page performance (speed, stability, responsiveness)
• Mobile usability
• HTTPS and security basics
• Indexation controls (robots.txt, noindex, canonicals)
• Structured data (where it genuinely helps)

Google’s starter guide is a good baseline. (Google SEO Starter Guide)

Quick definitions (so we mean the same thing)

• robots.txt is a file that tells crawlers what they are allowed to access. If it blocks key paths or resources, Google may not crawl or render your pages properly.
• A canonical tag tells Google which URL is the preferred version of a page when duplicates exist (for example, tracking parameters or printer-friendly variants).
• CrUX (Chrome User Experience Report) is Google’s aggregated real-user performance dataset. It powers field (real-world) Core Web Vitals where enough traffic exists.
• RUM (Real User Monitoring) is your own measurement of real-user performance, usually via a script that records timings and interaction latency.
• Render-blocking JavaScript is script that delays visible content or user interactivity while the browser downloads and executes it.

Why technical SEO matters (for rankings and revenue)

Search engines favour sites that are:

• Easy to crawl (clean internal links, minimal errors)
• Easy to understand (consistent structure, clear templates)
• Fast and usable (good page experience signals)

But there’s a second reason it matters: users don’t tolerate slow, broken sites. Technical fixes that improve crawlability and speed often improve conversion at the same time. That’s why technical SEO is one of the few areas where “SEO work” can pay back twice.

Crawling vs indexing (and why people mix them up)

These two get confused constantly, so here’s the clean split:

Crawling is when Googlebot discovers and fetches your pages by following links and sitemaps.

Indexing is when Google decides a page is good enough to store and show in search results.

A page can be crawled but not indexed. And if it isn’t indexed, it won’t rank.

Indexing and crawlability triage table

Make your site easier to crawl

1) Build a clear site hierarchy

A good structure helps Google find pages quickly and understand how they relate.

A practical rule: important pages should be reachable in a few clicks from your homepage. If you have pages that only exist in the XML sitemap (and nowhere in internal navigation), they’re easy to miss and often underperform.

Things that usually break crawlability:

• Orphan pages (no internal links)
• Bloated navigation (hundreds of near-identical links)
• Faceted URLs generating infinite combinations
• Broken internal links and redirect chains

2) Submit an XML sitemap (and keep it clean)

A sitemap is not magic, but it helps Google prioritise discovery—especially on larger sites.

Common URLs:

• yoursite.com/sitemap.xml
• yoursite.com/sitemap_index.xml

Submit it in Google Search Console. (About Search Console)

Keep it clean:

• Include only canonical, indexable URLs
• Exclude parameter-driven duplicates
• Remove 404s, redirected URLs, and “noindex” pages

3) Fix broken links (and stop creating new ones)

Broken links waste crawl budget and frustrate users.

When you audit:

• Internal links: update the destination, or add a 301 redirect if the old URL is still referenced. (What is a 301 redirect?)
• External links: replace with a working source, or remove if it’s no longer relevant

Then prevent recurrence:

• Use relative links where appropriate (easier to refactor)
• Avoid hardcoding legacy URLs into templates
• Run automated link checks (monthly is enough for most sites)

Improve site speed (without guesswork)

Speed is a mix of:

• Server response time (hosting, caching)
• Front-end weight (images, scripts, CSS)
• Rendering and interactivity (JavaScript, layout shifts)

Tools that are worth using

• Google PageSpeed Insights (quick signal + recommendations)
• Lighthouse (local testing and repeatability)
• WebPageTest (deep diagnostics, waterfalls, real-world locations)
• GTmetrix (useful reporting, especially for comparisons)

Important: treat lab tools as directional. The rankings-impacting metrics are based on real user data (where available), not a single synthetic run.

A quick note on PageSpeed Insights (PSI)

PSI is useful, but it’s easy to misread.

• PSI blends lab data (Lighthouse) with field data (CrUX) where available—so a “score” can move even when real users see no difference.
• Lighthouse runs with simulated throttling, which can overstate issues for audiences mostly on fast 4G/5G.
• The most useful output is usually the Opportunities/Diagnostics list—treat it as a prioritised backlog, not a pass/fail.

Core Web Vitals (what they are, and how to use them)

Core Web Vitals are Google’s page experience metrics. They’re not the whole story—but they’re measurable, and they’re a decent proxy for “is this page annoying to use?”

Key metrics:

• Largest Contentful Paint (LCP): loading speed (target: under 2.5s). (LCP explained)
• Interaction to Next Paint (INP): responsiveness to user input. (INP explained)
• Cumulative Layout Shift (CLS): visual stability (target: under 0.1). (CLS explained)

Core Web Vitals triage table (what to fix first)

If you’re improving performance, use this loop:

1. Measure (identify worst templates and top-traffic pages)
2. Fix (prioritise the biggest, simplest wins)
3. Verify (confirm improvements in the same tooling)
4. Repeat (performance regressions happen)

Do Core Web Vitals still matter for SEO?

Yes, but they’re rarely the main reason a page ranks or doesn’t rank.

The practical way to think about it:

• If you’re failing badly (especially on mobile), fix it. CWV issues often correlate with real UX problems and conversion drops.
• If you’re “nearly passing”, don’t sink weeks into chasing perfect scores. Put that time into content quality, internal linking, and indexation hygiene.
• If traffic dropped and CWV is the only obvious change, confirm whether the templates that matter (blog posts, product/service pages) are failing, not just the homepage.

Why does Search Console show “bad INP” when Lighthouse looks fine?

This is one of the most common real-world CWV problems right now.

In plain English: Search Console is based on field data (real user sessions), while Lighthouse is synthetic. It’s normal for them to disagree.

If GSC flags INP but you can’t reproduce it in Lighthouse:

1. Start with field data (CrUX, Search Console groups, or RUM) to find which page templates are failing
2. Look for “interaction-heavy” components: cookie banners, menus, filters, forms, chat widgets, sliders
3. On WordPress in particular, audit plugins and third-party scripts. They’re a common INP culprit
4. Fix one interaction at a time, then re-validate in GSC (don’t ship ten changes and guess)

Practical speed wins (most sites)

Non-technical (still high impact):

• Compress images and use modern formats (WebP/AVIF)
• Remove or reduce third-party scripts
• Limit web fonts and weights
• Avoid heavy iframes where possible

Technical:

• Cache static assets properly
• Minify CSS/JS and remove unused CSS
• Defer non-critical JavaScript
• Use lazy loading for below-the-fold media
• Use a CDN if you have international traffic

Make sure Google can index what matters

1) Be careful with noindex

noindex is useful—but it’s also one of the fastest ways to accidentally remove revenue pages from search.

Common places it belongs:

• Thank you pages
• Cart / checkout
• Internal search results
• Login/account pages

Common places it does not belong:

• Service pages
• Category pages
• Product pages
• Landing pages you expect to rank

2) Use canonical tags to control duplicates

If you have multiple URLs that show the same (or nearly the same) content, canonicals tell Google which one is the “main” version.

Canonical guidance from Google. (Consolidate duplicate URLs)

3) Make HTTPS non-negotiable

HTTPS is table stakes for trust and security, and it’s been a lightweight ranking signal for years. (HTTPS as a ranking signal)

If your site still has mixed content warnings or legacy HTTP pages, fix it. It’s not “advanced”—it’s basic hygiene.

Technical SEO checklist (quick audit)

Step-by-step audit workflow (what to do first, second, third)

1. Confirm indexation for your top pages
   • Use GSC Pages report + URL inspection on your top 10 pages by business value
   • Fix noindex, canonical conflicts, redirect chains, and soft 404s first
2. Confirm crawl paths
   • Make sure top pages are internally linked from relevant hubs
   • Find and fix orphan pages
   • Validate robots.txt is not blocking important resources
3. Validate performance on key templates
   • Check blog posts, product/service templates, and category pages, not just the homepage
   • Prioritise LCP/INP fixes where real users are failing on mobile
4. Clean up duplication and thin pages
   • Merge near duplicates
   • Deindex pages that should not rank
5. Add structured data where it helps
   • Use it for clarity (FAQ, HowTo, Product), not as decoration

Key takeaways

Technical SEO is how you make your site easy to crawl, index, and trust and it often improves conversion at the same time. Start with crawlability and indexation (the “can Google even see this?” layer), then move to performance and Core Web Vitals. Audit, fix, verify, repeat.