How to Fix Declining Indexation: URLs, Canonicals and Sitemaps

When indexed page counts fall, do not begin by submitting every URL again. First identify which pages disappeared and whether parameter URLs, redirects, canonical tags, language variants and the sitemap send conflicting signals. Fixing these inconsistencies can remove technical obstacles; it does not guarantee that Google will index every page or restore rankings.

This case covers a bilingual Next.js and WordPress content website. The implementation and acceptance records are dated September 23, 2026. Counts below describe that release snapshot, before publication of this article, rather than a permanently fixed site inventory.

Why can a working website still lose indexed pages?

An HTTP 200 response confirms that a resource is available. It does not establish that the page is unique, useful, indexable or Google’s preferred version. Crawlers also encounter redirects, internal links, canonical declarations, alternate-language references and sitemap entries.

If several addresses expose the same content, Google must select a representative URL. A site’s declared canonical is a signal, not an instruction that overrides every other signal. Conflicting destinations make the intended structure harder to interpret.

The investigation identified several interacting code paths: note listings exposed query-string pagination; paginated responses declared their own canonicals; internal navigation continued distributing parameter addresses; some language-neutral content aliases used temporary application-level redirects; and build checks did not cover all alias redirect rules.

Query parameters and self-canonical pagination are not inherently wrong. The issue was inconsistent URL governance and multiple entry patterns. Nor does a declining indexed-page count prove this was the only cause: intentional duplicate consolidation can reduce counts without harming valuable pages. Content quality, accessibility and the affected URL groups must be checked separately.

Step 1: Separate content URLs from functional URLs

Classify the affected addresses before applying redirects or indexing restrictions.

URL type	Indexing decision	Treatment
Original articles, service and product pages	Intended for search	Return 200, declare the preferred URL and include it in the sitemap
Retired article aliases	Not separate search pages	Redirect once to the equivalent permanent destination
Tracking-only variants	Not separate content	Consolidate without losing required campaign attribution
Internal search, login and registration	Usually excluded	Use suitable noindex rules and omit from the sitemap
Paginated content listings	Depends on purpose	Keep accessible navigation; decide indexability independently
Nonexistent page numbers	No content to index	Return a genuine 404

Do not block every address containing a question mark. A tracking parameter may leave the content unchanged, while a page number can select an entirely different set of articles. Filtering may also produce a useful landing page or a near-duplicate; it needs a separate decision.

Step 2: Consolidate pagination under one stable URL pattern

This release moved note pagination from query strings to paths:

/zh/notes/?page=2
/en/notes/?page=2&utm_source=campaign

The corresponding destinations became:

/zh/notes/page/2/
/en/notes/page/2/

The old listing URLs received single-hop 301 redirects. Requests carrying only tracking parameters returned to the clean listing homepage:

/en/notes/?page=2              -> 301 /en/notes/page/2/
/zh/notes/?page=2&utm_source=x -> 301 /zh/notes/page/2/
/en/notes/?utm_source=x        -> 301 /en/notes/

Internal pagination links were changed at the same time. Otherwise, each crawl would continue discovering the retired format even though redirects existed.

The benefit is consistency, not an intrinsic ranking advantage of paths over query strings. Valid query-string pagination can remain a sound implementation. Avoid migrating it merely to make URLs look cleaner. Before stripping tracking parameters, confirm how analytics records attribution; a redirect can remove information before client-side tracking sees it.

Step 3: Choose pagination indexability without sacrificing discovery

The site’s selected configuration returns 200 for valid paginated listings, declares a self-referencing canonical and corresponding language alternates, applies noindex, follow, and excludes the listings from the sitemap. Individual articles remain in the sitemap.

This is a site-specific decision, not a rule that every pagination page should be excluded. Pages in a sequence contain different items and should not all canonicalize to page one. Indexable pagination may be appropriate when it supports a useful archive or category experience.

Noindex controls eligibility for search results; it is not a robots.txt crawl block. However, follow does not guarantee that a search engine will keep revisiting an excluded page or discovering its links indefinitely. Important older articles need additional crawlable links from relevant indexable hubs and contextual pages, plus accurate sitemap entries. Do not make a noindexed listing their only discovery route.

Language annotations on an excluded listing also do not turn it into an eligible search landing page. The important language checks concern the indexable article URLs: correct language, corresponding alternatives and consistent canonical destinations.

Step 4: Align canonicals, redirects, internal links and the sitemap

A canonical tag alone cannot resolve every routing problem. If internal links promote one address, a redirect points elsewhere and the sitemap lists a third, the site is still sending mixed signals.

The acceptance contract should require:

Internal article links point directly to the preferred address.
Retired equivalent URLs permanently redirect without unnecessary chains.
Preferred indexable pages return 200 and declare the intended canonical.
Language variants refer to the matching versions, not unrelated pages.
Sitemap entries represent indexable preferred URLs, not redirects or excluded functional pages.
Missing content returns an appropriate error response rather than a successful-looking empty page.

Not every redirect should be permanent. Login or other language-dependent functional entry points may need temporary routing. The permanent-redirect rule in this case applies to content aliases with a stable replacement.

Step 5: Add release checks so the problem does not return

URL inconsistencies often reappear when a template is copied or a new route is introduced. The remediation therefore included a build-time gate rather than relying only on post-release spot checks.

For the static routes covered by the gate, checks inspect canonical metadata, language metadata, sitemap inclusion, functional-page indexing rules and permanent content-alias redirects. A missing requirement makes the production build fail.

Coverage matters. Passing this gate does not prove that every dynamic article or runtime API response is correct. Dynamic content still needs separate API and public-page checks. A test suite should also record the exact routes it covers so a green result is not mistaken for a complete site audit.

What did the release acceptance checks establish?

The September 23 remediation record contains three distinct evidence groups.

Compilation and targeted tests

TypeScript checks passed.
All 50 targeted SEO tests passed.
The production build passed.
The static indexability gate checked 48 routes with no failures.

These are scoped results. The full historical test suite was not entirely green: the record lists 155 passing tests, 39 failures and one skipped test. The remaining failures were recorded separately; this article does not describe the entire repository as passing.

Public URL behavior

Old page-parameter addresses returned a single 301 to their path equivalents. Valid path pagination returned 200 with the expected canonical, language and robots metadata. Page one returned permanently to the listing homepage, invalid query page values resolved to the clean homepage, and nonexistent high page numbers returned a real 404.

Sitemap and language inventory

The release snapshot contained 1,011 sitemap URLs, all unique. Its article inventory contained 454 English and 454 Chinese notes with unique slugs within each language. Checks covered 48 historical alias mappings and 96 language-specific redirect requests with no failures.

These numbers document technical acceptance at that point in time. They are not the number of pages Google indexed, and they will change when content is published or retired. They also do not establish a ranking increase.

Why does Search Console not change immediately after deployment?

Search Console describes Google’s processed observations, not a live mirror of the current application. Google must revisit affected addresses, process redirects and canonical relationships, and refresh its reporting.

Keep three states separate:

Fixed: public responses and page signals meet the technical contract.
Recrawled: there is evidence that Google revisited the relevant URLs after deployment.
Reprocessed: indexing reports reflect the changed URL relationships.

Compare dates before attributing a result to the release. A crawl recorded before deployment cannot confirm the new implementation. Track valuable preferred URLs separately from retired duplicates; successful consolidation may reduce the latter without increasing total indexed counts.

A practical checklist for declining indexation

Export affected URLs and classify them by host, language, directory and parameter purpose.
Check real HTTP responses and complete redirect chains.
Compare the final address with canonical and language metadata.
Confirm that sitemap entries are preferred indexable URLs.
Search internal navigation for retired aliases and unwanted parameter variants.
Review functional pages and filter combinations independently.
Verify that pagination provides actual anchor links, not only click-dependent controls.
Check missing pages for genuine 404 or 410 responses.
Repeat acceptance checks against public URLs after deployment.
Add regression tests and record the subsequent crawl and indexing dates separately.

Frequently asked questions

Do parameter URLs always harm SEO?

No. Their purpose and implementation matter. A valid page parameter can identify distinct content. Problems arise when variants unnecessarily duplicate content or when navigation, canonicals and sitemap entries disagree.

Should every pagination page use noindex?

No. Choose according to the archive’s purpose and discovery architecture. If a listing is excluded, provide other crawlable routes to important articles. Noindex, follow alone is not a permanent discovery guarantee.

Should redirects and canonicals be used together?

Redirect a retired URL to its permanent equivalent. Declare the intended canonical on the destination. When duplicate variants must remain accessible, canonical tags can express a preference, but their signals should agree with internal links and sitemaps.

Can robots.txt replace canonicalization?

No. Blocking crawling may prevent a crawler from reading a page’s canonical or noindex directive. Choose redirects, canonical declarations or indexing controls according to what the URL represents rather than treating robots.txt as a duplicate-merging mechanism.

How long will indexing recovery take?

There is no fixed deadline. Recrawling, processing, content assessment and site conditions vary. Technical acceptance can be dated precisely; indexing and ranking outcomes require later evidence and cannot be guaranteed.

Conclusion

The useful outcome of this release is a more consistent URL system and a regression gate, not a promise of instant recovery. Consolidate retired entrances, align the signals for preferred pages and test the public behavior after deployment. Then monitor which affected URLs Google revisits and how its indexing decisions change, without confusing a completed code fix with a completed search recovery.