SEOProfessional services

Implementing Technical SEO on a Business Site

Indexing, canonicals, structured data and link architecture — the layer everything else depends on.

This is an implementation example, not a client case study. It describes how this work is actually carried out — the method, the sequence and the reasoning. No client is named and no result is claimed, because inventing either would make it worthless as evidence.

Technical SEO layers from crawling through to structured data

Technical SEO is unglamorous and binary. A page blocked from indexing does not rank slightly less — it does not rank. Which makes it the cheapest place to find a large problem, and the most expensive place to have one you do not know about.

Project type
Technical SEO audit and remediation
Sector
Professional services

The challenge

Technical problems are invisible from the front end. A site can look perfect, load quickly and still be losing half its pages to a silent indexing fault. The failure modes give no user-facing symptom at all.

The objective

A site where every page intended for search is crawlable, indexable, canonically unambiguous, internally linked and describing itself accurately in structured data.

Approach

Audit in an order where each layer can invalidate the ones below it, so nothing is fixed twice: indexability, then canonicalisation, then architecture, then on-page, then structured data.

Implementation

1. Indexability

  • Check for unintended noindex, including the WordPress "discourage search engines" setting
  • Verify robots.txt blocks nothing important and does not block CSS, JavaScript or images
  • Confirm the XML sitemap lists exactly the indexable URLs — no redirects, no 404s, no noindexed pages
  • Review the Search Console Pages report and understand every excluded reason

A sitemap generated at build time from a data source that may be unavailable will ship incomplete and look completely normal. This exact failure removed eighteen of thirty-eight URLs from this site's own sitemap for three months. Generating it per request removes the failure mode.

2. Canonicalisation

  • Self-referencing canonical on every indexable page
  • Compare your declared canonical against the one Google chose, via URL Inspection — disagreement is the diagnosis
  • One host. If http, https, www and non-www all return 200, the site exists four times. Single-hop 301s to one canonical origin.
  • Consistent trailing slash behaviour

3. Architecture and internal linking

  • Nothing more than three clicks from the homepage
  • No orphan pages
  • Navigation as real anchors in the server-rendered HTML, not hover-mounted menus
  • Redirect chains collapsed to single hops
  • Internal links pointing at final URLs

4. On-page fundamentals

  • Unique title and description per page, within display limits
  • No duplicated brand suffix from a template colliding with page-level titles
  • One H1, correct heading hierarchy

5. Structured data

  • Generated from the content that renders the page, so the two cannot disagree
  • One entity per concept, referenced by @id, rather than a fresh Person node on every page
  • No review or rating markup without reviews visible on that page

6. Verification

Crawl the whole site and assert the invariants automatically, rather than spot-checking: every URL 200, unique title, unique description, correct canonical, one H1, valid JSON-LD, no duplicate breadcrumb blocks.

Technology

  • Screaming Frog
  • Google Search Console
  • JSON-LD
  • Next.js
  • WordPress

Decisions worth explaining

Automated crawl assertions rather than manual spot checks

Spot checks find what you thought to look for. An assertion run over every URL finds the page you forgot existed, and it can be repeated on every deploy.

Sitemap generated per request

Build-time generation introduces a silent dependency on data being present during the build. When it is not, the sitemap ships short and nothing alerts anyone.

Host canonicalisation handled at both the application and web-server layer

Application redirects only fire for requests that reach the application. Duplicating the rule at the web server catches static assets and keeps working while the app restarts.

What it produces

A site whose technical layer is verified rather than assumed: crawlable, canonically unambiguous, internally connected, and emitting structured data that matches its own content. Whether it then ranks depends on content and competition.

What it teaches

  • Technical SEO failures have no user-facing symptom, which is what makes them expensive.
  • Silent error handling is the most dangerous pattern in this whole area.
  • Four crawlable origins is more common than it sounds and invisible unless you check headers.
  • If a check is not automated, it stops happening after the first month.

Related services

Related guides

Worked examples

All case studies