SEO

Technical SEO Basics

Technical SEO is the part of search optimisation you cannot see: whether search engines can find your pages, read them, and understand them. Get it wrong, and the best content in the world will not rank — because it was never read.

By Abdul Hannan · Published 14 November 2026 · Updated 14 November 2026

Crawling, indexing and ranking — in order

A page goes through three stages before it can rank, and they happen in order. Crawling is the search engine’s visit: its crawler follows links from pages it already knows, downloading each new page it finds. Indexing is the decision to keep the page: the search engine reads it, understands what it is about, and stores it in its index — the catalogue of pages it can show. Ranking is the decision to show the page, and in what order, for a particular query. A page that is never crawled cannot be indexed. A page that is never indexed cannot rank. Most technical SEO is about the first two stages: making sure the crawler can reach the page, and making sure the page is worth indexing once it does.

The three stages have three different clocks. Crawling a new page takes days to weeks. Indexing follows, and ranking takes longer still — weeks to months for a new page on a new site. That is why the blogging guides on this site say consistent traffic takes three to six months: the delay is not in the writing, it is in the crawling, indexing and ranking that follow it. Patience is a technical requirement, not a virtue.

Helping the crawler find your pages

A crawler finds pages by following links, so the first technical rule is the same as the first content rule: every page must be linked from somewhere the crawler already visits. A page with no incoming links is invisible to the crawler as surely as it is invisible to the reader, and our internal linking guide exists for that reason. The second tool is the XML sitemap: a file that lists every page you want indexed, with its address and its last update date. The sitemap does not guarantee indexing — a crawler still decides for itself — but it tells the crawler where to look, and it is the first thing a new site should submit to the search engines’ webmaster tools. The sitemap should contain only indexable, canonical pages: no search results, no filter pages, no duplicates. On this site the sitemap and the list of indexable pages are kept equal, by design.

The third tool is the robots file: a small file that tells crawlers which parts of the site they may and may not visit. Its main job on a small site is pointing the crawler at the sitemap and keeping it away from pages that should never be indexed, such as internal search results. Used wrongly it can block the whole site, so it should be checked after every change — a blocked site is a silent failure, and the owner is usually the last person to notice.

Helping the crawler read your pages

Once the crawler reaches a page, it must be able to read it. The most common reading failures are mundane. A page whose content is loaded entirely by JavaScript may be read late or not at all, because the crawler must run the scripts before it can see the words — and although the major search engines do this, they do it slowly and sometimes incompletely. A site built with server-side or static rendering, where the words are in the page when it is downloaded, avoids the problem entirely. That is why this site is built as static pages: the content is in the HTML the crawler receives.

The structure of the page matters too. One H1 per page, heading levels that do not skip, descriptive titles and meta descriptions, and image alt text that says what the image shows — these are not decoration, they are the signals the crawler uses to understand the page. A page with three H1s, or with an H1 that says nothing about the content, is a page that has made the crawler’s job harder for no reason. And a page that repeats its title in every heading is a page that has told the crawler nothing new. Our keyword research guide covers what the titles and headings should say; the technical point is that they must exist and be in order.

Canonicals and duplicates

A canonical tag tells the search engine which address is the real one when the same content can be reached by more than one address — for example with and without a trailing slash, or with a tracking parameter added. Without one, the search engine may treat the two addresses as two pages, split the signals between them, and rank neither well. Every page on this site carries a canonical tag that points to its own address, and the site redirects the alternate addresses to it. The rule for the person writing is simple: one page, one address, one canonical. If two pages say the same thing, they are one page that has not been merged yet.

Duplicate content is the wider form of the same problem. Pages that repeat each other — two near-identical guides, a category page that copies an article, a tool page that duplicates a guide — dilute the site’s authority and confuse the crawler about which page to show. The cluster structure described in the topic cluster guide is the defence: one page per intent, each answering a different question, so no two pages compete for the same query.

Speed and the reader’s patience

Speed is a ranking factor and a reader factor, and the two are the same fact: a page that loads slowly is a page the reader leaves. The search engines’ own targets for a good experience are a largest contentful paint within about two and a half seconds, minimal delay on interaction, and no visible layout shift while the page loads. A small static site can meet those targets easily: light pages, optimised images, no heavy scripts, no third-party code that blocks the page. The enemies of speed are familiar: large unoptimised images, advertising scripts, social widgets, and JavaScript that runs before the content is shown. Every one of them should earn its place on the page, or be removed.

Mobile is where speed matters most, because most readers arrive on a phone, often on a slow connection. A page that loads quickly on a desktop and slowly on a phone is a page that fails most of its readers. Test on a real phone, on a real mobile connection, not only on a desktop. This site is built mobile-first, and every page is expected to work on a small screen without horizontal scrolling, with links and buttons large enough to tap.

Structured data — and what not to fake

Structured data is extra information in the page, in a format the search engine can read directly, that describes what the page is: an article, a set of FAQs, a breadcrumb trail, an organisation. It can earn a page richer results — a FAQ shown under the title, a breadcrumb path instead of a bare address — and it is worth adding where the visible content supports it. Every article on this site carries BreadcrumbList, Article and FAQPage structured data, because the visible content — the breadcrumbs, the article, the FAQs — is really there.

The rule is that structured data must describe what is visibly on the page, and nothing else. It must never be used to claim something the page does not have — reviews that do not exist, ratings nobody gave, a price the product does not carry. Fake structured data is a deception, and search engines treat it as one: the penalty falls on the page, and in serious cases on the site. This site carries no review or rating schema anywhere, because it has no genuine reviews to describe.

A beginner’s technical checklist

  • HTTPS everywhere. Browsers warn readers away from insecure sites.
  • Every page linked. No orphans: every page linked from at least three others.
  • Sitemap submitted. Only indexable, canonical pages, and the sitemap kept equal to that list.
  • Robots file checked. Pointing at the sitemap, blocking nothing that should be indexed.
  • One H1, no skipped headings. Titles and meta descriptions unique per page.
  • Canonical on every page. One page, one address, one canonical.
  • Content in the HTML. No page that depends on JavaScript to show its words.
  • Fast and mobile-first. Light pages, optimised images, tested on a real phone.
  • Structured data that is honest. Only what the visible page supports; no fake reviews or ratings.
  • HTTPS and errors checked after every deploy. A broken deploy is a silent failure — verify the live pages.

None of these is difficult on its own. Together they are the difference between a site the search engines can read and a site they cannot. The content guides in the SEO section explain what to write; this page explains how to make sure it is seen. The blogging guide covers the setup that a new blog needs, which is the same checklist applied to a first site.

Last checked: 14 November 2026.