Technical SEO

Technical SEO is the engineering layer of search. If content is “what you say,” technical SEO is “whether Google can find it, load it, render it, crawl it efficiently, and understand it correctly.” It is the part of SEO that sits closest to development, infrastructure, browser behavior and search engine mechanics.

This is where my development background pays off. I go past the meta tags where most agencies stop, down to render paths, crawl budget, server responses, log files, JavaScript execution, indexation rules, schema, internal linking and performance bottlenecks. A title tag can be perfect and the copy can be strong, but if Google is wasting crawl budget on junk URLs, struggling to render your main content, choosing the wrong canonical, or seeing a slower version of the page than users do, the site is operating under a technical ceiling.

This page is the technical deep-dive of my SEO service. The core point is simple: a site’s rankings are usually capped not by content but by invisible technical ceilings. Lift them, and the content can breathe. Leave them in place, and every content, link-building or conversion effort has to fight against the site itself.

Technical SEO is not “making a site look clean.” It is making sure the right pages are crawlable, indexable, fast, internally discoverable, correctly rendered, semantically clear and technically consistent. It is the work that turns a website from a collection of pages into a search-engine-readable system.

Core Web Vitals: user experience, measured

Google measures three metrics with real-user data (CrUX). That distinction matters: these are not just abstract performance scores in a testing tool. They are based on how real people experience your site in the field, across real devices, networks and browsers.

• LCP (Largest Contentful Paint) — time until the largest content appears. Target < 2.5s. Usual culprits: an unoptimized hero image, render-blocking CSS/JS, slow server response (TTFB), web-font loading. Fixes: inline critical CSS, serve images in modern formats (AVIF/WebP) at the right size, preload fonts.
• CLS (Cumulative Layout Shift) — layout shifting during load. Target < 0.1. Culprits: images/iframes without dimensions, late-injected ads/banners, late fonts (FOIT/FOUT). Fixes: width/height on all media, reserved space, a font-display strategy.
• INP (Interaction to Next Paint) — interaction response delay (replaced FID). Target < 200ms. Culprit: heavy JavaScript blocking the main thread. Fixes: reduce, split and defer JS; remove unnecessary hydration.

The practical meaning is straightforward. If the largest element on a page is a hero image, but that image is too large, not preloaded, served in the wrong format or delayed behind render-blocking code, users wait longer to see the page’s main value. If images, embeds, banners or cookie notices appear without reserved space, the page jumps while the user is trying to read or tap. If a framework ships a large JavaScript bundle and blocks the main thread, the page may look loaded but still feel broken when the user interacts with it.

That is why I diagnose these with real-user data, not just Lighthouse’s synthetic score — because the lab can be green while the field is red. Lighthouse is useful, but it is a controlled test. Real users may be on slower phones, weaker connections, different locations, or pages with third-party scripts that behave inconsistently. A site can pass a one-off lab run and still fail where it matters: in the data Google uses and in the experience users actually have.

The aim here is not cosmetic “speed optimization.” It is to remove the concrete technical reasons a page loads late, shifts unexpectedly or responds slowly. That might mean image work, a change to the render strategy, or removing JavaScript that should never have been shipped to the client in the first place.

Crawl budget and log analysis

Google’s bot spends limited time on your site. Is it spending that time on your money pages, or on infinite filter combinations, parameter URLs and pointless redirect chains? I see this in the server log files — what Googlebot actually crawls, and how often.

This is one of the areas where technical SEO separates itself from surface-level audits. A crawler can show what could be crawled. Search Console can show part of what Google reports. But server log files show the requests that actually happened. They show which URLs Googlebot visits, how frequently it returns, which status codes it receives, whether it keeps hitting redirects, whether it is wasting time on non-indexable pages, and whether important URLs are being crawled rarely or not at all.

On most sites a large share of crawl budget is wasted on junk URLs; cleaning that up (robots, parameter handling, canonicals) gets new and updated content indexed faster. This is especially important for large websites, e-commerce stores, marketplaces, directories, publishers and any site where filters, sorting, tracking parameters, pagination or faceted navigation can create near-infinite URL combinations.

For example, a product category might generate URLs for color, size, price order, availability, session IDs and tracking parameters. Individually they look harmless. At scale, they can create thousands of low-value variations competing for crawl attention. Googlebot may spend time requesting combinations that should never rank, while new products, updated categories or commercial landing pages wait longer to be discovered and refreshed.

The fix is not always “block everything in robots.txt.” That can create its own problems if Google cannot see signals it needs to consolidate. The right answer depends on the URL type: some should be canonicalized, some should be noindexed, some should be blocked, some should be removed from internal links, and some should be allowed because they serve real search demand. Technical SEO is knowing the difference.

Rendering: does Google actually see your content?

This is the most commonly missed issue on modern sites. Content can be produced three ways:

• SSG / SSR (rendered on the server) — the bot sees ready HTML. The safest path.
• CSR (in the browser with JavaScript) — the bot first sees an empty shell, then (in a second wave) runs the JS and tries to see the content. Delay + risk of errors.

Google runs JavaScript, but it’s neither guaranteed nor free. If critical content and links depend on client-side rendering, indexing problems follow. In an audit I check what Googlebot actually sees (rendered HTML) and, if needed, move it to SSR/SSG so the content that matters arrives in the initial HTML.

The important question is not “does the page work in my browser?” The question is “what is present in the initial HTML, what appears only after JavaScript runs, and what does Googlebot actually get?” A user with a powerful device may see the page normally. Google may still have to queue rendering, execute scripts later, fail on a JavaScript error, miss internal links, or delay understanding of the page.

This affects more than text. Navigation links, product listings, pagination, reviews, FAQs, related articles and structured content can all be hidden behind client-side rendering. If those elements are not available in the initial HTML or reliably rendered for Google, they may not pass internal link equity, may not be indexed correctly, or may be treated as less stable than server-rendered content.

Modern frameworks can be excellent when used well. The problem is not React, Vue, Next, Nuxt or any specific stack. The problem is choosing a rendering model without considering search. For pages that need to rank, the safest baseline is usually server-rendered or statically generated HTML, with JavaScript used only where it adds genuine interaction. Search pages should not depend on unnecessary hydration just to display content that could have been sent as HTML.

Indexing control and duplicate content

Indexing control is about telling search engines what should be discovered, what should be indexed, and which URL represents the authoritative version of a page. Small mistakes here can suppress important pages or cause Google to split signals across duplicates.

• robots.txt / meta robots / X-Robots-Tag — what gets crawled and indexed.
• Canonical — which version of similar content is the master. A wrong canonical hides the right page.
• Duplicate content — parameters, http/https, www/non-www, trailing slash, pagination. Must consolidate to one correct version.
• Orphan pages — pages with no internal links are hard for the bot to find.

Each of these controls has a different job. robots.txt controls crawling, not indexation in the same way a noindex directive does. A meta robots tag can keep a page out of the index, but Google needs to crawl the page to see it. An X-Robots-Tag can apply indexation rules at the HTTP header level, which is useful for non-HTML files or site-wide patterns. Canonical tags consolidate similar URLs, but they are signals, not absolute commands.

This is where many technical problems become invisible. A page may be live, linked in a menu and available to users, but carry a canonical tag pointing somewhere else. A staging rule may accidentally remain in place. HTTP and HTTPS versions may both resolve. The same content may be accessible with and without a trailing slash. Pagination may be implemented in a way that hides deeper items. Parameter URLs may compete with clean URLs. None of this necessarily breaks the website for users, but it can make search engines uncertain.

Duplicate content is often a URL consistency issue rather than a “content quality” one. If five technical versions of the same page exist, Google has to decide which one matters. If internal links point inconsistently to different versions, authority is diluted. If canonicals contradict internal links or sitemap URLs, the site sends mixed signals. Technical SEO removes that ambiguity.

Orphan pages are another common ceiling. A page may exist in the CMS and even appear in an XML sitemap, but if no internal links point to it, Google has fewer signals that it matters. Important pages should not rely only on sitemaps. They should sit inside the site architecture, connected through relevant navigation, hubs, breadcrumbs, contextual links and related pages.

Structured data (schema.org)

Structured data tells the search engine what a page is in machine language: an article, a product, an FAQ, a local business. Correct schema (JSON-LD) opens the door to both rich results (stars, price, FAQ expanders) and being cited by AI search. On a service site, that typically means Person, ProfessionalService, Service, BreadcrumbList and FAQPage markup, each describing a real part of the page.

Schema does not replace content. It clarifies it. It helps search engines understand entities, relationships and page purpose in a structured format instead of relying only on visible text and layout. For a service page, structured data can identify the service, the provider, the breadcrumbs, the FAQ content and the professional context. For a product page, it can clarify product name, pricing, availability, reviews and other attributes when they are present and eligible.

The key word is “correct.” Structured data should match the visible content on the page. It should be valid, specific and appropriate to the page type. Adding schema that does not reflect the page, stuffing irrelevant properties, or marking up content that users cannot see can create problems instead of benefits.

Good structured data makes the page easier to parse. It gives search engines a cleaner machine-readable layer on top of the human-readable page. As search shifts toward richer SERP features and answer-based experiences, that clarity becomes more important, not less.

Site architecture and internal linking

A flat, logical hierarchy helps both users and the bot. Important pages should be close to the homepage (few clicks); related pages should link to one another (hub & spoke). Internal linking flows authority within the site and guides the bot to the right pages.

Site architecture is how you decide what matters. If your most important commercial pages are buried five clicks deep, while thin blog tags or low-value archives are linked everywhere, the site is telling search engines the wrong story. If related pages do not link to each other, Google has less context for how topics connect. If every page links to every other page without structure, the signals become noisy.

A strong architecture usually has clear hubs and spokes. The hub explains the main topic or service. The spokes go deeper into specific subtopics. They link back to the hub and to each other where relevant. This creates a topical cluster that is easier for users to navigate and easier for Google to understand.

Internal links also affect crawl discovery. Google follows links. If a page is important, it should be linked from relevant places using descriptive anchor text. Breadcrumbs, related service sections, contextual links inside copy, navigation links and HTML sitemaps can all help when used deliberately. The point is not to add links randomly. The point is to make the site’s priorities obvious.

Internationalization: hreflang

On multilingual projects, hreflang tags tell Google which page is for which language/region. A misconfigured hreflang causes the wrong-language page to rank, or the two to cannibalize each other. Correct setup: reciprocal tags + x-default.

International SEO issues are often subtle. The pages may look correct to users, and each language version may be indexed, but Google may still show the wrong version in the wrong market. A Dutch user may see the English page. An English page and a translated page may compete against each other. Regional variants may be treated as duplicates instead of alternates.

hreflang solves this by creating a clear map of equivalent pages across languages or regions. But the map must be complete and consistent. If page A points to page B, page B must point back to page A. Each language version should reference itself and its alternates. x-default helps define the fallback page for users who do not match a specific language or region.

This is also where technical consistency matters. Canonicals and hreflang must not contradict each other. If the English page canonicalizes to the Dutch page, but the hreflang says they are alternates, the signals conflict. If translated pages are missing from the sitemap, internally hidden, or blocked, the hreflang implementation will not rescue them. Internationalization is a system, not a tag.

Monitoring: verify the fix

Technical SEO isn’t “set and forget.” With Search Console (Crawl Stats, Index Coverage, the CWV report) and real-user data, I verify the fix worked — in the field, not in theory.

That verification step is critical. A technical recommendation is not finished when it is written in an audit. It is finished when it is implemented correctly, deployed safely, crawled by Google, reflected in indexation behavior, and visible in real-world performance data. Otherwise, it is only a document.

Search Console helps show whether Google is crawling more efficiently, whether excluded pages are excluded for the right reasons, whether valid pages are increasing, whether Core Web Vitals have improved for real users, and whether crawl responses are healthy. Crawl Stats can reveal changes in crawl volume, response codes, file types and server behavior. Index Coverage can show whether pages are discovered, crawled, indexed, duplicated or blocked. Real-user data confirms whether performance improvements are actually reaching visitors.

Monitoring also catches regressions. A CMS update can change canonicals. A redesign can remove internal links. A tag manager change can add blocking scripts. A developer can accidentally noindex a template. A migration can create redirect chains. Technical SEO needs follow-up because websites are living systems, and living systems drift.

The advantage of a development-led technical SEO process is that recommendations are grounded in how websites are actually built. I am not just pointing at symptoms. I am looking at the rendering model, server behavior, template logic, crawl paths, HTML output, JavaScript weight, indexation rules and data signals underneath them.

---

With a solid technical foundation, content and authority work pays off much faster. The right pages get crawled. The right versions get indexed. The content is visible in the HTML. The site loads and responds better for real users. Internal links guide authority instead of wasting it. Schema gives search engines a clearer machine-readable layer. International pages stop competing with each other. And technical ceilings stop quietly limiting the upside of everything else.

On an online store, with its own technical challenges: e-commerce SEO. If you think your site needs a technical audit, get in touch.