Handling pagination and faceted URLs during migration | Lillian Purge

Handling pagination and faceted URLs during migration

I have been involved in more site migrations than I can comfortably count, and if there is one area that consistently causes hidden SEO damage, ranking volatility, and post migration panic, it is pagination and faceted URLs. In my opinion, this is one of the least understood and most mishandled aspects of technical SEO during a migration, especially on ecommerce, directory, property, education, and large content sites.

Most people focus heavily on core page redirects, templates, and design changes, but pagination and faceted URLs quietly sit underneath everything. When handled well, they support crawl efficiency, relevance, and scale. When handled badly, they create index bloat, duplicate content, lost equity, and long term instability that is very difficult to diagnose after the fact.

This article explains how to handle pagination and faceted URLs during a migration in a practical, experience led way. It is written for people who need to make decisions, not just tick boxes. Everything here is grounded in real world migrations, Google behaviour, and the problems I repeatedly see when pagination and faceting are treated as an afterthought.

Why pagination and faceted URLs are high risk during migrations

Pagination and faceted URLs already sit in a grey area of SEO even on stable sites. During a migration, that risk multiplies.

From experience, migrations change:

URL structures
Internal linking patterns
Canonical logic
Indexing directives
Crawl paths

Pagination and faceted URLs depend on all of these working together. When one piece changes, unexpected URLs surface, previously controlled parameters explode, or Google starts indexing things you never intended to be visible.

The reason this is so dangerous is simple. These URLs often exist in huge numbers. A single mistake can create thousands or millions of low value URLs overnight.

Once Google starts crawling and indexing them, recovery is slow.

What pagination actually is in SEO terms

Pagination is the splitting of a long list of items across multiple pages.

Common examples include:

Category page page 1, page 2, page 3
Blog archive pages
Search results pages
Product listings

Pagination URLs often look like:

?page=2
/page/2/
?p=3

From experience, pagination is not inherently bad. It is necessary for usability and performance.

The problem is not pagination itself. It is how it is signalled to search engines.

What faceted URLs actually are

Faceted URLs are generated when users filter or sort content.

Common facets include:

Price ranges
Categories
Tags
Colours
Sizes
Locations
Dates
Sort orders

These URLs are usually parameter based, such as:

?colour=blue
?price=low-to-high
?location=london
?size=large

From experience, faceted navigation is essential for users but extremely dangerous for SEO if not controlled.

Faceted URLs can create near infinite URL combinations, most of which have little or no unique search value.

Why migrations expose pagination and faceting issues

On an existing site, pagination and faceted URLs may be partially controlled through legacy rules, robots directives, canonical tags, or simply luck.

During a migration, those controls often change.

From experience, common triggers include:

A new CMS with different default behaviour
Changes in URL parameters
Loss of noindex rules
Changed canonical logic
New internal links exposing facets
Improved crawl efficiency revealing hidden URLs

What was once invisible becomes highly crawlable.

The biggest mistake people make before migrating

The single biggest mistake I see is not auditing pagination and faceted URLs before the migration.

From experience, teams often do not know:

How many paginated URLs exist
Which faceted URLs are indexed
Which parameters Google is crawling
Which URLs drive traffic or equity

Without this knowledge, you cannot make informed decisions during migration.

You end up reacting instead of planning.

Auditing pagination before a migration

Before migrating, you need to understand how pagination behaves on the current site.

From experience, this means:

Identifying all paginated URL patterns
Checking which paginated pages are indexed
Reviewing their traffic and impressions
Understanding canonical behaviour
Reviewing internal linking

Some paginated pages may actually rank and drive traffic. Others may be completely redundant.

Treating all pagination the same is a mistake.

Auditing faceted URLs before a migration

Faceted URLs require even more care.

From experience, you should identify:

Which parameters exist
Which parameters are crawlable
Which parameter combinations are indexed
Which facets drive organic traffic
Which are purely navigational

Tools like Search Console, log files, and crawling software are essential here.

You need to know what Google already values before deciding what to keep, consolidate, or block.

Why “just noindex everything” is rarely the right answer

A common reaction is to decide to noindex all pagination and faceted URLs on the new site.

From experience, this is often too blunt.

Some paginated pages may be important for crawl discovery. Some facets may represent meaningful search intent.

For example, category pages filtered by location or property type may deserve indexation.

Blanket rules often throw away equity unnecessarily.

The goal is control, not elimination.

Pagination handling best practice during migration

Pagination should be handled consistently and deliberately.

From experience, key principles include:

Clear self referencing canonicals on paginated pages
Avoiding canonicalising all pages to page 1
Ensuring paginated pages are internally linked logically
Maintaining pagination structure if URLs change

Google understands pagination. What it dislikes is confusion.

If page 2 canonicals to page 1 incorrectly, you lose signals and crawl paths.

The role of rel next and rel prev today

Historically, rel next and rel prev were recommended.

Google has since stated they no longer use these signals directly.

From experience, that does not mean pagination structure is irrelevant.

Internal linking, canonical tags, and content continuity now matter more.

During a migration, ensure pagination still forms a logical sequence that Google can crawl.

When paginated pages should be indexable

Not all paginated pages need to be indexed, but some should be crawlable.

From experience, page 1 is usually indexable.

Page 2 and beyond may or may not be, depending on:

Content uniqueness
Search demand
Crawl budget
Internal linking importance

For large ecommerce sites, paginated category pages often help Google discover deeper products.

Blocking them entirely can reduce crawl efficiency.

Handling paginated URLs that already rank

If paginated pages already rank or receive impressions, be extremely careful.

From experience, removing or noindexing these pages without consolidation causes ranking loss.

In such cases, options include:

Preserving URL structure
Redirecting to equivalent paginated URLs
Consolidating content carefully

Never assume paginated pages have no value just because they are not landing pages.

Faceted URL handling requires intent decisions

Faceted URLs are not equal.

From experience, the first question is always intent.

Does this facet represent something users actually search for.

For example:

flats for sale in manchester
three bedroom houses in leeds

These are faceted combinations but represent real search demand.

Other combinations like colour, sort order, or internal tags rarely deserve indexation.

During migration, you must decide which facets are SEO relevant and which are not.

Creating an SEO allowlist for facets

One of the safest approaches I use is an allowlist model.

From experience, this means:

Explicitly allowing only certain facet combinations to be indexable
Blocking or noindexing everything else

This prevents accidental index bloat.

The allowlist should be based on real search demand, not internal convenience.

Migration is the ideal time to implement this cleanly.

How faceted URLs explode during migrations

Facet explosion often happens because:

New CMS defaults allow crawlable parameters
Filter links become standard anchor links
Internal linking exposes thousands of combinations
Canonical logic resets

From experience, sites that never had faceted issues suddenly see huge crawl spikes after migration.

This often leads to:

Crawl budget waste
Index bloat
Diluted relevance
Ranking instability

Prevention is far easier than cleanup.

Canonical strategy for faceted URLs

Canonical tags are one of the most misunderstood tools here.

From experience, canonicals should:

Point to the most relevant version of content
Be consistent
Not contradict indexation directives

For faceted URLs that are not meant to rank, canonicalising them to the base category can work.

For SEO relevant facets, they should self canonical.

Mixing these rules inconsistently causes confusion.

Why parameter handling in Search Console is not a migration fix

Search Console parameter handling used to be more prominent.

From experience, it should not be relied on as a primary control method during migrations.

It is advisory, not absolute.

On site controls like internal linking, canonicals, and robots directives are far more reliable.

Parameter handling should be a last layer, not the foundation.

Using robots.txt carefully during migrations

robots.txt is powerful and dangerous.

From experience, blocking faceted URLs in robots.txt can stop crawling but not indexing if URLs are discovered elsewhere.

This often leads to URLs stuck in index with no content.

Using noindex or canonical is usually safer than robots.txt blocks for faceted URLs.

If robots.txt is used, it must be paired with proper canonical strategy.

Why internal linking is the real control lever

Internal linking determines what Google sees as important.

From experience, many faceted URL problems are caused by internal links exposing low value URLs.

During migration, review:

Filter links
Sort links
Pagination links
Footer links

Ensure that only SEO relevant URLs receive prominent internal links.

This alone often reduces crawl waste dramatically.

Handling URL changes for pagination during migration

If pagination URLs change, redirects must be precise.

From experience:

?page=2 to /page/2/ needs explicit mapping
/page/3 to /p/3/ must be tested

Do not rely on wildcard redirects.

Pagination errors are subtle and often missed in QA.

Migrating faceted URLs safely

For faceted URLs that must persist, mapping must be intentional.

From experience:

Old facet URLs should redirect to equivalent new ones
SEO relevant facets must not be orphaned
Non relevant facets should be consolidated

Ignoring old facet URLs often leads to 404 spikes and equity loss.

Crawl budget considerations during and after migration

Large sites often struggle with crawl budget post migration.

From experience, uncontrolled pagination and facets are the main cause.

Google spends time crawling useless URLs instead of important ones.

Managing pagination and facets properly ensures crawl budget is focused where it matters.

This supports faster recovery and stability.

Monitoring pagination and facets after launch

Post migration monitoring is critical.

From experience, you should monitor:

Index coverage reports
Crawl stats
Server logs
New indexed URLs
Impressions by URL pattern

Early detection allows small fixes instead of major cleanups later.

Common pagination and facet migration mistakes

Some of the most common mistakes I see include:

Accidentally noindexing all paginated pages
Canonicalising everything to page 1
Exposing all filter combinations via links
Blocking parameters in robots.txt only
Ignoring existing indexed facet URLs

Each of these can cause long term damage if not corrected quickly.

When to simplify instead of migrate complexity

Sometimes the best decision is simplification.

From experience, migrations are an opportunity to reduce unnecessary complexity.

If certain facets add little user or SEO value, consider removing them entirely.

Simpler structures are easier to manage and more stable long term.

Explaining pagination and facet decisions to stakeholders

These decisions can be hard to explain.

From experience, framing helps.

Explain that:

Not every page should rank
Too many URLs dilute relevance
Search engines need clarity
Users still get full filtering experience

SEO control does not mean reduced functionality.

Pagination and facets in ecommerce migrations

Ecommerce sites are the most affected.

From experience, product categories with multiple filters are the highest risk area.

Product discoverability must be balanced with SEO control.

Testing crawl paths before launch is essential.

Pagination and facets in content sites

Large blogs, news, or education sites also face risks.

From experience, archive pages, tag pages, and date filters often create problems.

Decide which of these should be indexed and which should not before migrating.

AI search and faceted URLs

AI driven search favours clarity and strong canonical signals.

From experience, sites with clean URL hierarchies perform better in AI summaries.

Excessive faceted URLs confuse entity understanding.

Future proofing means cleaning this up now.

The mindset required for handling this properly

The biggest mindset shift is this.

Pagination and faceted URLs are not technical details to be left to developers.

They are strategic SEO decisions that affect visibility, authority, and stability.

From experience, treating them with intent and care makes migrations far safer.

Bringing it all together

Handling pagination and faceted URLs during migration is about control, clarity, and intention.

From experience, most migration disasters do not come from homepage redirects or design changes. They come from uncontrolled URL generation that quietly undermines the site.

Audit before you move. Decide what matters. Preserve what has value. Control what does not.

Google rewards sites that make its job easier.

Users reward sites that feel organised and relevant.

When pagination and faceted URLs are handled properly during migration, recovery is faster, rankings are more stable, and future growth becomes easier rather than harder.