Technical SEO Checklist for Business Websites

Technical SEO is the part of search that has nothing to do with writing. It is whether search engines can reach your pages, understand them, and serve them without tripping over something structural.

It is also finite. Unlike content, which is never finished, the technical layer is a defined list you can work through and then maintain. This is that list, with an explanation of why each item matters and what "done" looks like.

The short answer

Technical SEO removes the reasons a page cannot rank. It does not make a page worth ranking — that is content's job. Work through indexability, canonicals, metadata, structure, internal links, images, speed and measurement, then keep them from drifting. Most sites have problems in three or four of these areas, not all of them.

A note on what this can promise

Nobody can guarantee rankings, and it is worth being suspicious of anyone who offers to. Google's own documentation states there is no single page-experience ranking signal, and that Search still aims to show the most relevant content even when the page experience is sub-par. Good scores in any tool do not guarantee a position.

What this work reliably does is remove obstacles and stop you losing visitors who would otherwise have left. That is worth doing properly. It is a different claim from a promise.

Indexability

Why it matters: a page that cannot be indexed cannot rank, no matter how good it is. This is the first thing to check and the most common place I find real problems.

• Search site:yourdomain.com and look at what appears. Anything unexpected — admin screens, staging URLs, login pages — is a problem.
• Confirm important pages return HTTP 200, not a redirect or an error.
• Check that no public page carries a noindex directive. A noindex accidentally left on after a redesign is a classic and very expensive mistake.
• Confirm private areas do carry noindex. Blocking a URL in robots.txt only stops crawling — a URL discovered elsewhere can still be indexed without its content. noindex is what actually keeps it out.

robots.txt

Why it matters: it is a single small file that can accidentally hide your entire site, and it is edited rarely enough that mistakes survive.

• Visit /robots.txt and read it. It should be short and comprehensible.
• Confirm it does not block CSS, JavaScript or images — blocking those stops Google rendering your pages as users see them.
• Confirm it disallows genuinely private areas.
• Confirm the Sitemap: directive points at your real sitemap on the canonical domain.

XML sitemap

Why it matters: it is how you tell search engines which URLs you consider canonical and worth crawling.

• It should contain only public, indexable, canonical URLs.
• No private routes, no API endpoints, no error pages, no redirects.
• No duplicates, consistent on trailing slashes, all HTTPS, all on one hostname.
• Every URL in it should return 200 and self-canonicalise. A sitemap listing a URL whose canonical points elsewhere is a contradiction.
• Submit it in Search Console and check the status occasionally.

Canonical URLs

Why it matters: the canonical tag tells search engines which URL is the preferred version. When it disagrees with your sitemap, internal links or redirects, you are sending mixed signals about which page should rank.

• Every indexable page should carry a self-referencing canonical using the exact production URL.
• Consistent on protocol, hostname (www or not — pick one) and trailing slash.
• Do not put a canonical on a noindex page; the two instructions conflict.
• On paginated archives, each page should canonicalise to itself. Pointing page two back at page one tells Google to ignore it — and with it, every link to the items only listed there.

Titles and meta descriptions

Why they matter: the title is one of the strongest on-page relevance signals and, with the description, determines whether anyone clicks.

• Unique on every page. Duplicated titles across templates are extremely common and mean your pages compete with each other in the results.
• Titles roughly 60 characters, front-loaded with what the page is about.
• Descriptions roughly 120 to 160 characters, written to earn the click rather than to repeat keywords.
• Both should describe the page honestly. A description that oversells produces clicks that bounce.

Headings and hierarchy

Why they matter: headings describe structure to search engines, and to anyone navigating with a screen reader.

• Exactly one H1 per page, describing what the page is about.
• H2 for main sections, H3 for subsections. Do not skip levels for visual reasons.
• Choose heading levels for meaning, not font size. If an H2 is too large, style it — that is what CSS is for.
• Headings should make sense read on their own as an outline.

Internal linking

Why it matters: internal links are how crawlers discover pages and how readers move between related content. A page reachable only from the sitemap is a page nobody on your site is arguing for.

• No orphan pages — every public page should have at least one inbound link from another page.
• Link from body content, not only navigation.
• Use descriptive anchor text. "WordPress development services" tells a reader and a crawler what to expect; "click here" and "read more" tell them nothing.
• Do not overcorrect into stuffing every paragraph with exact-match anchors — that reads as manipulation.
• Link related pages to each other so the relationship is visible.

Image SEO

Why it matters: images are usually the heaviest thing on a page and the most commonly neglected accessibility feature.

• Descriptive alt text on meaningful images, written as a sentence a person would find useful — not a list of keywords.
• Empty alt on purely decorative images so assistive technology skips them.
• Width and height set, so the browser reserves space and the layout does not shift as images load.
• Correct dimensions — not a 4000px photo displayed in an 800px column.
• Modern formats such as WebP or AVIF.
• Lazy-load below the fold, but never the main hero image.

Core Web Vitals

Why they matter: they are a shared, measurable vocabulary for page experience, and slow pages lose visitors regardless of ranking effects.

• Largest Contentful Paint under 2.5 seconds.
• Interaction to Next Paint under 200 milliseconds.
• Cumulative Layout Shift below 0.1.
• Measured at the 75th percentile of real visits — not on your laptop on office Wi-Fi.
• Use field data, not only a one-off lab score.

Core Web Vitals explained covers what each one actually measures in plain language.

Mobile usability

Why it matters: Google has crawled and indexed all sites with its mobile crawler since completing that migration after 5 July 2024. The mobile rendering of your site is the version that gets indexed.

• The same content, links and metadata must exist in the mobile rendering as the desktop one.
• Tap targets large enough to hit reliably.
• No horizontal scrolling; text readable without zooming.
• Test on a real mid-range device, not a resized browser window.

HTTPS

Why it matters: it is a baseline expectation, and mixed content undermines it silently.

• The whole site served over HTTPS, with HTTP redirecting to it.
• No mixed content — a secure page loading an insecure image still shows as insecure.
• Certificate renewal monitored rather than assumed.
• Canonicals and sitemap URLs all using HTTPS.

Structured data

Why it matters: it helps search engines understand what a page represents and can make richer results possible.

• Use types that genuinely describe the page — Article for articles, Product for products, BreadcrumbList for breadcrumbs.
• Ensure it matches the visible content. Markup describing things that are not on the page is a policy violation.
• Never add review, rating or FAQ markup for content that does not genuinely exist on the page. This is the most common structured-data mistake and it carries real risk.
• Validate it, and keep one coherent block per page rather than several that contradict each other.

404 handling and redirects

• Missing pages should return a genuine 404 status, not a 200 with an error message — a "soft 404" leaves search engines indexing a page that says nothing.
• Your 404 page should offer useful routes back into the site. It is the one page you know a visitor reached by accident.
• Redirect once, from old URL to final destination. Chains waste crawl budget and lose a little signal at each hop.
• Update internal links to point at final URLs rather than relying on redirects.
• After any migration, map old URLs to new ones. Skipping this is the most reliable way to lose rankings in a redesign.

Search Console and analytics

Why they matter: without them you are guessing. Search Console is free, first-party, and the only place showing the queries you actually appear for and the problems Google has found.

• Verify the property and submit your sitemap.
• Review the indexing report — "why pages aren't indexed" frequently reveals canonical and duplication problems you would never otherwise see.
• Watch the queries report for what you actually rank for, which is often not what you expected.
• Confirm analytics is still recording. Tracking codes get lost during redesigns more often than you would think.

Duplicate and thin content

• The same content on multiple URLs — with and without trailing slash, with tracking parameters, printer versions — should resolve to one canonical URL.
• Avoid near-identical pages with a city or product name swapped. That doorway pattern is a documented spam signal and produces thin pages that rank for nothing.
• Thin pages that exist only to target a keyword usually dilute the site rather than help it. Fewer, deeper pages generally perform better.
• On e-commerce, watch for manufacturer descriptions reused verbatim across every retailer selling the same item.

The checklist

Print this, work down it, and re-run it after any significant change to the site.

• Indexability — important pages indexable, private pages noindex
• robots.txt — correct, and not blocking CSS, JavaScript or images
• XML sitemap — canonical public URLs only, submitted to Search Console
• Canonicals — self-referencing, consistent, agreeing with the sitemap
• Titles — unique, around 60 characters
• Meta descriptions — unique, around 120 to 160 characters
• H1 — exactly one per page
• Heading hierarchy — logical, chosen for meaning not size
• Internal links — no orphans, descriptive anchor text
• Image alt text — descriptive on meaningful images, empty on decorative
• Image optimisation — sized correctly, modern format, dimensions set
• Core Web Vitals — LCP, INP and CLS within thresholds on field data
• Mobile usability — content parity, comfortable tap targets
• HTTPS — sitewide, no mixed content, renewal monitored
• Structured data — accurate, validated, nothing fabricated
• 404 handling — genuine status code, useful page
• Redirects — single hop, no chains, internal links updated
• Search Console — verified, sitemap submitted, indexing report reviewed
• Analytics — installed and still recording
• Duplicate content — resolved to canonical URLs
• Thin content — consolidated or improved

How this differs by platform

The list is the same everywhere; the tooling differs.

On WordPress, most of it is handled by configuration and a good SEO plugin, with the risk that defaults go unreviewed. On an Elementor Pro build, pay particular attention to heading levels — a builder makes it easy to choose an H2 because it looks right rather than because it is right. On a Next.js project, all of it is built deliberately, which means it is exactly as good as the developer made it; the classic failure is metadata that only exists after JavaScript runs.

Where to go next

Work through the checklist and you will find most sites have real problems in three or four areas — usually indexability, canonicals, image handling and internal linking. Fixing those is worth more than months of link building.

If you would rather have it done properly, SEO and website performance is where that work lives, or get in touch for a second opinion on why your pages are not ranking.