Technical SEO 2027: The Complete Plain-English Guide

Google's own starter guide describes SEO as helping search engines understand your content and helping people find your site. Technical SEO is the first half of that sentence. The second half belongs to content and on-page SEO, which shapes what each page says.

So think of it as plumbing. Nobody visits a house to admire the pipes, but everybody notices when the water stops. A site with clean technical work rarely gets praised for it. A site without it leaks traffic every single day.

What Technical SEO Is Not

It isn't a trick, and it isn't a score. A tool that shows "94 out of 100" tells you what that tool measured, not what Google thinks. Google states that it doesn't accept payment to crawl a site more often or rank it higher, so no plugin, badge or "submission service" can buy you a shortcut either. (Yes, people still sell those.)

What It Costs and How Long It Takes

If you do the work yourself, the main tools are free: Google Search Console, PageSpeed Insights and the Rich Results Test cost nothing. If I do it for you, my rate is €25 an hour, and technical work is part of every monthly plan further down this page.

As for time, be patient. Google's starter guide says some changes take effect in a few hours and others can take several months, and it suggests waiting a few weeks before you judge a change. A request for indexing in Search Console can take up to a week or two, and it isn't a guarantee. Anyone who promises faster is guessing.

Stage One: Crawling

First, Google has to learn that a page exists. There's no central list of web pages, so Google keeps looking for new and updated URLs. It finds most of them by following a link from a page it already knows, and some through a sitemap you submit.

Then a program called Googlebot fetches the page. Googlebot decides by algorithm which sites to crawl, how often, and how many pages to fetch from each. It's also built to avoid crawling a site too fast, so it doesn't overload your server. If your server answers slowly or returns errors, crawling slows down.

During the crawl, Google renders the page. Rendering means it runs the page's JavaScript in a recent version of Chrome, much like your browser does, so that content added by scripts becomes visible to it.

Stage Two: Indexing

Next, Google tries to understand what it fetched. It analyzes the text and the key tags and attributes, such as the title element and image alt text. It also decides whether the page duplicates another page.

To do that, Google groups pages with similar content into a cluster and picks one as the canonical, which is the version that may be shown in results. The others in the cluster are alternates. Then the canonical page's information may be stored in the Google index, a very large database.

The word "may" matters. Google says indexing isn't guaranteed. Common reasons a page is left out are low content quality, a robots meta rule that disallows indexing, or a site design that makes indexing difficult.

Stage Three: Serving Results

Finally, when someone searches, Google looks through the index for matching pages and returns the ones it believes are the most relevant and of the highest quality. Relevance is determined by hundreds of factors, including the searcher's location, language and device. That's why "bike repair shop" shows different results in Paris than in Hong Kong.

Technical SEO mostly works on stages one and two. However, it touches stage three as well, because page experience signals such as Core Web Vitals are used by Google's ranking systems. More on those below.

Duplicate Content Is Not a Penalty

Let's clear up an old scare first. Google's starter guide says duplicate content on your own site is not a violation of its spam policies. It calls it inefficient, not something that causes a manual action. The real cost is wasted crawling and Google picking a URL you didn't want.

Duplicates usually come from boring places: http and https versions, www and non-www, trailing slashes, tracking parameters, and product lists that can be sorted six ways.

How to Tell Google Your Preferred URL

Google lists the methods by strength. A redirect is a strong signal that the target should become canonical. A rel="canonical" link is also a strong signal. Including the URL in a sitemap is a weak signal. You can combine them, and combining them raises the odds that your preferred URL wins.

A canonical link sits in the head of the page and looks like this: <link rel="canonical" href="https://www.example.com/shoes/">. It works for HTML pages only. For files such as PDFs, the same instruction can be sent as an HTTP header.

Then back the signal up. Link internally to the canonical URL, not to a duplicate. Prefer the HTTPS version, because Google prefers HTTPS pages over equivalent HTTP pages as canonical. And don't use robots.txt or noindex to choose a canonical. Google warns against both, because a blocked page can't be read and a noindex page is removed from Search completely.

How Noindex Works

Noindex is a rule you set in one of two ways. The first is a meta tag in the page's head: <meta name="robots" content="noindex">. The second is an HTTP response header, X-Robots-Tag: noindex, which also works for non-HTML files.

One condition is essential. For noindex to work, the page must not be blocked by robots.txt. If the crawler can't fetch the page, it never sees the rule, and the URL can stay in the index. Blocking a page in robots.txt and adding noindex to it is the most common contradiction I find in audits.

If rules conflict, for example one tag says index and another says noindex, Google applies the more restrictive one. Both rules matter just as much when a whole site moves, which is why migrations get their own checklist.

JavaScript Rendering Basics

Google processes JavaScript pages in three phases: crawling, rendering and indexing. After the first fetch, the page waits in a render queue. Google says that wait may be a few seconds, but it can take longer. So content that only appears after scripts run is indexed later than content in the plain HTML.

Because of that, Google still calls server-side rendering or pre-rendering a great idea. Both mean the server sends finished HTML. It's faster for visitors, and not every bot can run JavaScript.

A few rules save most JavaScript sites:

• Use real links: a elements with an href attribute.
• For page-to-page navigation inside an app, use the History API, not URL fragments.
• Return meaningful status codes. If a single-page app can't, redirect missing pages to a URL that returns 404, or add noindex with JavaScript.
• Never put noindex in the original HTML and hope to remove it with a script. When Google sees noindex, it may skip rendering altogether.
• Don't change the canonical URL with JavaScript to something different from the one in the original HTML.

To see what Google actually rendered, use the URL Inspection tool in Search Console and open the rendered HTML. If your main text isn't in there, Google doesn't have it.

Mobile-First Indexing

Mobile-first indexing means Google uses the mobile version of your content, crawled with its smartphone agent, for indexing and ranking. In other words, what your site shows on a phone is your site as far as Google is concerned.

Google recommends responsive design, where one URL serves the same HTML and the layout adapts to the screen. It's the easiest pattern to build and maintain. If you have a separate mobile version, the mobile and desktop pages need the same content, the same robots meta tags, the same structured data, equivalent titles and meta descriptions, and the same image alt text.

One more trap: don't lazy-load primary content upon user interaction. Googlebot doesn't swipe, click or type, so content that appears only after a tap stays invisible.

HTTPS

HTTPS is the secure version of the web protocol, shown by the padlock in the browser. Google's page experience guidance asks, as one of its self-check questions, whether your pages are served in a secure fashion. Google also prefers HTTPS pages over equivalent HTTP pages as canonical, unless something is wrong, such as an invalid certificate.

So the setup is short. Install a valid certificate. Redirect every HTTP URL to its HTTPS twin with a permanent redirect. Update internal links, canonical tags and the sitemap to the HTTPS addresses. Google counts a move from HTTP to HTTPS as a site move with URL changes, which is why the redirects matter.

Why the Order Matters

If robots.txt blocks the whole site, nothing after check two can be fixed by editing pages. So fix access first, then understanding, then experience. That is also the order of the three parts at the top of this guide.

Which Tools You Need

Google Search Console is free and tells you what Google itself saw. A crawler, which is a program that visits your pages the way Googlebot does, shows the problems Google hasn't reported yet. PageSpeed Insights covers speed. For a small site, those three are enough. If you'd rather hand the whole list to someone, my SEO audit service runs it for €25 an hour and returns one page of fixes sorted by impact.

Two details save a lot of worry. First, the report has a Source column showing whether the cause is Google or your website, and you can generally fix only the issues whose source is Website. Second, "Crawled - currently not indexed" is common, and Google says it doesn't necessarily need attention, because Google doesn't index every page on the web.

For example, a plumber in Austin with 30 service pages might see two thin tag pages listed as crawled but not indexed. That's a shrug. The same status on the "emergency plumber" page is a problem worth a closer look at the content and internal links.

Two Rules for Validation

Fix every instance of an issue before you click Validate fix, because Google says validation stops if even one instance remains. After you click it, don't click it again until validation has succeeded or failed.

What the Rendered HTML Tells You

URL Inspection can show the raw HTML and a screenshot of the rendered page, but the screenshot is available only in a live test. If your main text is missing from the rendered HTML, fix that before anything else, because Google can't index what it can't see.