By Mehdi HassanEcommerce SEO has a whole discipline around faceted navigation, with millions of filter combinations. Marketing sites have a much smaller version of the same problem. A blog paginates, a changelog grows, a resource library adds filters by topic and format, and campaign links add UTM strings to every URL. Without a few rules, a small site can expose far more crawlable URLs than it has pages.
This guide sets out practical rules for the parameter and pagination patterns common on SaaS and startup sites. It's part of our technical SEO guide for marketing websites.
How should a marketing site handle pagination and URL parameters?
A marketing site should give every piece of content exactly one indexable URL, keep tracking and sorting parameters out of the index with canonicals, let paginated archives be crawled with self-referencing canonicals, and decide deliberately which filtered views deserve their own clean URLs.
The underlying principle is that search engines treat each distinct URL as a potentially separate page. Google has retired Search Console's URL Parameters tool, so you can no longer tell it in a dashboard how to treat each parameter. The decisions now have to live in your site: canonical tags, internal links, the sitemap and, occasionally, robots.txt.
What kinds of URL parameters does a marketing site have?
Marketing sites typically have five kinds of URL parameters: tracking, pagination, filtering, sorting and internal search. Each needs a different rule, because some change the content meaningfully and others don't change it at all.
Parameter type | Example | Changes content? | Should it be indexed? |
|---|---|---|---|
Tracking | ?utm_source=linkedin, ?gclid= | No | Never; canonical to the clean URL |
Pagination | ?page=2 or /page/2 | Yes, different items | Crawlable and self-canonical |
Filter | ?topic=security&format=guide | Yes, a subset | Only if promoted to a clean category path |
Sort | ?sort=newest | Order only | No; canonical to the unsorted URL |
Internal search | ?q=pricing | Yes, unpredictable | No; noindex or disallow |
Locale parameters such as ?lang=de are a sixth case. For multilingual sites, use subdirectories like /de/ instead of parameters; our multilingual website guide and the comparison of subdirectories, subdomains and ccTLDs explain why.
How should you handle URL parameters for SEO?
Handle URL parameters for SEO by making the canonical tag ignore any parameter that doesn't change content, linking internally only to clean URLs and listing only clean URLs in the sitemap. For parameters that do change content, decide case by case whether the result deserves to rank.
- Build canonicals from the path, not the full requested URL, so tracking and sort parameters never end up in a canonical.
- Never use UTM parameters on internal links. They create duplicate URLs and overwrite the original traffic source. Our UTM naming guide covers where UTMs belong.
- Keep parameter URLs out of the sitemap. Only clean, canonical URLs belong there; see our guide to robots.txt and XML sitemaps.
- Use consistent parameter order and casing if parameters must be linked, so the same view doesn't exist at several URLs.
- Disallow crawling only for genuinely endless spaces, such as internal search results or calendar views, and only on paths that also don't need to be indexed.
How should blog and changelog pagination work?
Blog and changelog pagination should use crawlable URLs for each page, a self-referencing canonical on each, and real anchor links between pages. Page 2 is not a duplicate of page 1, so it shouldn't canonicalize there, and it usually doesn't need noindex either.
Google stopped using rel=next and rel=prev as indexing signals, so pagination works through ordinary links. Path-style URLs like /blog/page/2 and parameters like ?page=2 both work; pick one and stay consistent. Deep pagination is the real issue: if a post is only reachable by clicking through ten archive pages, it's weakly linked. Category hubs, related-post modules and contextual links shorten that path; our blog setup guide and internal linking strategy cover how.
Changelogs have a specific choice to make. If each release has its own URL, the paginated index is just navigation and individual entries can rank for feature names. If releases live only on the paginated index, older entries sink deeper over time. For products whose changelog is a meaningful source of feature-name searches, individual entry pages are usually worth it.
How should filtered resource libraries work?
A filtered resource library should turn its most valuable filters into clean, indexable category pages and treat other filter combinations as unindexed views. That way the library ranks for its main topics without exposing every combination of topic, format and industry as a separate URL.
Decide which filtered views people actually search for. Guides about security, templates for onboarding or case studies by industry might each justify a page at a clean path like /resources/security, with a written introduction and its own title. Everything else, such as security plus webinar plus fintech, stays as a parameter view that canonicalizes to the base library or the nearest category page. Make the filter UI work with real links for the promoted categories and parameters for the rest.
Hypothetical example: a SaaS resource library with three filters
For example, suppose a SaaS company's resource library has 90 items filtered by topic (6 options), format (4 options) and industry (5 options). Every combination is a URL, which is over a hundred possible filtered views from 90 items.
The team promotes the six topic filters to clean paths such as /resources/compliance, each with a short intro, a unique title and a place in the navigation. Format and industry stay as parameters. Any URL with a format or industry parameter canonicalizes to its topic page, or to /resources if no topic is set. Only the base library and the six topic pages go in the sitemap.
The result is seven indexable library URLs instead of a hundred-plus near-duplicates, each with a clear reason to rank.
Does infinite scroll or load more hurt SEO?
Infinite scroll and load-more buttons hurt SEO when they're the only way to reach older items, because crawlers don't scroll or click. They're fine when each batch of content also exists at a paginated URL that's linked with a normal anchor tag.
The standard pattern is to back the scroll with paginated URLs: as visitors scroll, the page loads the next batch and can update the URL to ?page=2, while the HTML also contains a plain link to that page for crawlers. Load-more buttons should be real links to the next page that JavaScript enhances, not buttons that only fetch data. If your blog was built as a client-side app, our guide to JavaScript SEO explains why server-rendered pages matter here, and our guide to moving a React SPA to an SEO-friendly site covers the rebuild.
What are the most common parameter and pagination mistakes?
The most common mistakes are canonicals that include tracking parameters, paginated pages that canonicalize to page one, internal links carrying UTMs and filter combinations listed in the sitemap. Each creates duplicates or hides content, and each shows up in Search Console as duplicate or not-indexed statuses.
- Canonicals copied from the full URL, so ?utm_source=x becomes the canonical of its own duplicate.
- All archive pages canonicalized to page one, hiding posts linked only from deeper pages.
- UTM-tagged links in the navigation or banners, creating duplicates and corrupting attribution.
- Every filter combination in the sitemap, telling Google they're all important.
- Sort options as indexable pages, multiplying each archive by the number of sort orders.
- Session or preview IDs in URLs, often from CMS previews or A/B test tools leaking into public links.
If parameter URLs already appear in Search Console as duplicates, our guide to pages not indexed by Google explains each status and how to resolve it.
