The Technical SEO Checklist for 2026

Technical SEO is the work of making sure search engines can reach your pages, read them correctly, and trust what they find: server responses, redirects, security, mobile rendering, speed, and crawl access. It matters because technical failures are absolute — a page a search engine cannot fetch, or is told not to index, will not rank no matter how good the writing is.

Part 3 of 12 in the HighSEOTools SEO learning path.

The pipeline you are protecting

Part 2 introduced the basic vocabulary: a crawler is the program that downloads your pages, the index is the database of everything it has read, and the SERP is the results page searchers see. Between crawling and ranking sits one more stage worth knowing: rendering, where Google runs your page roughly the way a browser would — executing JavaScript, applying CSS — to see the finished content. The full pipeline is crawl → render → index → rank, and technical SEO owns the first three stages.

That is why professional audits check the technical layer before touching content: a fault here silently caps everything downstream. This checklist is ordered the same way — fatal problems first, enhancements last.

1. Answer every request with the right status code

Every time a browser or crawler asks your server for a URL, the server replies with a status code — a three-digit number that says how the request went. Crawlers take these codes literally, so a wrong code is a wrong instruction:

• 200 OK — the page exists and was served. What every page you want ranking should return.
• 301 Moved Permanently — the page lives at a new address; ranking signals should transfer there.
• 302 Found — a temporary detour; the original URL keeps its signals. Use it only when the move really is temporary.
• 404 Not Found — the page does not exist. Normal for genuinely removed content; harmful when internal links still point at it.
• 410 Gone — deliberately deleted, not coming back. A slightly stronger removal signal than 404.
• 500 / 503 — server errors. If they persist, crawlers slow down, and indexed pages can eventually drop out.

You can read these codes for a list of URLs with the Server Status Checker — it fetches each one and reports the final status, response time, and server. A real run (checked 2026-07-17):

https://www.iana.org/help/example-domains — 200 OK        · 15 ms · server: cloudflare
https://example.com/no-such-page          — 404 Not Found · 13 ms · server: cloudflare

The real page answers 200; the made-up URL correctly answers 404. That second behaviour matters more than it looks. Some sites respond to missing pages with a friendly "not found" screen that still returns 200 — a soft 404. The crawler is told the page exists, keeps it in its queue, and revisits an empty page indefinitely. Missing pages should say so in the status code, not just in the on-screen text.

2. Don't tell search engines to stay away

Two small instructions can remove pages from search entirely, and both are easy to leave switched on by accident.

robots.txt is a plain-text file at yourdomain.com/robots.txt that tells crawlers which paths they may fetch. One careless line — a leftover Disallow: / from a staging site is the classic — blocks the whole domain. The noindex robots meta tag is the second switch: the page can still be crawled, but the crawler is told not to include it in the index. Keep the distinction straight: robots.txt controls crawling, noindex controls indexing.

Checking both takes minutes. Open yourdomain.com/robots.txt in a browser and read it; if a rule looks ambiguous, paste the file's contents into the Robots.txt Tester along with a URL path and a crawler name, and it tells you whether that path is allowed or blocked — and which rule decided it. To inspect a page for noindex (and the rest of its head tags), run it through the Meta Tags Analyzer. Robots.txt has enough depth — wildcards, precedence rules, persistent myths — that it gets the next guide in this path to itself.

The positive half of crawl control is the XML sitemap: a machine-readable list of the URLs you want indexed, usually at /sitemap.xml, which you submit once in Google Search Console. Build one with the XML Sitemap Generator; keeping it honest — only real, indexable, 200-status URLs — is Part 5.

Finally, crawlers discover most pages by following links, so broken internal links are discovery dead ends. The Website Broken Link Checker fetches a page and tests up to its first 30 unique links, flagging each one that no longer resolves.

3. One address per page: redirects, HTTPS, and your canonical domain

A redirect is a server answer that says "the page you want is over there" and forwards visitors and crawlers automatically. Redirects are essential when URLs change, but they follow three rules: use 301 for permanent moves, keep chains short (A→B, never A→B→C→D — every hop costs a request and slows discovery), and never leave two URLs serving the same content without one redirecting to the other.

The most common duplicate-address problem is your own domain. Between http/https and www/non-www, your homepage is potentially reachable at four different addresses. Pick one — your canonical domain — and 301-redirect the other three to it, so links and ranking signals accumulate in one place instead of four.

Real sites get this half-right surprisingly often. We ran the Redirect Checker on http://gnu.org/, and this is the true output (checked 2026-07-17):

301  http://gnu.org/  →  http://www.gnu.org/
200  http://www.gnu.org/

Redirects: 1 · Final status: 200 · Final protocol: HTTP (flagged)

The redirect settles the www question in a single clean hop — good — but it forwards the plain-http request to the http version rather than upgrading it, so the tool flags the final protocol. (The site does serve https; the flag is about what this redirect chain does with an insecure request.) A fully tightened setup sends every variant — http, https, www, bare — to one https address in one hop.

HTTPS is the encrypted version of the web's transfer protocol — the padlock in the address bar — and it is table stakes: browsers mark plain-http pages "not secure", and Google has used HTTPS as a lightweight ranking signal for years. After moving to HTTPS, also fix mixed content: an https page loading images or scripts over plain http, which browsers may block outright.

For duplicate URLs you cannot redirect — tracking parameters, print views, filtered listings — the canonical tag names the preferred address so signals consolidate on it. It appeared in Part 2, and the whole duplicate-content problem gets its own treatment in Part 8.

4. Pass the phone test: mobile-first indexing

Google predominantly crawls and indexes the mobile version of your pages — this is called mobile-first indexing — and it applies even when the searcher is on a desktop. The consequence is blunt: whatever your site shows on a phone is, for ranking purposes, what your site is. Content, structured data, or internal links that exist only in your desktop layout may never be seen at all.

Serve one responsive page

There are three ways to serve mobile pages: responsive design (the same HTML at the same URL, with CSS adapting the layout to the screen), dynamic serving (different HTML by device), and separate mobile URLs (an m. subdomain). Google supports all three but recommends responsive, and for good reason — one set of content, one URL, none of the parity headaches the other two invite.

A responsive layout only works if every page carries the viewport tag — <meta name="viewport" content="width=device-width, initial-scale=1"> — in its head. Without it, phone browsers assume a desktop-width canvas and shrink the whole page to pinch-and-zoom size. Don't set a fixed pixel width, and don't disable user zooming — blocking zoom hurts accessibility.

Design for thumbs

• Tap targets: buttons and links need a touch area of roughly 48 pixels with space between neighbours — fingers are far less precise than cursors.
• Text: body copy around 16px or larger, readable without zooming, with generous line height.
• No horizontal scroll: tables, images, and code blocks must wrap or scroll inside their own container, never push the whole page sideways.
• No intrusive interstitials: a full-screen pop-up covering the content right after someone arrives from search is a negative signal. Easily dismissed banners and legally required notices (cookie consent) are fine — the test is whether visitors can read what they came for without fighting an overlay.

Keep content parity

Because the mobile version is the indexed version, it must carry the same primary content, headings, structured data, meta tags, and images (with alt text) as desktop. Collapsing sections behind accordions or tabs is fine — the content is still in the HTML. Deleting sections to simplify the small screen hands Google a thinner page. If it deserves to rank, it has to be on mobile.

Test it

The Mobile-Friendly Test fetches a URL plus its stylesheets and scores the mobile-readiness signals in the code: viewport tag, responsive CSS rules, fixed-width layouts, heavy embeds, wide tables, and touch controls. Run against https://example.com it returned 78/100, "Needs improvement" (checked 2026-07-17): the viewport tag passes, but the Responsive CSS check fails with "0 media queries, 0 container queries, 0 layout hints". That is a fair verdict worth understanding — example.com is a one-paragraph page that happens to fit any screen, but its code contains none of the responsive machinery a real layout needs, and on a content site that gap would show up as broken phone rendering. Pair the tool with two manual checks on your own pages: Chrome DevTools device emulation at a 375px width, and one pass on an actual phone, scrolling the full page while watching for overflow, unreadable text, and cramped controls.

5. Be fast where it counts: Core Web Vitals

Speed matters twice over: slow pages lose visitors, and slow servers get crawled more cautiously (more on that below). Google measures real-world experience through the Core Web Vitals, three metrics collected from actual Chrome users:

• Largest Contentful Paint (LCP) — how long until the main content is visible. Good: 2.5 seconds or less.
• Interaction to Next Paint (INP) — how quickly the page reacts when tapped or clicked. Good: 200 ms or less.
• Cumulative Layout Shift (CLS) — how much the layout jumps around while loading. Good: 0.1 or less.

Two kinds of data measure them, and knowing the difference saves confusion. Lab data is a single simulated page load on standardized hardware — reproducible, ideal for debugging. Field data is aggregated from real visitors over the previous 28 days (Google's Chrome UX Report, or CrUX) — this is what reflects your actual users, and it only exists for sites with enough traffic. Our Page Speed Test wraps Google's PageSpeed Insights and shows both. Run against https://example.com on the mobile strategy it returned a 100/100 performance score, with real-user field data of LCP 960 ms, INP 81 ms, and CLS 0.00 — every vital comfortably in the good range (checked 2026-07-17). No surprise for a page that is a few kilobytes of HTML, and that is exactly the lesson: page weight is the enemy, and most of it is usually images and scripts.

The reliable quick wins, in order: compress and right-size images before uploading (gauge a page's total weight with the Page Size Checker), defer JavaScript that isn't needed for the first paint, and reserve space for images and ads so the layout doesn't jump as they load. Core Web Vitals get a full walkthrough — including how to read a failing report — in Part 6.

6. Crawl budget: real, but probably not your problem

Crawl budget is the number of URLs a search engine will fetch from your site in a given period. It isn't a dial you can turn; it emerges from two factors. The crawl rate limit is politeness: crawlers watch how quickly your server responds and back off when it slows down or returns errors. Crawl demand is interest: URLs that attract links and traffic, or change often, get revisited more; URLs the crawler considers stale or unimportant get visited less. Your effective budget is what the crawler can fetch, filtered by what it wants to fetch.

Here is the honest part much SEO advice skips: if your site has a few hundred or even a few thousand pages, crawl budget is almost certainly not your problem. Google has said plainly that most site owners don't need to think about it, and that on well-maintained sites new pages tend to be crawled quickly. If pages on a small site aren't getting indexed, the cause is nearly always something earlier in this checklist — an accidental noindex, a robots.txt block, thin or duplicate content — not a crawler running out of appetite.

Crawl budget becomes a genuine constraint in three situations: very large sites (tens of thousands of URLs and up), sites whose filters or search boxes generate endless URL variations (e-commerce faceted navigation — filter and sort combinations, each with its own URL — is the classic), and fast-changing sites like news publishers that depend on rapid recrawling. If none of those describes you, skip ahead. If one does, the waste usually isn't "too many good pages" — it's crawlers burning visits on URLs that should never have been fetched:

• Duplicate URLs — the same content behind tracking parameters, session IDs, or inconsistent trailing slashes.
• Faceted navigation — filter combinations spawning a near-infinite URL set from one category page.
• Infinite spaces — calendars with endless next-month links, bottomless paginated archives.
• Soft 404s — empty pages answering 200, so the crawler keeps coming back (section 1).
• Redirect chains — every hop is another spent request.
• Thin auto-generated pages — near-empty tag archives, stub profiles.

The fixes are the levers this checklist already covers, aimed deliberately: block never-crawl patterns (internal search results, parameter combinations) in robots.txt; consolidate duplicates with canonicals and redirects; keep the sitemap limited to canonical, indexable, 200-status URLs; repair broken internal links; speed up server responses, which raises the rate limit; and prune or noindex pages that earn nothing. The goal is never less crawling — it's moving crawls away from waste and toward pages that can actually rank. Google Search Console's Crawl stats report shows whether the change is landing.

7. The enhancement layer: structured data and hreflang

Structured data is a machine-readable summary of a page — usually a small JSON-LD script in the head — that states what the page is (an article, a product, a review) in the standard Schema.org vocabulary. It helps engines understand content and can make pages eligible for rich results: enhanced listings with ratings, prices, or breadcrumbs. Two honest caveats: Google alone decides when rich results appear, so eligibility is never a guarantee, and FAQ rich results are now shown only for a small set of well-known government and health sites. Build valid markup with the Schema Markup Generator; Part 7 covers the types worth adding.

If you serve more than one language or region, hreflang tags tell engines which version belongs to which audience, so the German searcher lands on the German page. Generate a correct tag set with the Hreflang Generator. Single-language, single-region sites can skip this entirely.

Fix in this order

You'll rarely fix everything at once, so work in order of impact:

1. Indexability first. A page blocked in robots.txt, set to noindex, or returning the wrong status code cannot rank at all — treat these as emergencies.
2. Addresses second. One canonical https domain, single-hop 301s, no chains, no broken internal links.
3. Experience third. Mobile rendering and Core Web Vitals — they shape both rankings and whether visitors stay.
4. Enhancements last. Crawl-budget hygiene (if your site is big enough to need it), structured data, hreflang.

Re-test after every change rather than shipping ten fixes blind — one misplaced directive can quietly undo the rest. For a fast automated pass over any single URL, the Website SEO Score Checker fetches the page and runs pass/warn/fail checks across metadata, content, technical, and social signals, which makes it easy to confirm a fix actually landed.

The checklist, in one place

• Pages you want ranking return 200; removed pages return 404 or 410 — no soft 404s.
• No accidental robots.txt blocks; no leftover noindex tags.
• XML sitemap submitted, listing only real, indexable, 200-status URLs.
• No broken internal links.
• One canonical domain: https, one hostname, every variant 301-redirected in a single hop.
• Viewport tag on every page; layout responsive; tap targets and text sized for thumbs.
• Mobile content matches desktop content — parity, not a stripped-down version.
• No intrusive interstitials.
• Core Web Vitals in the good range, on field data where your traffic provides it.
• Large or faceted sites only: crawl waste blocked, duplicates consolidated, thin pages pruned.
• Structured data valid; hreflang present where multiple languages exist.

Technical SEO isn't a one-time project — re-run this list after any redesign, migration, or platform change, because those are exactly the moments stray directives sneak in.

Next: robots.txt without the myths

The most powerful — and most dangerous — file in this checklist is robots.txt: one line can hide a mess from crawlers, and one wrong line can hide your whole site. Next we take it apart properly: the syntax, the precedence rules, what it can and cannot do, and the mistakes that actually take sites out of search. Continue with Part 4: the robots.txt guide.