Technical SEO: Indexing, Core Web Vitals and Duplicate Pages

Technical SEO removes obstacles; commercial SEO competes for queries. If pages aren't indexed or compete with each other as copies, content and links won't work, which is why the technical part usually comes first. On its own, though, it rarely lifts rankings: it gives the site back the ability to rank, and after that you need work on keywords and content.

Because they are the only source that shows where the bot actually went. Search Console gives a summary with a delay, third-party tools give their own estimate, and logs give the facts: which pages the bot reached, how many times, and what response it got. In large catalogs, that's where you see crawl budget being spent on filters instead of products.

Indexing reacts faster than rankings: changes to robots.txt and sitemaps show up within days, duplicates disappear within weeks, and rankings shift over months, and not only because of us. The quickest case to reverse is a drop after a migration: there, redirects often bring back most of the traffic within a few weeks.

Because they measure different things. A lab test runs the page under sterile conditions, while real visitors arrive on different networks and devices. So we look at separate metrics (server response, rendering, responsiveness to input) rather than a single number, and at field data as well as synthetic tests.

They hurt in two ways. First, the search engine decides on its own which copy to show, and it isn't always the one you are promoting. Second, crawling isn't unlimited: if the bot spends it on thousands of filter variants, it reaches new products later. In large catalogs the second problem usually costs more than the first.

Whichever suits you. Some fixes are server-level or template settings, and we'll do them faster. Others your developer will close in a day because they know the code. We write the list so that you can verify every item yourself against a response code, a URL or a number, rather than a line like “optimize indexing”.

It does, but not always the way people expect. The search engine first sees what came from the server, while content that a script renders afterwards is processed later and without guarantee. It's easy to check: we look at the page as the bot receives it and compare it with what a person sees. If the difference is large, that is the cause.

The most accurate place is the Pages report in Search Console: how many URLs are indexed, how many are excluded, and why. Compare that number with how many pages should be in search: if the catalog has five thousand products and the index has eight hundred, there's a problem. The site: operator in search gives only a rough number, so don't rely on it. For an individual page, use the URL Inspection tool: it shows whether the page is indexed and which version Google considers canonical.

Most often the cause is mundane: pages are blocked in robots.txt or by a noindex meta tag left over from development, or they're missing from the sitemap and no link points to them. More complex cases: the server returns an error or responds too slowly, a script renders the content and the bot sees an empty page, or dozens of copies of one page use up the crawl budget. Google may not notice a new site for weeks, and that isn't a fault yet. Which cause is yours shows up in Search Console data and server logs, not in assumptions.

Not as directly as people often think. Core Web Vitals are one of the ranking signals: among pages of equal content quality, the faster one has an edge, but speed won't lift a page with weaker content to the top. Something else is more noticeable: on a large catalog, a slow server response means the bot crawls fewer pages in the same time, and mobile visitors close the tab more often. So we measure server response and real-visitor data rather than the PageSpeed Insights score.