Beyond Content: The Technical SEO Foundations You're Overlooking

Why content alone is no longer enough

Five years ago, publishing a well-structured 1,500-word article was often enough to reach the first page on niche queries. Today, that equation has changed significantly.

Three major developments explain this shift.

Google's algorithmic updates have tightened the criteria. The Helpful Content Update (2022-2023), the E-E-A-T update (Experience, Expertise, Authority, Trustworthiness), and Core Web Vitals as a ranking signal since 2021 have added layers of technical requirements that editorial work alone cannot satisfy. Google no longer ranks simply what answers a query: it ranks what answers a query on a fast, secure, well-structured, technically clean site.

Competition has homogenised on content. In sectors like real estate, law, accounting, or business services in French-speaking Belgium, all serious players now have optimised pages. Differentiation increasingly happens at the technical level: a site at 90/100 PageSpeed regularly beats a competitor at 55/100 when content is comparable.

User experience signals carry more weight. Google measures behavioural signals (bounce rate, time on site, return to results) and progressively integrates them into its assessments. A slow site mechanically generates more bounces, which sends a negative signal even on the best pages.

The practical conclusion for an SEO agency: the technical audit is no longer optional. It is the prerequisite for any effective content strategy. Publishing articles on a technically flawed site is building on sand.

Crawlability and indexing: the foundation you do not check often enough

Before Google can rank a page, it must find it, explore it, and index it. These three steps seem obvious, but they fail more often than is commonly thought, silently, without any visible error message in Analytics.

The robots.txt file: a double-edged sword

The robots.txt file tells Googlebot which parts of the site not to explore. On a poorly configured site, this file can accidentally block strategic pages: category directories, service pages, or even the entire site (a classic mistake after a poorly executed migration).

Minimum check: access yourdomain.com/robots.txt and confirm that your strategic pages are not included in a Disallow directive. On WordPress, also verify that the "Ask search engines not to index this site" setting is not enabled in reading settings, a box sometimes ticked during development and never unticked.

The XML sitemap: your navigation map for Google

A well-maintained XML sitemap tells Google which pages exist and their relative priority. On sites with more than 50 pages, an absent or outdated sitemap forces Googlebot to discover content only via internal links, which increases the indexing delay for new pages.

Essential checkpoints:

• Is the sitemap submitted in Google Search Console?
• Does it include all your strategic pages?
• Does it exclude pages with no SEO value (tags, authors, pagination pages, URL parameters)?
• Is it automatically updated with each new publication?

Crawl budget: critical for high-volume sites

Crawl budget represents the number of pages Googlebot explores on your site per day. On a 20 to 50-page site, this is not an issue. On an e-commerce site, a blog with 500 articles, or a site with URL parameters (filters, sorting, internal search), Googlebot can exhaust its budget on worthless pages and never reach your strategic pages.

Core Web Vitals and performance: the direct ranking impact

Core Web Vitals are the three performance metrics Google uses as a ranking signal since 2021. Since March 2024, Interaction to Next Paint (INP) has replaced First Input Delay (FID) as the third metric. In 2026, the three official metrics are:

• LCP (Largest Contentful Paint): rendering time of the largest visible element. Target: under 2.5 seconds.
• CLS (Cumulative Layout Shift): visual instability of content during loading. Target: under 0.1.
• INP (Interaction to Next Paint): responsiveness to user interactions. Target: under 200 milliseconds.

What these metrics actually measure

LCP measures perceived loading speed: the moment when the user sees the main content of the page. On most sites, LCP is determined by the hero image or main heading. Causes of poor LCP: unoptimised images, slow hosting, JavaScript blocking rendering, no browser cache.

CLS measures layout shifts: elements that move during loading because their dimensions were not defined in advance. An advertisement inserted at the top of the page, an image without width/height attributes, a web font that shifts the layout on display. These shifts harm user experience and send a negative signal to Google.

INP measures responsiveness: the delay between a click or input and the visible response from the interface. On WordPress sites loaded with heavy JavaScript plugins, this delay can exceed 500ms on mobile, well above the acceptable threshold.

The most frequent causes of poor scores on client sites

In audits of Belgian and Swiss agency sites, four causes consistently appear for PageSpeed scores below 60/100 on mobile.

Unoptimised images: high-resolution JPG or PNG images served without compression, without modern formats (WebP, AVIF), and without explicit dimension attributes. This is the number one cause of poor LCP on WordPress.

Blocking third-party JavaScript: poorly configured Google Tag Manager, a chat widget loaded synchronously, a Facebook pixel blocking rendering. These scripts can add 1 to 3 seconds of visible rendering delay.

Low-end shared hosting: a Time to First Byte (TTFB) above 1.5 seconds caps LCP regardless of other optimisations. Hosting is the foundation of performance, and a 3-euro-per-month shared host cannot deliver the same performance as a configured VPS or cloud hosting.

Non-deferred CSS and JS resources: CSS and JavaScript files loaded in a render-blocking manner before the main content is rendered. On WordPress, each plugin can add its own CSS/JS files without consideration for overall performance.

URL architecture and internal linking: structural SEO

A website's architecture is its navigation logic and information organisation. For Google, it is also a signal of thematic relevance and relative authority between pages.

Silo architecture: the approach Google prefers

Silo architecture groups content by theme in coherent directories, with an internal link flow that connects pages within the same silo before pointing to other silos.

Example for a Belgian accounting firm:

• /taxation/ (pillar page) linking to /taxation/vat-belgium/, /taxation/corporate-tax/, /taxation/withholding-tax/
• /company-formation/ (pillar page) linking to /company-formation/srl/, /company-formation/sa/, /company-formation/asbl/

This structure sends Google a clear signal about the site's thematic expertise. It concentrates authority (link equity) on strategic pages via internal linking, and it improves user experience by organising information logically.

URLs: consistency above all

URLs are a secondary but non-negligible SEO signal. An incoherent structure accumulated over years (dates in URLs, numerical identifiers, dynamic parameters) creates canonicalisation problems and dilutes authority between multiple versions of the same page.

Basic rules for SEO-friendly URLs:

• Use hyphens, not underscores: /technical-seo-guide/ not /technical_seo_guide/
• Avoid unnecessary stopwords in URLs: /services/seo-audit/ rather than /our-services/complete-seo-audit/
• Stay consistent in structure: do not mix /blog/article-slug and /news/2024/article-slug
• Implement 301 redirects immediately for any modified URL

Internal linking: the lever SEO agencies underuse

Internal linking is the art of connecting strategic pages to each other with optimised anchors. It is one of the most powerful and least costly SEO levers, as it depends on no external factor.

An internal link does two things: it transfers authority from the source page to the target page, and it tells Google the thematic context of the target page via the anchor text.

Structured data and schema markup: semantic SEO

Structured data (schema markup) is a standardised vocabulary (Schema.org) that you add to HTML code to explicitly tell Google the nature and meaning of your content. It is not a direct ranking factor, but it is one of the most powerful levers for increasing organic click-through rates.

Rich results: what schema markup makes possible

When Google understands the structure of your content through structured data, it can display rich results in search results: review stars, FAQ accordions, clickable breadcrumbs, prices, availability, events. These additional elements increase the visual footprint of your result and improve click-through rates.

According to an Ahrefs study on 600,000 pages (2024), pages with FAQ accordion markup displayed in results record an average CTR 28% higher than the same pages without rich results. On a competitive local market like Brussels, Liege or Geneva, a result with stars and a visible FAQ stands out immediately from the nine other first-page results.

The most useful schema types for your clients' sites

Not all schema types are equal in terms of impact. Here are those that produce the most visible results for the types of sites that French-speaking agencies build most often.

Implementation: JSON-LD, the only sensible choice

There are three ways to integrate schema markup: Microdata (in HTML attributes), RDFa (in HTML attributes) and JSON-LD (in a script block). Google has officially recommended JSON-LD since 2015, for good reasons: it is independent of HTML, easy to read and maintain, and does not risk breaking the layout in case of error.

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Agency Martin",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "10 Law Street",
    "addressLocality": "Brussels",
    "postalCode": "1000",
    "addressCountry": "BE"
  },
  "telephone": "+32-2-000-00-00",
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "09:00",
      "closes": "18:00"
    }
  ]
}

Mobile, HTTPS and security: the prerequisites people forget to check

Some technical fundamentals are so well established that people assume they are in place. They are not always. And when they are missing, they penalise the site disproportionately relative to the time needed to fix them.

Mobile-first indexing: your site is evaluated in its mobile version

Since 2019, Google indexes and evaluates sites primarily via their mobile version. This means that content visible only on desktop, images not served on mobile, and performance measured on mobile are what Google uses for its ranking assessments.

The most frequent mobile errors in client site audits:

Content hidden on mobile: sections unfolded only on desktop via CSS display:none are considered secondary by Google in its mobile-first evaluation. If your key content is hidden on mobile for design reasons, that is an SEO problem.

Text too small and buttons too close: Google Search Console reports mobile usability errors via its "Mobile Usability" report. Text below 16px or clickable elements too close together are signals of poor mobile experience.

Non-adapted images: serving images at 1200px width on a 390px mobile screen weighs unnecessarily on mobile LCP. The srcset attribute or modern format images (WebP, AVIF) allow serving the right size based on device.

HTTPS: non-negotiable, but not always correctly implemented

HTTPS has been a trust factor and ranking signal since 2014. In 2026, a site without HTTPS is rare, but implementation errors are less so.

Security as an E-E-A-T trust signal

Beyond HTTPS, website security contributes to the E-E-A-T assessment (Experience, Expertise, Authority, Trustworthiness) that Google uses to evaluate site quality, particularly in YMYL (Your Money or Your Life) categories: health, finance, law, professional services.

Security elements that contribute to perceived and measured trustworthiness:

• HTTP security headers correctly configured (Content-Security-Policy, X-Frame-Options, X-Content-Type-Options)
• Regular CMS and plugin updates (unpatched WordPress vulnerabilities can lead to a hack that causes Google to deindex the site)
• Privacy policy and legal notices compliant with GDPR, mandatory in Belgium, Switzerland and Luxembourg

How SEO agencies can delegate the technical side without losing control

Most SEO agencies have a clear positioning: they are experts in content strategy, semantic auditing, link building. They are not developers. And that is exactly where the problem lies: technical SEO requires developer skills to be implemented correctly.

The solution is not to become a developer. It is to work with a development partner who understands technical SEO and can implement it correctly, without you having to supervise every line of code.

What you can delegate entirely

Core Web Vitals optimisation, schema markup implementation, server cache configuration, image optimisation, 301 redirect setup, crawl error correction and XML sitemap configuration are pure development tasks. They require access to the server, the code and sometimes the database.

Delegating these tasks to a developer who understands their SEO implications frees you to do what you do better than anyone: strategy, content and client relationships.

What you must keep in hand: the brief and validation

Delegating technical development does not mean losing control over SEO decisions. Your role remains to:

• Define measurable technical objectives (target PageSpeed score, Core Web Vitals metrics, URL structure)
• Validate architectural choices before implementation
• Verify results with your SEO tools (Screaming Frog, Ahrefs, Search Console)
• Ensure technical changes have no side effects on existing content or rankings

The technical brief: your interface with the developer

The quality of the brief you hand to your developer directly determines the quality of the technical implementation. A vague brief produces a vague implementation, and you will spend more time in back-and-forth than in genuine delegation.

An effective technical SEO brief includes:

1. Current measured metrics (current PageSpeed scores, list of Search Console errors, real Core Web Vitals metrics from CrUX)
2. Measurable targets (target mobile PageSpeed score, Search Console errors to zero, etc.)
3. Constraints to respect (do not modify indexed existing URLs, do not remove certain pages)
4. Priorities in order of SEO importance
5. The validation tools you will use to verify the work

Our web project specification template gives you a structured base you can adapt for technical SEO briefs. With this type of document, your development partner can produce a clean technical implementation independently, and you validate with your tools without having to supervise the execution.

Frequently asked questions