Technical SEO best practices to build into your website.

Technical SEO best practices are the structural decisions made during development that let search engines find, understand and rank every page: a crawlable site structure, fast pages that pass Core Web Vitals, correct indexation and canonicals, clean redirects and valid structured data. Each is far cheaper to build in at launch than to retrofit, and retrofitting often means a rebuild.

Technical SEO is often described as a checklist run after a site is finished. That framing backfires, because these problems are design decisions: whether a page renders on a phone, whether a redirect chain exists, whether it carries a canonical tag, all get settled in the build. Left to chance, you end up paying for the same site twice, a pattern the website development cost guide shows.

Why technical SEO belongs in the build

Technical SEO covers four things: whether a crawler can reach a page, whether it renders properly on a phone, whether the markup tells search engines what the page is about, and whether the signals about that page are consistent. The reason these technical SEO best practices belong in the build is sequence: crawl budget wasted on redirect chains is spent before anyone sees your content, and a template or heading decision made in week one applies to every page published for the next three years.

Crawlability and site structure

Crawlers discover pages by following links, and pages buried several clicks deep get crawled less often and less completely.

Keep the hierarchy shallow. Aim for any page within three clicks of the homepage. Flat structures are easier to crawl and to navigate.

Use descriptive, permanent URLs. /services/web-development/ communicates the topic; /page?id=42 communicates nothing, and changing it later breaks every link pointing to it.

Build internal links deliberately. Every important page should be reachable through contextual links from related pages, not only from menus. A page linked only from menus gets crawled less deeply than one linked from four relevant articles.

Keep the XML sitemap accurate and automatic. Generate it from the site, reference it in robots.txt, and submit it in Google Search Console. A sitemap is a hint, not a command: listed pages can still be blocked by robots directives or noindex tags, and when those disagree the crawler goes in circles.

Check robots.txt before launch. An over-restrictive file is one of the most common causes of a site that has content but cannot be found.

Keep faceted URLs under control. Filters and sorting parameters can generate thousands of variants of the same page. Decide which parameters are meaningful and block the rest consistently.

Page speed and Core Web Vitals

Google’s Core Web Vitals are three field metrics that describe how a page feels to a real visitor on a real device. web.dev’s guide to vitals and the Google Search documentation on Core Web Vitals describe how they are collected, and the thresholds below are the standard to build against.

Largest Contentful Paint (LCP) under 2.5 seconds. This measures when the largest visible element, usually a heading or hero image, finishes painting. It answers “is the page showing up?” A slow LCP usually points to slow server response, an unoptimised hero image or render-blocking resources.

Interaction to Next Paint (INP) under 200 milliseconds. This measures how quickly the page responds to a tap, click or keypress by drawing the next frame. It answers “does it feel alive?” It replaced First Input Delay as a Core Web Vital, and it catches the long tasks and heavy scripts that make a site feel sticky on a phone.

Cumulative Layout Shift (CLS) under 0.1. This measures how much visible content moves unexpectedly while the page loads. It answers “did the page stay put?” CLS comes from images without reserved dimensions, late-loading fonts and injected banners. It is the easiest metric to fix, and to introduce by accident.

Passing them is a concrete part of technical SEO best practices, mostly settled by a few early decisions: server response well under half a second, images compressed in a modern format, fonts preloaded and subset, JavaScript split and deferred, and a layout where every element has a defined size.

Test on a mid-range phone over a throttled connection, not a laptop on office wifi. That is where the thresholds are most often missed, and a slow page costs conversions either way.

Mobile rendering and responsive design

Google indexes the mobile version of a site. If that version is reduced or broken, that is what gets ranked.

The requirement: serve one codebase with a responsive layout, and do not hide content from mobile visitors. A menu item that exists only in the desktop navigation is content search engines may never see.

Practical checks:

• No horizontal scrolling at any viewport width, and text readable without zooming.
• Tap targets large enough to hit, and interactive elements, including forms, working with touch input.
• Fonts sized in relative units, and images using srcset and sizes attributes so phones do not download desktop files.

Serving a separate mobile site is a common mistake: it splits your authority across URLs and adds redirect complexity. One responsive site is simpler and easier to keep sound.

Structured data

Structured data is a standard format, usually JSON-LD, that describes what a page contains in a way machines can read. Google supports it for types including Article, Organization, LocalBusiness, Product, FAQPage, BreadcrumbList and Event.

It tells a search engine how to interpret a page rather than leaving the engine to infer it, and marking a page as an Article, an FAQ or a Product can feed richer results and extra information under the listing.

Implementation rules are strict, and the penalty for getting them wrong is that the markup is ignored.

• It must describe content that is actually visible on the page. Marking up hidden text violates the guidelines.
• Use one recommended type per page where possible. Stacking unrelated types dilutes the signal.
• Keep it in sync with the page. Marking up a product that no longer exists is worse than having no markup.
• Validate before launch and after every significant content change, using Google’s rich results test.
• Do not treat it as a ranking factor. It helps machines understand the page, but it does not replace good content.

For a business site, the minimum sensible set: Organization or LocalBusiness on the home page, BreadcrumbList on inner pages, and Article on editorial content.

Indexation, canonicals and duplicate content

Indexation is the decision that a page belongs in search results. It is made per URL, and it should be deliberate.

Choose indexation on purpose. noindex is the right answer for utility pages, thin archives, internal search results and anything you do not want listed. Leaving the decision to chance means pages you never wanted get indexed, diluting the signals for the ones you did.

Understand duplicate content. The same content can exist at more than one URL: a service page and a landing page for the same offer, or a product reachable through two category paths. Duplicates are not automatically a penalty, but search engines must pick one version, and picking the wrong one means your canonical page may not rank.

Use canonical tags consistently. The tag tells search engines which URL is primary. It should be an absolute URL, appear once, and point to itself on the canonical page. It is followed more reliably when the internal links and sitemap agree with it.

Watch for parameter and case variants. The same page reachable at two letter cases is two URLs unless the server redirects one to the other, which is cheaper to solve with a permanent redirect than to leave for search engines to sort out.

Redirects and URL hygiene

Redirects are the most common source of wasted crawl budget on otherwise sound sites.

Use 301 for permanent moves. A 301 tells search engines the content has moved and transfers the signals. A 302 is temporary: right for short-lived campaigns, wrong for a page that moved for good.

Point directly at the final URL. A chain of three redirects works for a browser and wastes signals for a crawler. Map every old URL to its new home in one step.

Keep a redirect map from day one. Record every URL you launch, retire or change, with the reason and the date, because the alternative is discovering a broken redirect when nobody remembers the old structure.

Do not redirect everything to the homepage. Redirect to the closest relevant page, and return a proper 404 where there is no equivalent.

Watch for soft 404s. A page that returns a 200 status but shows a “page not found” message tells search engines the page exists and is empty. A custom 404 page should return a real 404 status code.

Accessibility and SEO overlap

Accessibility and technical SEO overlap more than most teams expect, because both depend on the same underlying structure: semantic HTML, sensible heading order, descriptive link text, alt text and a working keyboard path. A screen reader user needs real heading levels and real buttons; a crawler needs the same semantic clarity to understand the page. The shared wins:

• One h1 per page, with heading levels in order.
• Descriptive link text. “Click here” tells a user and a crawler nothing.
• Alt text on meaningful images, empty alt on decorative ones.
• The full page can be completed by keyboard alone, with a visible focus state.
• Sufficient colour contrast between text and background.
• Every form field labelled, with the label properly associated with its input.

Meeting WCAG 2.1 AA is the usual target for a professional site. Raise it early, because retrofitting keyboard support and semantic structure across a live site is expensive.

Technical SEO best practices checklist for launch

Run through this before the site goes live. Items that fail here are much cheaper to fix now than after launch.

Crawlability

• Every important page is reachable within three clicks of the homepage.
• robots.txt allows the pages you want indexed and blocks the ones you do not.
• The XML sitemap is generated automatically, lists canonical URLs only, is referenced in robots.txt, and is submitted in search console.

Indexation

• Every indexable page has a self-referencing absolute canonical tag.
• noindex appears only where you have decided a page should be excluded, not by default across a template, and no page has a conflicting canonical or robots directive.

Performance and mobile

• LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1 on mobile, measured on a throttled connection.
• Images are compressed, sized correctly and in a modern format, with srcset where needed.
• Fonts are preloaded or subset, and render without shifting the layout.
• No horizontal scrolling at 320 pixels wide, tested on a real mid-range phone.

Markup and content

• Structured data validates, matches visible content and appears once per page.
• One h1 per page, headings in order, and alt text on every meaningful image.
• Descriptive, unique <title> and meta description on every indexable page.

Routing and hygiene

• Every permanent URL change has a single-hop 301 redirect, with no chains or loops.
• URLs are lower case, hyphenated and consistent.
• A real 404 page returns a 404 status code, and HTTPS is enforced site-wide.
• Staging and preview URLs are not indexable.

Measurement

• Analytics and search console access are in place on the live domain, and a baseline of index coverage and search performance is recorded on launch day.

Keeping technical health after launch

Following technical SEO best practices does not end at launch. Technical health decays quietly, as plugins get outdated, content gets republished at new URLs, and marketing tools add tracking scripts that slow pages down.

A practical routine, often folded into a wider website maintenance plan:

• Monthly. Review search console coverage reports, fix newly flagged errors, confirm the sitemap is current, and check Core Web Vitals in field data.
• Quarterly. Review pages that lost indexation, audit top landing pages for speed and mobile issues, check the redirect map against real traffic, and re-validate structured data on key templates.
• After every release. Run the launch checklist against the changed templates. Most regressions come from a single new plugin or script, and a fifteen-minute check catches them.
• Continuously. Watch Core Web Vitals trends and real-user monitoring data for your highest-traffic pages, because field data reflects the actual devices and connections you did not test on.

The ongoing work is small and predictable, which is why it works as a retainer rather than a series of emergencies. The technical foundations belong in the same scope as web development rather than being added later, and the reporting connects to how digital marketing measures performance and data analytics tracks it. Talk to us about your site, and if you are choosing who to do it, the hiring guide covers how to run that selection.