Google Indexed 258 of My 406 Pages. The Sitemap Was Never the Problem.

I run Kimusta, a marketplace for local services in Turkey. 406 URLs in the sitemap, every one returning HTTP 200, every one with its own title, description and canonical.

Google indexed 258 of them and left 140 in Discovered — currently not indexed.

The obvious suspects were all clean: no crawl errors, no manual actions, robots.txt correct, sitemap read successfully. So I crawled all 406 URLs myself, with JavaScript disabled, and built a link graph from the raw HTML. The answer was embarrassing.

The homepage linked to four pages

Four links. On a site with 406 pages.

They pointed at /hizmetler, /hizmet-verenler, /iletisim and /yasal — and all four were single-page app shells. Their HTML body was empty; the content arrived after the JavaScript bundle did.

The cause: navigation was mounted by JavaScript

Every server-rendered page started like this:

<header id="commonSiteHeaderMount" class="site-header"></header>
<main id="main"> ...real content... </main>
<footer id="commonSiteFooterMount" class="site-footer"></footer>
<script src="/js/common-site-header.js" defer></script>
<script src="/js/common-site-footer.js" defer></script>

The content was server-rendered. The navigation was not. Menu and footer links — the most important internal links on any site — only existed after the defer scripts ran.

Total internal links across the whole site, as reported by Search Console: 970. That is 2.4 per page.

The catalogue hub had zero links

/hizmetler was the worst case. After the SPA rendered, the page had 323 words and 10 links — all of them menu items. None pointed at any of the 119 service pages it was supposed to list.

The 119 service pages, in turn, received a median of one internal link each.

What I changed

Three server-side changes. No framework, no build step.

1. Render the chrome on the server

One PHP partial returns exactly the markup the JavaScript was already producing:

// lib/site-chrome.php
function k_ust_chrome_header(): string {
    return <<<'HTML'
<header class="site-nav">
  <a class="brand" href="/">KIMUSTA</a>
  <nav class="desktop-nav">
    <a href="/hizmetler">Hizmetler</a>
    <a href="/hizmet-veren-basvurusu">Hizmet Veren Ol</a>
  </nav>
</header>
HTML;
}

The templates print it straight into the mount:

<header id="commonSiteHeaderMount">
  <?= k_ust_chrome_header() ?>
</header>

The client script stays. When it runs it writes the same markup into the same element, so there is no hydration mismatch — it only swaps the session-dependent buttons (login / account).

2. Give the hub a real body

I replaced the /hizmetler shell with a server-rendered A–Z index: 119 services, each linked, grouped by letter, with its parent category as a label. 46 KB of HTML that works with JavaScript switched off.

3. Measure the same thing again

The other 140 pages are a different problem

Those 140 URLs are city pages: 20 categories × 12 cities, generated from one template. Measured across a category, the text overlap is 91%. Only the city name changes.

That is not a crawling bug. It is a content verdict, and no amount of internal linking fixes it.

What I did not do is delete them. They are linked, they return 200, and the catalogue is still growing — a category that has one service today will have ten next quarter, and its city pages become useful on their own. Deleting URLs to please a crawler is how you lose the pages you will want later.

The honest plan is slower: write content that actually differs per city (provider counts, price ranges, seasonal demand) and let the thin ones stay unindexed until they earn it.

Five things I took away

1. Measure crawl depth, not sitemap size. A 406-URL sitemap tells you nothing about what Google can reach by following links.
2. If a component is navigation, render it on the server. Hydration is for interactivity, not for structure.
3. Never ship an empty mount for anything you want indexed. An SPA shell returns 200 and looks fine in a browser, which is exactly why it survives review.
4. Discovered — currently not indexed is a quality signal. 140 pages said it at once; that was the content model talking, not a technical fault.
5. Programmatic pages are cheap to generate and expensive to earn. Generating them took an afternoon. Everything since has been the real work.

The site is at kimusta.com; the catalogue index that replaced the empty shell is at kimusta.com/hizmetler.