Technical SEO

Technical SEO is the work that lets a search engine reach your pages, read them, understand them and decide to store them. It covers crawling, indexing, site structure, speed, how the site behaves on a phone, and the markup that describes your content to a machine. It is the foundation of SEO, and it is the part nobody notices until it is wrong, because a technical fault does not announce itself. It simply limits everything built on top of it.

In short

• Technical SEO decides whether Google can reach and store your pages at all.
• Most problems are invisible from the front of the site.
• Google Search Console tells you what is wrong, for free, and few people look.
• It is a foundation, not a growth tactic. It removes ceilings rather than adding traffic.

Crawling: can Google reach the pages

Before a page can rank, something has to find it. Google’s crawler follows links and reads a few files that tell it what it may do.

• Internal links are the main route. A page that nothing links to is a page the crawler may never reach, no matter how good it is. Orphan pages are common on sites that have been added to for years, and they are usually a symptom of the information architecture rather than of the page.
• robots.txt is a file at the root of your site that tells crawlers which areas to stay out of. It is useful and it is dangerous. A single misplaced line here can tell every search engine to ignore the entire site, and it is a genuinely common way for a site to vanish after a redesign.
• The XML sitemap is a list of the pages you want indexed. It helps Google find things, particularly on a new site with few incoming links.
• Crawl efficiency. Google will not spend unlimited effort on any one site. A site that wastes that effort on thousands of near-identical filtered pages leaves less for the pages that matter. This only becomes a real concern on large sites, and on large sites it becomes a serious one.

Indexing: can Google store them

Being crawled is not being indexed. Google reads far more pages than it keeps.

A page can be excluded because it carries a noindex tag, often left behind from a staging site and then forgotten, which is one of the most expensive one-word mistakes available. It can be excluded because a canonical tag points at a different page as the preferred version. It can be excluded because it duplicates something else on the site, or because Google judged it thin enough not to be worth storing.

The important thing is that none of this is visible from the front of the site. The page loads perfectly for you. It is simply not in the index, and therefore cannot appear for anything.

Google Search Console reports every one of these decisions with a reason attached. It is free, and it is the only report that comes from Google rather than from a tool making an estimate.

Speed, and what Google actually measures

Google measures the experience of loading a page through three numbers, usually called Core Web Vitals. They sound technical and they describe things you have felt: how long before the main thing appears, how quickly the page answers when you tap, and how much it jumps about while loading.

The thresholds and where to read your own scores are on that entry. What matters here is that the causes are almost always the same: oversized images, too many scripts, and a server that is slow or far away. Which makes speed partly a hosting question, since a server in Singapore reaches a phone in Davao faster than one in Frankfurt.

Speed is a genuine ranking factor and a mild one. It matters much more for whether a visitor on mobile data waits for your page at all.

Mobile, which is the version Google judges

Google indexes the mobile version of your site, not the desktop one. If something exists on desktop and is hidden on mobile, Google may simply not see it. What makes a layout adapt in the first place is covered under responsive design.

That makes a few things worth checking on an actual phone rather than a narrowed browser window. Whether the content is all present. Whether text is readable without zooming. Whether buttons are large enough to hit. Whether anything overflows sideways, which is the most common visual fault and the easiest to miss on a laptop.

In this market it is also the realistic case rather than the edge case. Most of your visitors are on a mid-range Android phone on mobile data.

Structured data, and what it is for

Structured data is markup added to a page that describes what the page is in a form a machine reads without interpretation. Not “this looks like an address and some opening hours”, but “this is the address, and these are the hours”.

It does not directly improve rankings. What it does is remove guesswork, and the rule that keeps you safe is that the markup must match what the page actually says. Which types still earn their place, and which features Google has withdrawn, is covered on the structured data entry.

The things that quietly break

These are the most common faults, and none of them are visible to a visitor.

• Redirect chains. Page A sends to B, which sends to C. No ranking value is lost along the way, and every hop still costs the visitor time. It builds up over years of small changes.
• Broken internal links after pages are renamed or removed.
• A staging site left indexed, competing with the real one.
• Mixed content, where a secure page loads an insecure image or script, which can trip browser warnings.
• An expired SSL certificate, which throws a security warning on an otherwise healthy site and stops most visitors immediately.
• Several addresses serving one page, with and without www, with and without a trailing slash, http and https. Each version splits the signals unless one is made canonical.
• Pagination and filters generating thousands of near-identical addresses on stores, which is where crawl efficiency stops being theoretical.

Words you will hear, and what they mean

• Crawl. A search engine visiting and reading a page.
• Index. The store of pages a search engine has kept. Being in it is a precondition for ranking.
• robots.txt. The file telling crawlers where they may go.
• XML sitemap. The list of pages you want found.
• Canonical tag. A declaration of the preferred address for a page.
• noindex. An instruction not to store this page.
• 301 and 302. Permanent and temporary redirects. Use 301 when a page has moved for good, which is nearly always.
• Core Web Vitals. Google’s three loading and responsiveness measurements.
• Schema markup. Another name for structured data.
• Render. Google running the page’s code to see the finished result, as a browser would. Content that only appears after scripts run depends on this succeeding.

How to tell whether the technical side is healthy

Four checks, all free, and none require a developer to interpret.

• Search Console Pages report. Are the pages you care about indexed, and what reason is given for the ones that are not.
• URL inspection on a specific important page, which shows exactly how Google crawled and rendered it.
• Your own phone. Load the three most important pages on mobile data and watch what happens.
• A crawl of your own site with any standard crawling tool, which surfaces broken links, redirect chains and missing titles in one pass.

If those four are clean, the technical side is not what is holding you back, and the answer lies in on-page work or in off-page reputation instead. That is worth knowing, because technical work is where budgets often go by default.