Technical SEO consultant in Germany for sites with many pages

Why a site with many pages loses visibility

A site with many pages loses visibility when search engines crawl its pages and leave them out of the index, or index the wrong version. The cause sits in the system that builds the pages, so the fix belongs there too.

A shop, a portal or a database with public pages builds its pages from records and templates. One template can produce thousands of pages, and a fault in it repeats on each of them. Filters and sort orders add addresses that show the same products again. A crawler spends its visits on those, and new pages wait longer.

Google wrote its crawl budget guide for sites with more than a million pages that change weekly, and for sites with more than 10,000 pages that change daily (Google, crawl budget guide). A site below that size still loses pages to duplicates and wrong canonicals.

An SEO tool reports the symptom, such as duplicate titles or pages without an index entry. Marketing reads the report, and the fix waits in the IT backlog.

Where I look: database, templates, server

I am an IT expert for data platforms. I read the data model and the server configuration, and I change the part that produces the fault.

The canonical address of a page is a decision about data. Someone has to say which record is the original and which address shows it. Hreflang needs a table that knows which record exists in which language. Without that table, the tags point to pages that do not exist.

Structured data should come from the same fields as the visible text. When the price in the markup differs from the price on the page, two parts of the code read two different sources.

A sitemap for a large site is a query over the indexable records, with the date each one last changed. One sitemap file holds at most 50,000 addresses, and a sitemap index lists the files above that (sitemaps.org).

Technical SEO findings, with their cause and fix

These are the findings I check on a site with many pages. Each row names where the fault comes from and where I fix it.

Finding	Cause in the system	Fix at the source
Many addresses show the same products	Filter and sort parameters create new URLs	Parameter pages name the unfiltered page as canonical and stay out of the sitemap
Canonical points to a redirect or a dead page	The template builds it from the requested URL or an old slug	The template reads the main address stored with the record
Hreflang tags without a return link	Language versions are stored with no link between them	A translation table joins the records, and the template reads it
Structured data contradicts the page	Markup and page read different fields or caches	Both read the same fields from one query
Sitemap lists redirected, blocked or empty pages	A plugin or a separate script writes it without the indexing rules	The sitemap comes from the query that decides indexing
Thin pages from half-empty records	The template renders a page for each record	A rule in the data: a page goes live only when its record has the fields a searcher needs
Pages crawled and left out of the index	Pages from one template differ in a name only	Merge them, or add data that sets each page apart
Redirect chains	Rules from several relaunches point to each other	One rule per old address, straight to the final one, in the server configuration
Text appears only after a script runs	Listings load by JavaScript after the page arrives	The server delivers the text in the HTML
Slow pages on large lists	Queries without an index, and pages built on each request	Database index, cache or a search index, measured with Lighthouse before and after

Programmatic SEO: pages from your data

Programmatic SEO builds pages from a dataset, one page per record or per combination of fields. It works when each page answers a search with data that no other page shows in one place.

Google’s spam policies name scaled content abuse: many pages made to manipulate rankings without adding value for the reader (Google, spam policies). The same policies list pages per city that funnel visitors to one page as doorways.

I programmed the websites and databases of a global real estate database on major construction projects. I also put Elasticsearch in front of a real estate database with millions of records, and its users reached them within milliseconds. Before a set of generated pages goes live, we decide together which records carry enough data for a page.

Who I am

I am Michael Wutzke, an IT expert for data platforms in Frankfurt. I have spent more than twenty years from code to CIO in finance, e-commerce and real estate, with cloud platforms and data centers. Today AI agents speed up how I build and transform data platforms.

As editor in chief of an information portal on construction projects I reached more than one million readers a year by 2024. For an insurance group I built web portals, hosted them on AWS in Frankfurt and London, and managed more than 100 top-level domains from 2016 to 2021. In a current client project I optimize the website for search and for AI agents next to the transformation of the platform.

This site is a static Astro build, and the server delivers plain HTML. I moved it off WordPress with Claude as coding agent. I hold the Google Mobile Sites certification.