Technical SEO is now the eligibility layer
for two different indexes.

It matters more, because it became the eligibility layer rather than a ranking tweak. Google requires that a page be indexed and eligible to be shown with a snippet in order to appear in its generative features, on top of the ordinary technical requirements. A page that fails those cannot be retrieved, so it cannot be cited, regardless of how good the content is. That is the same foundation described in our AI SEO practice.

Because Microsoft Copilot answers from the Bing index, not Google's. Bing crawls with its own agent, maintains its own index, and is submitted to through its own webmaster tools. Google's generative AI performance report covers AI Overviews and AI Mode and tells you nothing about Copilot at all. A site can be healthy in Search Console and thin in Bing without anyone noticing, because nobody is looking at the second report. The remedy is unglamorous: verify the site there, submit the sitemap there too, and check that crawl directives aren't excluding non-Google agents. It runs alongside the local SEO work for any business with a physical footprint.

No, and this is the most common technical error we inherit. robots.txt controls whether a URL may be requested. A noindex directive controls whether it may be indexed — but the crawler has to fetch the page to read that directive. Block the page and the instruction is never seen, so the URL can persist in results with no description. Use noindex and leave the page crawlable. Related cleanup usually runs through website maintenance.

No. Google states that structured data is not required for generative AI search and that there is no special schema markup to add for it. Deploy it anyway, for a different and legitimate reason: structured data makes pages eligible for rich results and helps clarify what a page is about. Any proposal that prices schema as an AI unlock is pricing something the issuing authority says does not exist. Markup we deploy is validated as part of the wider SEO program rather than billed separately.

A lab score on one URL is not the same as field performance on the pages people actually use. Core Web Vitals are reported from real-world data, and Google's page experience guidance frames them as one part of a good experience rather than a single dial to turn. We measure on the converting templates — service pages, contact paths, mobile — because that is where speed is a revenue problem before it is a search problem. It usually pairs with conversion rate optimization rather than replacing it.

Potentially. Google's spam policies define scaled content abuse as generating many pages primarily to manipulate rankings rather than to help people, and its AI guidance separately warns against creating separate content for every query variation, noting that a high quantity of pages does not make a site higher quality. Before the policy question, there is a mechanical one: Google picks one canonical per cluster, so the rest are spending crawl budget to be ignored. We consolidate rather than rewriting them one adjective at a time, then rebuild the survivors properly through content writing.

It is a solvable problem and a frequently undiagnosed one. If content depends on JavaScript to appear, it depends on rendering to be indexed — the page looks complete in a browser and can arrive empty at the index. The check is simple and nobody runs it: compare what a crawler receives against what a browser displays, template by template. This is a standing item in any website build or rebuild we take on.

Not with guesses. Google publishes a structured debugging sequence for exactly this, and working it in order separates a technical fault from a seasonal change from a broad ranking movement before anyone proposes a fix. In our experience the technical branch resolves it more often than the market branch, and the specific culprit is usually a deploy that revoked crawl access or introduced a template-level directive — which is why deploy-time checks are part of the ninety-day plan rather than an upsell. Where the cause turns out to be competitive rather than technical, it moves to competitor analysis.

For most sites, less than the conversation suggests. Google's own crawl budget guidance is aimed at large sites, and a few hundred pages rarely has a budget problem. Where it becomes real is faceted navigation and parameters generating URL space faster than anything will work through it. The honest test: if crawl stats show most requests landing on URLs you would not want indexed, there is a problem worth solving. If not, the effort belongs in content or structural work instead.

No, and any agency saying otherwise is telling you something about itself. Google states that indexing and serving are not guaranteed even when every requirement and policy is met. What technical work does reliably is remove the reasons a page cannot be retrieved — and that is a precondition, not a promise. What we commit to is a sequence, a baseline in both indexes, and reporting that separates measured data from observed data. If you want the fuller picture before deciding, start with an A.R.C. Report or a website audit.