Google Indexed 304 More Pages. I Still Almost Fixed the Wrong Number.

On July 28, 2026, Google Search Console gave me two numbers that seemed to contradict each other.

The first looked like a win: Wimemo had jumped to 350 indexed pages.

The second looked like a new backlog: 85 pages were still not indexed.

My first instinct was embarrassingly predictable. I wanted to treat 85 as the problem to solve.

That would have been the wrong number.

Two and a half weeks earlier, on July 10, the same property showed only 46 indexed pages. The multilingual rollout, canonical cleanup, and sitemap split had clearly worked. Google had added 304 indexed pages. If I reacted to the new report as if the site were broken, I would be optimizing against a headline that did not actually describe the inventory I meant to publish.

This was the real problem:

I was about to confuse Search Console's All known pages view with my live canonical site.

That mistake is easy to make on a small product site, especially when you are also the founder, developer, release manager, and accidental SEO analyst. A chart gives you one scary total, and the brain immediately turns it into an action list.

But Google was not describing my intended website. It was describing every URL it knew about.

Those are not the same thing.

The Report Was Bigger Than The Site I Actually Wanted

Wimemo is an iPhone app, but the website has become a multilingual product surface: English plus Simplified Chinese, Traditional Chinese, Japanese, and Korean. That means the URL graph includes canonical articles, localized pages, retired aliases, language redirects, utilities, download resources, and support documents.

By July 28, the production sitemap index contained 344 canonical URLs: 67 each for English, Simplified Chinese, Traditional Chinese, Japanese, and Korean, plus 9 standalone pages.

That was the inventory I was actually willing to defend.

Search Console's All known pages report, by contrast, covered 435 URLs. Its 85 exclusions included 21 alternate canonicals, 16 redirects, 4 intentional noindex pages, 24 discovered pages, 16 crawled-but-not-indexed pages, and 4 cases where Google chose a different canonical.

Once I saw the classes, the fear drained out of the number.

Forty-one of the 85 exclusions were normal outcomes of canonicalization, redirects, or intentional utility-page handling. They were not failures. They were evidence that the site had duplicate-control behavior at all.

Google's own Page indexing report docs make this distinction explicit: Not indexed is not automatically bad, and the summary page can be filtered between All known pages, submitted pages, or a specific sitemap. Its canonicalization guidance says the same thing from another angle: redirects, rel="canonical", and sitemap inclusion are signals, not guarantees, and Google may choose a different representative URL than the one you prefer.

That means an exclusion count is not a to-do list until you map it back to your intended canonical set.

The Productive Question Was Not “Why 85?”

The productive question was this:

Which excluded URLs are canonical pages that deserve action, and which are side effects of the site's routing history?

That changed the workflow immediately.

Instead of chasing every exclusion, I carved the report into three buckets.

1. Expected Exclusions

Alternate canonicals, permanent redirects, and explicit noindex resources stay excluded unless they appear in a canonical sitemap or a current internal link unexpectedly.

These are not “problems to zero out.” They are control surfaces. If a site has localized aliases, retired routes, or operational downloads, some exclusions are evidence that the boundaries are working.

2. Actionable Canonical Mismatches

The four Duplicate, Google chose different canonical than user examples looked serious until I checked the actual URLs.

Three were old ?lang= article URLs crawled before static locale routing shipped. In production they already returned one-hop permanent redirects to the correct Chinese or Japanese paths, and each destination self-canonicalized. Those examples were stale history, not active defects.

The fourth was real.

/essays/the-clever-heuristic.html was a valid self-canonical founder essay, but it had been omitted from sitemap-pages.xml. The Medium copy had stronger discovery signals than the Wimemo original, so Google chose a different canonical than I wanted.

That was not a content-writing problem. It was a publication invariant problem.

The fix was to make every essays/*.html page automatically appear in the canonical sitemap, fail the SEO gate if any essay was missing, strengthen contextual links to the essay, and list it in llms.txt as first-party engineering evidence.

In other words: stop debugging one URL by hand and restore the invariant that canonical originals must be impossible to forget.

3. Crawled But Not Indexed URLs That Needed Classification

The 16 Crawled - currently not indexed examples were the most tempting place to waste time, because this label feels like a technical failure even when it usually is not.

Once exported, they split into five classes: 9 Local Connector installers, manifests, binaries, or checksum files; 4 legacy runtime-language aliases; 1 public legal page; 1 Traditional Chinese article to keep observing; and 1 English article that overlapped an existing privacy cluster.

That classification made the right actions obvious:

• download resources were given X-Robots-Tag: noindex
• legacy aliases kept their redirect and canonical behavior
• the legal page stayed live
• the new Traditional Chinese article was left alone for observation
• the overlapping English article was consolidated into a stronger privacy page

The important part is what I did not do.

I did not start resubmitting individual pages. I did not publish extra filler content to inflate the indexed total. I did not expand the sitemap just because the report had room for more URLs.

Once the canonical inventory is clear, “more pages” stops being the objective.

The Durable System Changed, Not Just The Count

This incident changed my process more than my content.

I now treat the sitemap inventory as a production contract:

1. Keep a counted canonical URL set and know what belongs in it.
2. Classify Search Console exclusions by URL class before touching content.
3. Distinguish “Google knows this URL” from “this URL deserves to rank.”
4. Add gates for publication invariants, not just one-off cleanup.
5. Consolidate overlapping pages instead of hoarding weak ones.

That last point matters more than it sounds.

Independent developers often inherit bad SEO instincts from growth content: more pages, more keywords, more submissions, more requests for indexing. But if your site is still small, the harder problem is usually not discovery. It is signal clarity.

On July 28, Wimemo did not need more random inventory. It needed a tighter canonical set, clearer internal evidence for first-party essays, and explicit boundaries around files that were never meant to be search landing pages.

The best fix of the day was not “grow faster.” It was “stop counting the wrong thing.”

What I Would Reuse On Any Small Multilingual Site

If I were handing this lesson to another solo founder, it would be this:

Your real denominator is the live canonical inventory you are prepared to maintain, not the largest URL count a dashboard can show you.

That does not mean ignoring Search Console. It means reading it as a diagnostic surface instead of a scoreboard.

A useful sequence is:

1. count the canonical URLs you actually mean to publish
2. verify that every one of them is in the sitemap and returns the right status
3. classify exclusions by class before touching content
4. fix invariant breaks first
5. only then make content judgments page by page

There are still limitations.

Search Console data lags reality. Canonical examples can be stale. Google may still choose a different representative URL even after you stack redirects, canonical tags, and sitemap inclusion. And Crawled - currently not indexed often requires editorial judgment rather than a technical patch, which means a developer cannot automate the whole answer.

That is fine.

The point is not to eliminate judgment. The point is to spend it on the right URLs.

I build Wimemo as a one-person company, so every misleading dashboard number has an outsized cost. If I let a scary aggregate dictate the plan, I can easily burn a week cleaning history instead of improving the current product surface.

The thesis I am carrying forward is simple:

In Search Console, the biggest number is often the least useful one. Define your canonical inventory first, then decide which exclusions are actual problems.

I write these from building Wimemo, an AI-native travel memory app. If you want the product context behind the engineering decisions, you can read more about Wimemo here.