What Is Technical SEO? A 14-Point Checklist for 2026

What Is Technical SEO?

Technical SEO, or technical search engine optimization, is everything that determines whether Google can read, understand and display your website. It's not about text or links, but about load time, mobile display, site structure, indexing and structured data.

Content is what people read, and links are what build trust. Technical SEO ensures that both actually reach Google. A page Google can't read doesn't rank. A slow page loses to a fast page with equally good content.

The same foundation applies to AI search. Google sets no separate technical requirements for AI Overviews and AI Mode beyond what applies to regular search. If Google can read the page, it can also be cited in AI answers.

If you're new to the whole field, you can start with our guide on what SEO is. If you want the full picture including content and links, you'll find it in our 15 SEO tips. Here, we focus only on the technical part.

Why Is Technical SEO Important?

Technical SEO is important because Google must accomplish three things with your page before it can rank it: find it, read it, and trust that it works for visitors. If one of these fails, all other work is wasted.

Google uses Core Web Vitals as a measure of whether a page works. The thresholds are public, according to web.dev: the main content should display within 2.5 seconds, the page should respond to clicks within 200 milliseconds, and the content shouldn't shift more than 0.1 in layout shift. The target applies to 75 percent of visits, measured over the last 28 days.

We see the same with our clients. SEO-Analyse.no, the tool we built ourselves, ran over 1,500 analyses in 2026. Among the most common errors we see, the same ones keep recurring: missing canonical, oversized images, pages not included in the sitemap, and schema data with errors.

Technical SEO Checklist: 14 Points

Go through the points in order. The first ones are about Google and AI services finding the page, the next ones about speed, and the last ones about structure and data. If you don't have access to the code yourself, the checklist can be used as a request for whoever manages the website.

Crawling and Indexing

• Robots.txt: Check that the file doesn't block pages that should appear in Google. One wrong line can hide the entire website. Also never block CSS and JavaScript files, as Google needs them to render the page correctly.
• AI Crawlers: In 2026, websites are visited by a dozen AI crawlers in addition to Google and Bing. Check that robots.txt allows in the ones you want to be cited by, such as OAI-SearchBot, ClaudeBot and PerplexityBot. If you want to block AI training, you can block GPTBot and Google-Extended without losing visibility in Google Search or ChatGPT search.
• XML Sitemap: All pages that should rank must be listed in the sitemap, with the correct last-modified date. Google, Bing and AI bots use the date as a signal of freshness. Submit the sitemap in Google Search Console.
• Canonical: Each page should point to itself as the original. Without this, Google may choose a copy with parameters or a trailing slash.
• Noindex: Only pages that shouldn't rank, such as thank-you pages and internal search, should have noindex. Check that no important pages have been given this by mistake.
• Redirects: Old addresses should go directly to the new one with a single 301, not through a chain. Dead links pointing to your website waste ranking you already have.

Speed and Mobile

• Core Web Vitals: Measure LCP, INP and CLS in PageSpeed Insights, both mobile and desktop. Field data from real visitors counts most, and Google measures it over 28 days. That's why it takes a few weeks before an improvement shows up in Search Console.
• Images: Use WebP or AVIF, set width and height in the code, and lazy-load below-the-fold images so they only load when needed.
• Fonts and Scripts: Self-hosted fonts and as little render-blocking JavaScript as possible. Every external script is a new delay. The content should be in the HTML the server sends, not built by JavaScript afterward. Google runs JavaScript, but most AI crawlers don't.
• Mobile: The page should work at 320 pixels wide without content overflowing the screen. Google indexes the mobile version first.

Structure and Data

• HTTPS and URL Structure: The entire website on https, with a single redirect from http and from www to the address you use. Addresses should be short and readable, containing words people search for, and follow the same pattern across all pages.
• Internal Linking: Each page should have links pointing to it from other pages on the website, with text describing the target. Orphaned pages are rarely found.
• Structured Data: JSON-LD for organization, articles, services and prices, with no errors in validator.schema.org. Google removed the FAQ display in search results in May 2026, but FAQ markup is still valid and is read by Bing and AI services. Incorrect markup can lead to a manual action from Google, while missing markup simply means you miss out on rich results.
• Multilingual: If you have multiple languages, each page should have hreflang pointing to all versions, including itself.

How We Measure on Our Own Website

We rebuilt mementor.no in 2026 and set 100 out of 100 measured in Google PageSpeed as a requirement, not a goal. This means self-hosted fonts, WebP on all images, no scripts before consent, and full page caching so the server responds in under 30 milliseconds.

The field data Google itself collects from Chrome users (Chrome UX Report, August 15 to September 11, 2026) shows that 75 percent of visits get the main content on screen within 0.74 seconds. The threshold is 2.5. The layout shift is 0. For INP, Google doesn't yet provide numbers, because the website has too few measured clicks. When we ran a full technical review in September 2026, all pages in the sitemap (152 at the time of measurement) returned 200, had their own canonical and complete hreflang.

The point isn't the numbers themselves. The point is that it's achievable with common tools and a checklist that's followed every time something changes. If you want to see what we require of a new website, we've written a dedicated guide on SEO-friendly websites.

Free Tools That Find the Errors

You don't need to pay to do a technical SEO analysis. These tools cover most of the checklist above.

• Google Search Console: Shows which pages Google has indexed, which are failing, and Core Web Vitals from real visitors. Free and essential for anyone running a website.
• PageSpeed Insights: Measures speed on one page at a time, with concrete suggestions for what should be fixed.
• SEO-Analyse.no: Our own tool that runs over 30 tests on a page, including canonical, meta, headings and structured data.
• Broken Link Checker: Finds dead links across the entire website, both internal and external.

If you want to go deeper than the technical points, the SEO analysis guide shows how to assess the entire website step by step, including content and competitors.

How Often Should Technical SEO Be Checked?

Technical SEO should be checked with every major change, and at least quarterly. A new plugin, a new theme, or a site migration can break things that worked yesterday.

For us, the checks are built into the publishing process itself. Every time we build the website, automated tests run for links, alt texts, structured data, HTML and sitemap. If one test fails, publishing stops. That's a cheaper habit than discovering the error in Search Console three weeks later.

If you need help getting this in place, technical SEO is always the first phase in our SEO service. We review the page with the same tools Google uses, fix what's holding you back, and measure before and after.

Frequently Asked Questions

Conclusion

Technical SEO isn't the most visible work, but it's what determines whether everything else works. Go through the 14 points, measure with free tools, and repeat with every change. Then you won't waste good content on a page Google can't read.