Consultancy

Technical SEO consulting

By Miguel Maio · Published July 2026

Your site can be losing rankings and going invisible to ChatGPT without anyone noticing - all it takes is being built in React, Vue or Angular without the technical base handled. Technical SEO is the layer that decides whether search engines (and AI engines) can even read your site. When it fails, the best content in the world won't save you.

The problem that only shows up once traffic has already dropped

Technical SEO disasters are silent. They don't show up in a nice report - they show up in a traffic drop three weeks later, when it's already too late. And there's a new one almost nobody measures: a study by Vercel and Merj, across more than 500 million GPTBot fetches, found not a single JavaScript execution. AI crawlers - GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, Bytespider - read the raw HTML and don't run JavaScript. Only Gemini renders, because it uses Googlebot's infrastructure.

The translation is blunt: a client-side-rendered site can rank on Google (which renders) and be completely invisible in ChatGPT, Perplexity and Claude. The content exists - but only after JavaScript runs, and those bots never get there.

Why it's the fastest-growing need

Never have so many sites been built in JavaScript frameworks, and never have so many bots depended on clean HTML. At the same time, GEO - being cited by AI - rests entirely on the technical base: if the bot can't read it, it won't cite it. Technical SEO stopped being "hygiene" and became what decides whether you exist in search and in AI. It's also why it's one of the best-paid, least commoditizable services: it demands understanding code, server and engine at the same time.

The JavaScript framework black hole

React, Vue, Angular, Next.js, Nuxt, Svelte - all can be excellent for SEO or a disaster, depending on the rendering strategy. The problems I see most:

Pure CSR: content only exists after JavaScript runs. Googlebot may render it (with delay and a limited budget), but AI bots don't - they see an empty page.

Links built in JavaScript: navigation via onclick or routers with no real <a href>. Engines don't follow what isn't a link - whole pages go undiscovered.

Content loaded on interaction: tabs, "load more", infinite scroll. If it only appears after a click, it doesn't exist for the crawler.

Error states returning 200 (soft-404) and hydration errors: error pages with HTTP 200, SPAs serving the same shell for everything, and hydration failures that swap out the rendered content.

Parameter URLs and duplicate routes: filters and states that generate endless variations of the same page, burning crawl budget and creating duplicate content.

SSR, SSG, ISR or CSR: what to choose

The rendering strategy is the decision that weighs most. In short:

If you're already stuck on CSR, dynamic rendering or prerendering is a band-aid - and Google itself advises against it as a long-term solution. The real fix is serving indexable pages with SSR or SSG.

HTTP headers and the server response

Before any content, what the engine sees is the HTTP response - and that's where expensive things get lost. Where I work: correct status codes (200, 301 and 308 for permanent, 302 only for temporary, 404 and 410 for removed), eliminating soft-404s, X-Robots-Tag, canonical and hreflang via header, Vary, Content-Type, cache policy, Link headers, compression (gzip/Brotli) and HSTS. And a case I see more and more: a rate limit (429) too aggressive, blocking AI bots in practice, even with robots.txt allowing them. Finally, redirect chains and loops, which dilute signals and waste crawl.

Crawl, logs and rendering

Google indexes in two waves: first the HTML, then - when there's budget - the rendered content. Understanding this pipeline (crawl → render → index → citation) is what tells you where your site fails. Log file analysis shows what the bots actually do: which pages they crawl, how often, and whether the AI crawlers get there or give up.

Mobile-first crawling

Google indexes the mobile version of your site, not the desktop one. If content, internal links or structured data differ on mobile, it's the poorer version that counts for indexing. Mobile/desktop parity stopped being a recommendation and became a requirement.

Core Web Vitals and technical performance

Core Web Vitals (LCP, INP and CLS) are a page-experience signal, and the weight of JavaScript is often the culprit. A heavy bundle slows loading, interaction and rendering - it penalizes the user and the crawler at once. Here, technical SEO and front-end performance are the same job.

Structured data and the bridge to GEO

Structured data (Schema.org) describes content for machines and defines your entity - the base for being cited by AI. It's where technical SEO meets GEO: without a solid technical base, the CITAR method doesn't even start. A common, costly mistake: marking up what doesn't apply, which can trigger a manual penalty.

AI bots and crawlability

Do you allow GPTBot and PerplexityBot in robots.txt, or block them without noticing? A rate limit (429) too tight cuts them off even with permission. And llms.txt steers them to your best content. AI crawlability is a new discipline - and exactly where technical SEO meets GEO.

SEO migrations

Migrations - of platform, domain or URL structure - are a site's highest-risk moment: done badly, traffic losses can reach 80-90%. It's a discipline of its own, with its own method, so I handle it as a dedicated service. See SEO Migration.

Advanced tools I use

Tools don't do the work - but without them you can't see the problem. The ones I use daily:

Screaming Frog - SEO Spider with JavaScript rendering, before/after crawl comparison for migrations, and the Log File Analyser to see what bots actually do. Google Search Console - URL Inspection to compare raw vs. rendered HTML, Crawl Stats and Coverage. Chrome Developer Tools - network, code coverage, the rendering panel and mobile emulation. Claude Code and Gemini as audit assistants: analyzing templates and code, catching JavaScript problem patterns at scale, and comparing raw vs. rendered HTML. curl and httpstatus.io to inspect HTTP headers and redirect chains. PageSpeed Insights, CrUX and WebPageTest for Core Web Vitals and waterfalls. Rich Results Test for structured data, and log analysis for AI bots.

What's included

• Full technical audit: crawl, indexing, rendering and log files
• JavaScript/SPA diagnosis and rendering strategy (SSR, SSG or ISR)
• HTTP headers, status codes and redirect chains
• Core Web Vitals and technical performance
• Structured data and rich-result eligibility
• AI-bot crawlability (robots.txt, 429, llms.txt)
• Planning and execution of zero-loss migrations

How I work

1. Diagnosis and data collection (GSC, logs, crawl, DevTools)
2. Prioritization by impact - what moves the needle first
3. An action plan with clear, testable tickets for the development team
4. Execution or oversight, with validation at each step
5. Before/after measurement and continuous monitoring

Who it's for (and who it isn't)

It's for sites on JavaScript frameworks, e-commerce and large catalogs, publishers, and any project about to migrate. It isn't for anyone wanting an automated 200-point report with no priorities, or a guaranteed-ranking promise. I work with your development team, not against it - with tickets developers can actually execute and test.

Proof

At Mercedes-Benz I worked directly with Developer, Software Architect, CloudOps and UX teams to improve the technical SEO of international sites at scale - the kind of context where a rendering error or a botched redirect costs a lot. Add to that a decade in WPP Media agencies and teaching. I take a very limited number of clients at a time, to keep real focus.

Sources

• Analysis: AI crawlers do not execute JavaScript (Vercel/Merj data)
• Google - JavaScript SEO basics
• Google - site move with URL changes

See also GEO, Analytics and international SEO.