SEO

Technical SEO: a practical guide

The technical groundwork that lets search engines find, read and trust your pages, from speed and HTTPS to crawling, site structure and structured data, with a checklist you can work through.

By the MarQira teamPublished Updated 9 min read

A technical SEO guide answers one question: can search engines find, load, understand and trust every page you want to rank? Technical SEO is the groundwork under your content. It covers site speed, mobile usability, HTTPS, crawling and indexing, site structure and structured data. When it is broken, even excellent pages struggle to appear.

This guide walks through each area in plain terms, explains what Google actually looks at, and ends with a technical SEO checklist you can work through on your own site. It replaces an older article of ours, refreshed to drop advice that no longer holds.

What technical SEO covers

Search engines work in three broad stages: they crawl (discover and download pages), index (process and store them) and rank (decide which indexed pages best answer a search). Technical SEO is everything that helps the first two stages go smoothly and gives the third stage clean signals to work with.

In practice it breaks down into six areas:

Area The question it answers
Speed and Core Web Vitals Does the page load quickly and respond smoothly for real visitors?
Mobile and HTTPS Does it work properly on a phone, over a secure connection?
Crawlability Can search engines reach every page you care about, and skip the rest?
Indexing Is the right version of each page stored, without duplicates?
Site architecture Do the structure, URLs and internal links make sense to people and bots?
Structured data Can machines read the key facts on the page without guessing?

One thing that is not on the list any more: the meta keywords tag. Older guides, including the earlier version of this one, still recommended filling it in. Google stated back in 2009 that it does not use the keywords meta tag in web ranking (opens in a new tab), and nothing has changed since. Leave it out. Your time is better spent on a distinct title and meta description for every page.

Speed and Core Web Vitals

Site speed and SEO are linked through Google’s Core Web Vitals, three measurements of how a page feels to use:

  • Largest Contentful Paint (LCP): how quickly the main content appears. Good is 2.5 seconds or less.
  • Interaction to Next Paint (INP): how quickly the page responds to taps, clicks and typing. Good is 200 milliseconds or less.
  • Cumulative Layout Shift (CLS): how much content jumps around while loading. Good is 0.1 or less.

Google publishes these thresholds on web.dev (opens in a new tab) and measures them on real visitors, at the 75th percentile, over 28 days. Our Core Web Vitals guide covers each metric and its fixes in detail.

The causes of a slow site are usually predictable:

  1. Slow hosting and no caching. If the server takes a second to send the first byte, everything else starts late.
  2. Oversized images. Serve AVIF or WebP, size images to the space they fill, and give every image a width and height.
  3. Too much JavaScript. Page builders, sliders, chat widgets and stacked tracking tags all compete for the browser’s attention.
  4. Render-blocking files. Large theme and plugin stylesheets have to load before anything appears.

Speed is far easier to build in than to bolt on. It is one of the reasons we treat performance as part of web design and development, not as a clean-up job after launch.

Mobile and HTTPS

Mobile first

Google uses the mobile version of your site for indexing and ranking, which it calls mobile-first indexing (opens in a new tab). If something exists only on desktop, such as a block of text, a table or a set of links, Google may never see it.

Check these on a real phone, not just a narrow browser window:

  • The same content and links appear on mobile and desktop.
  • Text is readable without zooming, and buttons are large enough to tap.
  • Nothing scrolls sideways, and pop-ups do not cover the content on arrival.
  • Images and structured data are present on the mobile version too.

HTTPS everywhere

Google confirmed HTTPS as a ranking signal (opens in a new tab) years ago, and browsers now label plain HTTP pages as “Not secure”. Beyond having a certificate, make sure that:

  • every HTTP URL redirects to its HTTPS version in a single 301 hop;
  • you have chosen one host (with or without www) and redirect the other;
  • no images, scripts or fonts still load over HTTP (mixed content);
  • internal links, canonical tags and the sitemap all use the HTTPS address.

Crawlability and indexing

Crawlability is whether search engines can reach your pages. Indexing is whether they keep them. A page can be crawlable and still not indexed, so check both.

Help crawlers find the right pages

  • robots.txt tells crawlers which areas to skip. Use it to keep them out of admin areas, internal search results and endless filter combinations. Do not use it to hide pages from the index; Google’s robots.txt introduction (opens in a new tab) explains why a blocked page can still be indexed from links.
  • An XML sitemap lists the pages you want indexed. Include only live, indexable URLs that return 200, and submit it in Search Console.
  • Internal links are how crawlers discover most pages. A page nothing links to (an orphan page) may never be found.

Keep the index clean

  • Use noindex on pages with no search value, such as thank-you pages, tag archives and internal search.
  • Set a canonical URL on every page, so that duplicates (tracking parameters, print versions, sorted product lists) point to the version you want ranked. Google’s guide to consolidating duplicate URLs (opens in a new tab) covers the options.
  • Return honest status codes. Missing pages should answer 404 (or 410), moved pages 301. A “page not found” message served with a 200 status is a soft 404, and it wastes crawling.
  • Avoid redirect chains. Every old URL should reach its final destination in one hop.
  • Do not hide content behind JavaScript. If key text or links only appear after scripts run, test the page with the URL Inspection tool to confirm Google renders it.

The Pages report in Google Search Console shows which URLs are indexed and why the rest are not. Read it monthly; it is the fastest way to catch an accidental noindex or a broken redirect.

Good site architecture means a visitor (or a crawler) can reach any important page in a few clicks, and can tell from the URL and the page itself where they are.

URLs and navigation

  • Keep URLs short, readable and lowercase, with hyphens between words: /services/seo/, not /index.php?p=123.
  • Leave dates and years out of URLs. They make evergreen content look stale and force a redirect when you update it. The old version of this article had a year in its address; this one does not.
  • Group related pages under a clear parent, such as services under /services/ and articles under /blog/.
  • Add breadcrumbs, so both people and search engines can see the hierarchy.

Internal links pass context and authority between your pages. A few rules cover most of it:

  • Link from broad pages to specific ones and back again: a service page to its supporting articles, and each article to the service it supports.
  • Use descriptive anchor text that says what the target page is about. “Our WordPress maintenance checklist” helps; “click here” does not.
  • Make sure every page you want to rank has at least one contextual link from another relevant page.
  • Fix or remove links to pages that redirect or no longer exist.

Titles, headings and alt text

These sit on the border between technical and on-page SEO, and they are easy to get right:

  • One unique title per page, roughly 50 to 60 characters, with the main topic near the start.
  • A meta description that summarizes the page in a sentence or two. It does not affect ranking directly, but it shapes the snippet people decide to click.
  • One H1 that states what the page is about, then H2s and H3s in order, without skipping levels.
  • Alt text that describes each meaningful image for people who cannot see it. Leave decorative images with empty alt text.

Structured data

Structured data is a block of code, usually JSON-LD, that states the key facts on a page in a format machines can read: this is an article, published on this date, by this organization; this is a business, with this logo and this email address.

It helps in two ways. It can make pages eligible for richer search results, and it gives search engines and AI assistants an unambiguous description of who you are and what the page covers. Google’s introduction to structured data (opens in a new tab) lists the types it supports.

The types most business sites need:

  • Organization on the homepage: name, logo, URL and contact details.
  • BreadcrumbList on inner pages, matching the visible breadcrumbs.
  • Article or BlogPosting on articles, with dates and author.
  • Product on product pages, with price and availability.
  • LocalBusiness, but only if you publish a real address.

Mark up only what is visible on the page, keep it accurate, and test it with Google’s Rich Results Test (opens in a new tab) after every change.

Checklist

Work through this technical SEO checklist once, then revisit it every quarter or after any significant change to the site.

Speed and mobile

  • Field data in PageSpeed Insights passes LCP, INP and CLS on mobile.
  • The main image on each key page is compressed, correctly sized and not lazy-loaded.
  • Page caching and a CDN are on.
  • Mobile and desktop show the same content, links and structured data.

Security and hosts

  • Every page loads over HTTPS, with no mixed content.
  • HTTP and the unused host (www or not) redirect in one 301 hop.

Crawling and indexing

  • robots.txt blocks only areas with no search value, and points to the sitemap.
  • The XML sitemap lists only live, indexable, canonical URLs.
  • Every indexable page has a self-referencing canonical tag.
  • Missing pages return 404; there are no soft 404s or redirect chains.
  • The Search Console Pages report shows no unexpected exclusions.

Structure and pages

  • URLs are short, readable and free of dates.
  • Every important page has contextual internal links pointing to it.
  • Each page has one H1, a unique title and a meta description.
  • Meaningful images have descriptive alt text.
  • No meta keywords tags remain.

Structured data

  • Organization, BreadcrumbList and Article markup are present where they apply.
  • The Rich Results Test shows no errors.

If you would rather hand this over, a technical audit is where our SEO services usually start: we crawl the site, rank the issues by impact and fix them, or brief your developer. Planning a new site? Read our website redesign SEO checklist before anything moves, and browse the rest of our WordPress and SEO guides for the next step.

Questions about this topic

What is the difference between technical SEO and on-page SEO?

Technical SEO makes sure search engines can reach, render and index your pages, and that the site is fast, secure and well structured. On-page SEO is about the content of each page, such as its topic, copy, headings and title. Both matter, and technical problems can stop good content from ranking at all.

Should I still add a meta keywords tag?

No. Google has said publicly since 2009 that it does not use the keywords meta tag in web ranking. It does no good, and it shows competitors which terms you are targeting. Spend the time on a clear title and meta description for each page instead.

How often should I run a technical SEO audit?

Run a full audit before and after any redesign or migration, and a lighter check every quarter. In between, keep an eye on the Pages and Core Web Vitals reports in Google Search Console, which flag most new problems within days.

Can I do technical SEO myself on WordPress?

Much of it, yes. An SEO plugin handles titles, descriptions, sitemaps and canonical tags, and Search Console shows what Google sees. Speed work, redirect mapping and structured data beyond the basics are where most site owners bring in help.

Tell us what you’re building.

A short message is enough. We read every enquiry personally and reply with honest next steps, even if that means pointing you elsewhere.