Key takeaways
- Technical SEO in 2026 is still a short list: indexable, one URL, discoverable, fast enough, usable on a phone.
- Fix indexation and canonicals before you chase a score. A green plugin on a noindex page is not the work.
- The list lets a useful page be found. It does not invent the page.
The plugin is green. The page is `noindex`. A person on a phone still cannot finish the form.
That is most 2026 technical SEO theater. A technical SEO checklist is whether a crawler can fetch the URL, whether one URL is the URL, and whether a person can finish the page on a phone before they leave. Indexable. Canonical. Fast. Usable on a phone. A short list you can finish. It does not invent useful content.
A plugin score is not the list. A second HTML written for the crawler is not the list. How to rank your website is the longer order: intent first, technical second, mentions third. Technical health is that second column. It lets a useful page be found. It does not write the page.
Five checks you can finish this month
A page is technically healthy when five things are true:
- The URL is indexable. Not `noindex` by accident. Not blocked. Not locked behind a login or a cookie wall that hides the offer.
- One URL is the URL. Parameters, trailing slashes, and preview hosts do not compete.
- A crawler can discover it. A relevant page links to it. A sitemap lists it, and only lists URLs you want known.
- It is fast enough. The offer arrives before the person leaves. You do not need a perfect score.
- A phone can use it. Readable type, taps that hit, a form that submits.
Remove any one and the others get expensive. A `noindex` essay is a draft. A sitemap of thin URLs is a map of pages that should not exist.
Indexable lets the URL enter the index. It cannot invent a reason to retrieve it. Canonical names the one URL. It cannot merge two different offers into one page. Discoverable points the crawler at URLs you want known. It cannot rank a URL nobody asked for. Fast enough lets the offer arrive. It cannot rescue a page with nothing to say. Usable on a phone lets a thumb finish the job. It cannot substitute for useful unique text.
If a vendor sells a score that skips the first column, they are selling a story. The story fails the first time a person lands and the form does not submit.
Staging leftovers and blocked offers
The most common indexation issues are accidents: a staging `noindex` that shipped, a `robots.txt` that blocks the offer, a cookie wall or login that hides the HTML, a preview host that got indexed, a different page for the crawler than for the person.
Check the URL, not the dashboard:
- View source. Is there a `noindex`? Is there a canonical that points somewhere else?
- Open `/robots.txt`. Are you blocking the HTML you want retrieved?
- Open the page logged out, on a phone, with cookies cleared. Do you see the same offer a crawler would get?
- Confirm the host in Search Console is the host people use.
If the answer is no, stop buying tools. Fix the gate. A crawler that cannot fetch the document cannot store it. That is not a ranking problem. It is an indexation problem. Do not cloak. Do not serve a cleaner company to the bot than the visitor gets.
A green score on a `noindex` page is still a draft. Fix the gate before you argue about speed.
Pick the URL and redirect the rest
One URL is the URL. `https://www.example.com/offer`, `https://example.com/offer/`, and `https://example.com/offer?utm_source=ad` are not three pages. They are one page with three doors. Canonical tags name the preferred door. They do not invent a page, and they do not merge two different offers.
What competes: `www` versus the apex, `http` versus `https`, trailing slash, query parameters that do not change the document, preview and staging hosts, filter URLs that reprint the same offer.
Pick one host. Redirect the rest. Put a self-referencing canonical on the URL you want retrieved. Do not point every interior page at the homepage. If two URLs say different things, they are not duplicates. A canonical is a name, not a rewrite.
Sitemaps that only list pages you will defend
Canonical tags, sitemap, and robots fail as one system. `robots.txt` is a gate. A sitemap is a list. Internal links say this URL matters.
`robots.txt` should allow the HTML you want retrieved. Do not `Disallow: /` and then wonder why nothing indexes. `robots.txt` is not a `noindex`. A blocked URL may still be known if other sites link to it — you just hid the document.
A sitemap lists the URLs you want known, and only those. No drafts, thank-you pages, parameter junk, 404s, or staging hosts. If you would not defend the URL in a meeting, do not list it. Discovery is the precondition, not the ranking.
A relevant page should point at the URL. An orphan that exists only in a sitemap is a rumor. A footer of 200 links is not a relevant page.
The offer has to arrive on a phone
You do not need a perfect score. You need the offer to arrive before the person leaves. Most "speed projects" are image weight, unused scripts, and a third-party tag that was "just for the campaign." Compress images. Serve a size that matches the slot. Cut the script that does not serve the form. Web development that skips this is not done.
Most visits are on a phone. Technical SEO that only checks a wide monitor is half a list. Creating a mobile-friendly website is the longer version: readable type, usable taps, fast images, a form that does not fight the thumb.
A missing title is a retrieval problem. A title that disagrees with the heading is an entity problem. A form that drops mobile submissions teaches analytics a lie. A crawlable page a person cannot finish will not keep the ranking it briefly got.
Metadata that agrees with the page
Titles package retrieval. They should match the body. They should not bait a query the page will not finish.
Schema is the same rule in a different syntax. Honest schema markup is the longer version: describe the page you shipped. Do not invent a LocalBusiness, a review, or an Offer without a price. A title, a heading, a body, and a JSON-LD block that say four different jobs taught the index a contradiction. Align them. Metadata cannot invent authority.
Do not optimize a URL that should not exist
This list cannot replace useful content. A technically perfect URL that restates the homepage is still a thin page. Twenty city URLs for a market you do not serve are still a waste of crawl.
If the homepage is still mush, fix the pages. Do not run a technical SEO checklist on a URL that should not exist. Intent first. Technical second.
SEO and content is the ongoing version of useful unique pages. Web development is how those pages get a site that can hold them. Neither is a ranking product.
If you wanted a list you can finish this month, this is it:
1. Confirm the URL is not `noindex`, not blocked, not behind a wall that hides the offer. 2. Confirm one URL is the URL. Redirect the doors that compete. Canonicalize the one you want retrieved. 3. Confirm a relevant page links to it. Confirm the sitemap lists it, and only lists URLs you will defend. 4. Confirm a phone can read it, tap it, and submit the form before the person leaves. 5. Confirm the title matches the heading and the body. Confirm the schema matches the page. 6. Stop. Do not buy a score. Do not write a second page for the crawler.
Do this yourself when you can write the offer, open the source, fix `robots.txt`, and refuse to cloak. Skip it when the homepage is still a slogan.
CLICK.BLUE has shipped crawlable sites since 2014 — twelve-plus years, fifty-plus businesses, a hundred-plus websites. Crawl checks and honest titles are byproducts of pages we will stand behind. They are not a ranking for sale.
If you already know the offer and need the site to say it — and to stay crawlable after launch — that is a full website and the SEO that follows. Start from the current URLs. A score will not rank you. Honest public pages might be found.