Technical SEO Checklist (2026): 12 Checks, Tested on a Real Site

Technical SEO is the part of SEO that makes sure search engines can fetch, render, understand and index your pages, and that those pages load well for people. It does not make weak content rank. It removes the obstacles that stop good content from being found. This checklist is organized as an audit: for each item, what to check, how to check it, and what “good” looks like.

To keep it honest, I ran the checklist against this site in October 2026. It found real problems, which I show below, because a checklist that only ever passes is not much use. If you are a developer looking for implementation details and code, read technical SEO for front-end developers, which covers the same items from the code side.

Technical vs On-Page vs Off-Page SEO

The Checklist at a Glance

1. One Canonical Host, Served Over HTTPS

Every variant of your domain (http://, www.) should permanently redirect to one HTTPS version. Google’s page experience self-assessment asks whether pages are served securely, and its canonicalization guidance notes Google generally prefers HTTPS URLs.

curl -sI https://scientyficworld.org/ | grep -i "^HTTP\|^location"
HTTP/1.1 301 Moved Permanently
Location: https://scientyficworld.org/

curl -sI https://www.scientyficworld.org/ | grep -i "^HTTP\|^location"
HTTP/2 301
location: https://scientyficworld.org/

This site: pass. Both variants 301 to the same HTTPS host in one hop, and the server sends an HSTS header.

2. robots.txt

robots.txt manages crawling, not indexing. Google says it is not a way to keep pages out of Google; a blocked URL can still be indexed if linked. Check that it does not block CSS, JavaScript or pages you want ranked, and that it points to your sitemap.

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://scientyficworld.org/sitemap_index.xml

This site: pass. This is the standard WordPress pattern.

3. XML Sitemap

A sitemap should list only canonical, indexable URLs. From Google’s sitemap documentation: up to 50,000 URLs or 50 MB per file, absolute URLs, UTF-8; Google ignores priority and changefreq and uses lastmod only when it is consistently accurate. Submit it in Search Console’s Sitemaps report and check for errors.

This site: needs work. The sitemap index loads and lists post, page and category sitemaps, but the lastmod values were stale: posts I rewrote this month still showed their 2022 or 2025 dates, and the index itself had not changed since June 2026. That points to a cached sitemap rather than wrong data. A stale lastmod is exactly the kind Google learns to ignore, so it is worth fixing by clearing the SEO plugin’s sitemap cache and checking again.

4. Status Codes for Missing Pages

A URL that does not exist should return 404 (or 410 if it is gone for good). Google removes URLs that return 4xx from its index. If a missing page returns 200 with an error message, Search Console reports it as a soft 404. Redirecting every missing URL to the homepage or to a generic error page has the same problem.

curl -sIL https://scientyficworld.org/this-page-does-not-exist-xyz/ | grep -i "^HTTP\|^location"
HTTP/2 301
location: https://scientyficworld.org/404-error/
HTTP/2 200

This site: fail. Missing URLs redirect to a /404-error/ page that returns 200, and that page’s robots meta tag says index. That turns every broken link into a soft 404 and invites Google to index an error page. The fix is to let missing URLs return a real 404 status (most themes show a custom 404 template while still sending 404) and to noindex or remove the separate error page.

5. Redirects

Use permanent server-side redirects (301 or 308) when a URL moves for good and temporary ones (302 or 307) only for short-term moves, following Google’s redirect guidance. Avoid chains: each URL should reach its destination in one hop. After merging or removing content, redirect old URLs to the closest relevant page, not to the homepage.

This site: pass for the cases I tested. A URL without its trailing slash 301s to the slashed version in one hop, and the merged posts redirect to their new homes.

6. Canonical Tags

Every indexable page should carry a self-referencing, absolute rel="canonical". Duplicates (parameters, print versions, sorted listings) should point to the main version. Canonicals are hints, so internal links, sitemaps and redirects must agree with them (canonicalization guide).

This site: pass on the pages I checked, for example <link rel="canonical" href="https://scientyficworld.org/how-google-search-works/" />.

7. Indexing

Search Console’s Page indexing report shows which URLs are indexed and why others are not. Statuses such as “Excluded by noindex tag”, “Page with redirect” and “Alternate page with proper canonical tag” are often intended. Look harder at “Crawled – currently not indexed”, “Discovered – currently not indexed” and “Soft 404”. Use URL Inspection on individual pages, and request indexing after major fixes. Keep pages out of the index with noindex, not robots.txt, and make sure Google can crawl those pages to see it (block indexing).

8. Rendering

If your site relies on JavaScript, confirm that the rendered HTML Google sees, shown in URL Inspection, contains the main content and links. Do not block script or style files in robots.txt. Server-side rendering or prerendering for content pages removes most risk (JavaScript SEO basics).

9. Site Architecture and Internal Links

• Every important page is linked from somewhere with a normal <a href>; orphan pages are hard to discover.
• Important pages sit a few clicks from the homepage, grouped in a logical hierarchy (categories, hubs).
• Link text describes the destination, not “click here”.
• URLs are readable words separated by hyphens. Google says keywords in URLs have little ranking effect, so do not change established URLs just to add them.
• Breadcrumbs help users and can appear in results when marked up.

10. Core Web Vitals

The Core Web Vitals are three field metrics, assessed at the 75th percentile of real visits: Largest Contentful Paint (good ≤ 2.5 s), Interaction to Next Paint (good ≤ 200 ms) and Cumulative Layout Shift (good ≤ 0.1). INP replaced First Input Delay on March 12, 2024, so checklists that still list FID are out of date. First Contentful Paint and Time to First Byte are useful diagnostics, but they are not Core Web Vitals.

Use Search Console’s Core Web Vitals report and PageSpeed Insights for field data from real Chrome users, and Lighthouse for lab diagnosis. Google says its ranking systems use Core Web Vitals but that relevance comes first.

This site: needs work. I ran Lighthouse 13.5 (mobile, simulated throttling, one run from my machine) on one of the rewritten articles:

Lab results under simulated slow mobile conditions are harsher than many real visits, and they are not what Google uses for ranking, so the next step is to compare them with field data in Search Console. But the causes are concrete and fixable: fewer render-blocking scripts and styles, explicit image dimensions, and less JavaScript. The same run scored 100 on Lighthouse’s SEO checks, which shows how little that score says on its own.

11. Mobile

Google uses the mobile version of pages for indexing (mobile-first indexing) and recommends responsive design. Check that mobile pages have the same main content, headings, structured data and metadata as desktop, and avoid intrusive interstitials, which the page experience guidance asks about. Google retired its Mobile-Friendly Test in 2023, so use Lighthouse or Chrome DevTools device mode.

12. Structured Data

Structured data can make pages eligible for rich results; it is not a guarantee and must describe visible content. Google recommends JSON-LD and the Rich Results Test. The old Structured Data Testing Tool mentioned in many checklists has been replaced: Google points to the Rich Results Test, and schema.org hosts a general validator. Monitor the rich result reports in Search Console after deploying.

Why Bother: The Real Benefits

• Your content can actually be found. Pages that cannot be crawled or indexed get no search traffic, however good they are.
• Signals are not wasted. Clean redirects and canonicals concentrate links and signals on one URL instead of splitting them across duplicates.
• Faster, more stable pages. Better Core Web Vitals help users first, and Google’s systems use them.
• Problems surface early. Search Console reports catch broken templates and indexing drops before they become traffic losses.

How Often to Audit

Check Search Console’s indexing and Core Web Vitals reports monthly, and run the full checklist after a redesign, a CMS or plugin change, a domain or URL change, or a large content cleanup. The two failures on this site, stale sitemap dates and soft 404s, are both the kind of thing a plugin setting can introduce without anyone noticing.

Conclusion

Technical SEO comes down to a short list: one HTTPS host, sensible robots.txt, an accurate sitemap, honest status codes, clean redirects and canonicals, renderable content, good architecture, healthy Core Web Vitals, mobile parity and valid structured data. Check each one with the tools above rather than assuming, and expect to find something. When I audited this site, a 100 SEO score sat alongside soft 404s, stale sitemaps and slow mobile pages.

FAQs