Coder Legion - Recent posts tagged pagination

Faceted Navigation and Pagination for Ecommerce SEO

Mon, 31 Aug 2026 15:50:00 +0000

Direct answer: Treat each filter and page-number URL as a product-discovery decision, not as a by-product of the interface. Keep crawlable links to categories, useful curated facets, and paginated product sets. Block or otherwise contain combinations that add no search value. Return a real 404 for empty or nonsensical combinations, and use consistent canonicals, internal links, and sitemap policy for every indexable route.

1. Decide which URL families deserve crawling

Start with an inventory of URL-generating controls: category paths, attributes, price bands, sort orders, pagination, search, tracking, session state, display modes, and campaign parameters. Record the parameter order, possible values, combinations, status behavior, canonical target, internal links, and intended search job.

The objective is not to make every filtered result indexable. It is to make important inventory discoverable while keeping low-value combinations from consuming server and crawl resources. A filtered page can earn a place in search when it represents a stable demand, has enough useful inventory, has distinct context, and can be maintained as a real landing page.

URL family	Default policy	Keep it crawlable when
Category or curated collection	Indexable, self-canonical	It has a clear scope, useful inventory, and durable internal links
Single useful facet	Evaluate deliberately	Demand, inventory, copy, links, and ownership justify a landing page
Sort, tracking, or session state	Contain or exclude	Almost never creates a separate search task
Pagination	Crawlable sequence	Later pages contain products that are not otherwise reachable
Empty or impossible combination	Return 404	There is no matching inventory or valid URL state

Example policy for a shoe catalog

Example URL	Policy	Why
`/shoes/`	Indexable	Primary category page
`/shoes/black/`	Curated and indexable	Stable facet with useful inventory, context, and internal links
`/shoes/?sort=price`	Non-indexable	The sort order does not create a separate search destination
`/shoes/?color=black&size=42&page=3`	Depends on the approved facet policy	Keep page 3 crawlable only when the underlying facet is an approved destination
`/shoes/?color=purple&material=banana`	Return 404	The combination has no valid results or meaningful catalog state

2. Model the filter space before changing robots.txt

Sample the combinations a shopper and a crawler can create. Count the number of values per parameter, test parameter order, and estimate how many URLs appear after two, three, or more filters are combined. Include combinations produced by links, forms, JavaScript state, feeds, and old URLs.

Google's faceted navigation guidance explains that parameter-based filters can create an effectively infinite URL space. If filtered URLs do not need to appear in Google, a robots policy can prevent crawling of known parameter families. URL fragments can also represent purely client-side filters because Google generally does not use fragments for crawling and indexing. Neither approach should be used to hide products that have no other crawlable discovery path.

Make the policy enforceable. A written rule such as “filters are not indexable” is not enough. Test every navigation component and template that can emit the URL. One unfiltered link, feed, or canonical mismatch can reopen the crawl path.

Do not use rel="nofollow" as the only control for a large parameter space. If the business needs a filtered page in search, design that route as a maintained landing page instead of treating a random combination as an SEO asset.

3. Build stable filtered landing pages only for real search jobs

For every approved facet, choose one URL representation and keep its logical filter order stable. Use the standard & separator for query parameters. If filters are encoded in path segments, reject duplicate filters and keep the sequence deterministic. Link to the same preferred URL from navigation, related collections, feeds, and sitemaps.

A useful filtered landing page needs more than a parameter and a changed product grid. Give it a descriptive title and heading, explain the selected scope, show meaningful inventory, expose links to the parent category and relevant products, and define what happens when stock changes. Assign an owner who can remove or merge the page when demand or inventory disappears.

Use one stable URL for one stable filter combination.
Keep the selected state visible in HTML, not only in client-side state.
Give the page enough context to stand on its own.
Prevent sort, tracking, session, and display parameters from creating competing variants.
Return 404 for no-result, duplicate, or nonsensical combinations.

Canonical tags can consolidate duplicate signals, but they do not replace a crawl policy. Google describes canonicals as a preference that can be overridden, while redirects, canonical annotations, and sitemap inclusion work best when they all identify the same preferred URL. Use the sitemap and non-canonical URL guide when those signals disagree.

4. Make pagination a crawlable sequence

Pagination should expose distinct URLs for distinct result pages and link them sequentially with normal <a href> elements. Test the first, middle, and final page of each important collection. Verify status, canonical, title, heading, product links, empty state, and what happens when products are added or removed.

Google's pagination documentation notes that crawlers generally find URLs in link href attributes. They do not reliably click a Load more button or trigger the user action that powers infinite scroll. A JavaScript interface can still be useful, but it needs an underlying URL sequence or another crawlable discovery route.

Pattern	SEO implementation test	Common failure
Page numbers	Each page has a stable URL and links to the next available page	Only page one is linked in source HTML
Load more	Each incremental state has a retrievable URL or all important items have another path	Products exist only after a click that crawlers do not perform
Infinite scroll	Scrolling states map to crawlable URLs and do not require interaction for discovery	One URL hides a long catalog behind browser events
Empty final page	Removed page numbers return the correct state and do not loop	Redirects send every stale page to an unrelated category

Do not canonicalize every later page to page one when those pages contain distinct products. Do not submit every page-number URL to the sitemap automatically either. The sitemap should reinforce the store's intended indexable inventory, while internal pagination links keep products discoverable.

5. Separate filtering, sorting, and pagination signals

Inspect combined states such as ?color=green&sort=price&page=3. Decide whether the page number belongs to the selected collection, whether sorting changes the search job, and which parameters should be removed from internal links and canonicals. The same product should not be described through a dozen competing URL patterns because different controls append parameters in different orders.

Use a small representative matrix:

unfiltered category, first page;
approved single facet, first and later pages;
two filters with a valid result set;
sort-only and tracking-only variants;
an empty combination and a malformed combination;
a product reachable only from a deep page.

Compare requested URL, final URL, status, canonical, robots directives, source links, rendered links, sitemap presence, and Search Console evidence. A crawl such as the one described in the ecommerce SEO audit checklist helps establish the sitewide inventory; this guide focuses on the filter and pagination behavior behind that inventory.

6. Validate empty states and catalog drift

Products change faster than URL policies. A combination that was useful last season can become empty after inventory or taxonomy changes. Test the empty state at the application and HTTP levels. Google recommends a proper 404 for combinations with no results, duplicate filters, nonsensical paths, and nonexistent pagination URLs rather than redirecting every case to a generic error or category page.

If the URL represents a durable curated collection whose products are temporarily unavailable, it may remain live with a 200 response only when it still provides useful collection context and relevant alternatives. A dynamically generated filter combination with no valid results should return 404. Record the distinction by template, and do not allow a thin error message with a successful status to become a soft 404.

Re-run the sample after category, attribute, or inventory imports.
Watch for duplicate parameter order and duplicate path segments.
Check that stale pagination links disappear or resolve predictably.
Keep replacement links relevant when a curated facet is retired.
Compare sitemap and internal-link sets after major catalog changes.

7. Release and monitor the URL policy

Release one parameter family or template at a time. Keep a before-and-after crawl sample, a list of URL patterns, and the expected response for each class. Check server logs, crawl reports, Search Console indexing signals, sitemap errors, and product discovery after deployment. A drop in crawled URLs is not automatically a problem if low-value combinations were removed. A drop in product discovery is.

Prioritize defects by template reach and user impact:

Restore crawlable discovery for products with no other internal path.
Stop high-volume parameter families that create duplicates or empty pages.
Repair conflicting redirects, canonicals, links, and sitemaps.
Fix pagination states that hide later inventory.
Review curated facets for unique context, useful inventory, and ownership.

For a broader technical review, combine this page with the technical crawl and Search Console workflow. For product template decisions, continue with Product and Category Page SEO.

What not to do

Do not index every filter combination. Most combinations are interface states, not durable search destinations.
Do not block the only path to products. Contain low-value facets while preserving crawlable category and product discovery.
Do not use canonical as a crawl-budget switch. It is a consolidation signal, not a substitute for URL controls.
Do not redirect empty combinations to the parent category by default. Return the correct 404 state when no valid inventory exists.
Do not hide pagination behind a click-only interface. Expose links or another durable discovery path.
Do not mix parameter order across templates. Stable URL construction makes monitoring and consolidation possible.

Verification checklist

Every filter family has a documented crawl and index policy.
Approved facets use stable URLs, useful context, meaningful inventory, and a responsible owner.
Sort, tracking, session, and display parameters do not create uncontrolled competing URLs.
Pagination uses stable page URLs and crawlable sequential links.
Products on later pages are reachable through crawlable pagination links or another durable internal discovery path.
Empty, duplicate, malformed, and nonexistent pagination URLs return the intended status.
Internal links, canonicals, redirects, feeds, and sitemaps agree on preferred URLs.
Representative desktop and mobile states expose the same selected filters and product links.
A post-release crawl and Search Console review detect drift after catalog changes.

Faceted navigation and pagination are working when the store can explain which URL classes help shoppers and search discovery, which classes are contained, how later products are reached, and what happens when inventory changes.

Evidence basis

Google's faceted navigation, pagination, and canonicalization guidance were checked from official documentation on August 25, 2026. The URL-class matrix, release sequence, monitoring priorities, and ownership model are FloxoLab implementation frameworks, not Google ranking factors or guarantees.

Need the store URL rules turned into a fix plan?

FloxoLab can map filter combinations, pagination paths, canonical signals, internal discovery, and catalog drift into a prioritized ecommerce SEO implementation plan.

Explore the SEO audit

Originally published on FloxoLab.

Stop Scrolling Forever: 5+ Shadcn Pagination Fixes for Long Lists

Fri, 01 May 2026 14:17:21 +0000

If you've ever searched something on Google, you've already used pagination.

Google has billions of results, and instead of loading everything at once, it breaks them into pages so users can browse step by step.

The same idea applies to modern web apps.

When your website or app has a lot of data, products, users, posts, or records, showing everything at once becomes messy and slow.

That’s where Shadcn Pagination helps.

If you're building with React, Next.js, or shadcn/ui, these Shadcn Pagination Components can help you organize large datasets cleanly and improve user experience.

What Is Shadcn Pagination?

Pagination is a UI pattern used to split large content or datasets into multiple pages.

Instead of rendering 500 items in one long list, pagination breaks them into smaller manageable chunks.

Example use cases:

Product listings
Blog archives
Admin dashboard tables
Search results
Documentation pages

Shadcn UI Pagination gives you a flexible and customizable way to build this pattern in modern React apps.

Why Developers Use Shadcn Pagination

As your app grows, your data grows too.

Without proper pagination, performance drops and users struggle to navigate large datasets.

Benefits of Pagination

Improves page load speed
Makes large data easier to handle
Gives users better navigation control
Works well with APIs and server-side data
Keeps UI structured and clean
Easy to integrate into tables and lists

Shadcn Pagination Examples & Variations

Stop struggling with messy lists. Today I’m sharing my favorite Shadcn pagination examples to help you build a cleaner, more professional web interface in minutes.

Floating Pill Pagination

A modern pill-style pagination component with rounded active states.

Features

Modern floating design
Great for SaaS and dashboard UIs
Easy to integrate into any React project

Premium Ribbon Pagination

A more polished pagination design with premium visual styling.

Features

Premium ribbon-inspired appearance
Best for high-end landing pages
Clean active/hover states

Interactive Jump Pagination

Built for interfaces with many pages.

Instead of forcing users to click repeatedly, this variant makes jumping across page ranges easier.

Features

Ideal for large datasets
Better navigation for deep pagination
Improves usability in data-heavy apps

⬇️ Get these Shadcn Paginations

Pagination with Next / Previous Option

Classic pagination with previous and next controls.

Features

Includes directional navigation
Familiar UI pattern
Great for blogs and search pages

Collapsible Pagination

Minimal pagination without page numbers.

Useful when page numbers are not necessary.

Features

Previous / Next only
Great for tables with row selectors
Cleaner compact layout

Basic Pagination

Simple & straightforward page-number-based pagination component.

Features

Simple and lightweight
Easy to customize
Works in most use cases

⬇️ Get these Shadcn Paginations

Key Features of Shadcn UI Pagination

Most modern Shadcn Pagination Variants support:

Previous, next, and page controls
Active page highlighting
Client-side and server-side data handling
Flexible component structure
Keyboard accessibility
Fully responsive layouts
Minimal design that fits most UIs

Why Pagination Matters in Modern Web Apps

Pagination is not just about splitting content.

It improves both performance and usability.

Rendering too much data at once can:

Slow down the page
Increase API load
Confuse users
Hurt mobile experience

A good pagination system keeps your UI fast, structured, and scalable.

FAQ

Does Pagination Help with SEO?

Yes. Pagination improves internal linking structure and helps search engines understand relationships between content pages.

Should Pagination Appear on Every Page?

No. Pagination should only be used where content is split across multiple views or datasets.

Is Pagination Useful in SaaS Dashboards?

Absolutely. Pagination is commonly used in:

Admin panels
Analytics dashboards
User management tables
Large data reports

Final Thoughts

Pagination is one of those small components that has a big impact on usability.

Whether you're building a dashboard, blog, product listing, or admin panel, having the right Shadcn Pagination Component makes your interface easier to use and easier to scale.

Instead of building from scratch, use these Shadcn UI Pagination Examples as a starting point and customize them to fit your project.

Looking for More Shadcn Pagination Components?

Check out this curated collection of Shadcn Pagination Components to explore more modern pagination patterns for your React and Next.js projects.

Feel free to send it to me on:

Built a Shadcn Pagination Variant of your own?

I’d love to review it and feature it here.

Client side pagination is not good in some cases

Fri, 08 Aug 2025 20:29:08 +0000

The Pagination Pitfall: A React + Spring Boot Cautionary Tale

The Setup: "It’ll Be Fine..."

A few years ago, I was working on a dashboard application with a React frontend and a Spring Boot backend. The task seemed simple: display a list of users with pagination.

One of the newer devs suggested:

“Let’s just fetch everything once and paginate on the client side — it’ll be faster for the user.”

We had maybe 500 users at the time, so… sure. Why not?

And then we shipped it.

The Plot Twist: Growth Happens

A few months passed.

Marketing launched a campaign that worked too well.
Suddenly, instead of 500 users, we had 250,000+.

The dashboard became unusable. The browser would freeze, mobile devices would crash, and CPU usage would spike through the roof.
Our once-smooth user experience turned into a memory-leaking nightmare.

⚠️ The Mistake: Client-Side Pagination at Scale

Client-side pagination works only when:

The dataset is small and controlled
The entire dataset can be loaded efficiently in the browser
You don’t expect explosive growth

But when you're working with Spring Boot APIs and React, it's tempting to fetch all data via a single REST call, dump it into state, and let React handle the UI slicing.

What’s wrong with that?

You're sending huge payloads over the wire
You're increasing memory usage on the frontend
You’re locking users into long initial load times
You make updates or filtering much harder

✅ The Fix: Server-Side Pagination with Spring Boot + React

We refactored. Here’s what we did:

Backend (Spring Boot)

We used Pageable from Spring Data:

@GetMapping("/users")
public Page<User> getUsers(Pageable pageable) {
    return userRepository.findAll(pageable);
}

Spring Boot handles page number, size, sorting, and total count under the hood.

Frontend (React)

We called the API with query parameters like ?page=0&size=20:

const fetchUsers = async (page, size) => {
  const res = await fetch(`/api/users?page=${page}&size=${size}`);
  const data = await res.json();
  setUsers(data.content);
  setTotalPages(data.totalPages);
};

We then plugged this into a pagination UI. Now, we load only what we need, keep response times fast, and keep the browser happy.

Lessons Learned

React + Spring Boot is a powerful combo — but scale with caution
Don’t optimize for “today’s data” unless you’re certain it won’t grow
Use Spring’s Pageable and let the database do the heavy lifting
Keep network traffic and frontend memory usage lean
Premature optimization is bad, but premature de-optimization is worse

TL;DR

Using client-side pagination for large or unknown datasets is like bringing a spoon to a firefight.

It might work — for a while — but you’re setting yourself up for disaster.

Use the right tools. Paginate smart. Scale with confidence.

Offset vs Cursor-based Pagination: Choosing The Right Pagination Strategy

Tue, 01 Apr 2025 08:52:38 +0000

Whether you’re building API endpoints or designing sleek interfaces, selecting the right pagination strategy can significantly influence user experience and system performance. By the end of this article, you will understand the two types of pagination strategies and know when to choose one over the other.

What is Pagination & Why Does It Matter?

Pagination is the process of dividing large datasets into smaller, manageable chunks or pages to improve performance and usability. Without pagination:

Frontend apps would struggle with rendering thousands of records at once.
Backend APIs would waste resources fetching unnecessary data.

Two Types Of Pagination Strategy

During the course of my career, I have seen engineers use the wrong pagination approach when implementing features for their app. Understanding the two types of pagination strategies can make a significant difference in both the performance and user experience of software applications.

Offset-Based Pagination

Offset-based pagination is a commonly used pagination pattern where the frontend specifies a page number and a page size (how many items per page).

Here is a sample React component that makes a request to an API that is based on offset pagination

function ProductList() {
  const [products, setProducts] = useState([]);
  const [page, setPage] = useState(1);

  const fetchProducts = async () => {
    const response = await fetch(`/api/products?page=${page}&limit=10`);
    const data = await response.json();
    setProducts(data);
  };

  return (
    <div>
      {products.map(product => <div key={product.id}>{product.name}</div>)}
      <button onClick={() => setPage(p => p - 1)} disabled={page === 1}>
        Previous
      </button>
      <button onClick={() => setPage(p => p + 1)}>Next</button>
    </div>
  );
}

A sample sql query to implement the pagination could look like this:

SELECT * FROM products LIMIT 10 OFFSET 20;

Pros of offset-based pagination

It is easy to implement on the backend and also easy to implement a
frontend component for interacting with the paginated data.
Users can conveniently jump to any specific page.

Cons of offset-based pagination

Performance issues with large datasets:

While it is possible for the frontend to request a specific page number, the database still has to scan all the previous rows in the table until it reaches the exact page number and retrieve the specified page size. This leads to a significant performance bottle-neck for very large datasets. Let me make this clearer. Imagine a dataset of 500,000 records. To request the last 20 records, the frontend will make a GET request similar to this:

GET /api/items?page=25000&limit=20
   
// OR using the offset parameter
   
GET /api/items?offset=499980&limit=20

This means, the database must scan all 500,000 rows (even though the frontend only wants 20), skip the first 499,980 records (wasting CPU, I/O, and memory) and finally return the last 20. This leads to slow queries (higher latencies) and wasted resources (imagine 1000 users hitting page 25,000 simultaneously!)

Inconsistent results with real-time data

Offset-based pagination is not suitable for real-time data such as social media feeds because it can lead to duplicate and inconsistent results. This is why social media apps such as Facebook, Instagram, Twitter, etc., use infinite scroll (which is based on cursor pagination) for loading more data to the UI.

Cursor-based pagination

Cursor-based pagination uses a unique identifier known as a cursor or pointer as a reference point to fetch the next set of results. That is, each time the frontend makes an API call, in addition to sending back data, the API would send a unique identifier that the frontend will pass in the next request. Then the API would use that identifier as a reference point for sending the next set of data.

Below is a sample React component that consumes an API that is based on cursor pagination:

function CommentsFeed() {
  const [comments, setComments] = useState([]);
  const [cursor, setCursor] = useState(null);

  const fetchComments = async () => {
    const url = `/api/comments?limit=10${cursor ? `&cursor=${cursor}` : ''}`;
    const response = await fetch(url);
    const { data, nextCursor } = await response.json();
    setComments(prev => [...prev, ...data]);
    setCursor(nextCursor);
  };

  return (
    <div>
      {comments.map(comment => <div key={comment.id}>{comment.content}</div>)}
      {cursor && <button onClick={fetchComments}>Load More</button>}
    </div>
  );
}

Pros of cursor-based pagination

Efficient for large datasets since the database uses the unique
identifier to retrieve the next set of data without having to scan
previous records.
Suitable for real-time data: Cursor based pagination does not lead to
duplicate or inconsistent results when applied on datasets that
update rapidly.

Cons of cursor-based pagination

Users cannot jump to specific pages.
It is slighltly more complex to implement.

Comparison of Offset vs. Cursor

Feature	Offset Pagination	Cursor Pagination
Performance	Slow with large offsets	Fast, even with big data
Random Access	✅ Yes	❌ No (sequential only)
Real-time Data	❌ Pages may shift	✅ Stable & consistent
Implementation	Simple	Requires cursor tracking
Use Case	E-commerce, dashboards	Social media, activity logs

Choosing the right pagination strategy depends on the context and requirements of your features. With the above insights, you're ready to paginate with precision—empowering your application to be both user-friendly and performant.

Coder Legion - Recent posts tagged pagination

Faceted Navigation and Pagination for Ecommerce SEO

1. Decide which URL families deserve crawling

Example policy for a shoe catalog

2. Model the filter space before changing robots.txt

3. Build stable filtered landing pages only for real search jobs

4. Make pagination a crawlable sequence

5. Separate filtering, sorting, and pagination signals

6. Validate empty states and catalog drift

7. Release and monitor the URL policy

What not to do

Verification checklist

Evidence basis

Stop Scrolling Forever: 5+ Shadcn Pagination Fixes for Long Lists

What Is Shadcn Pagination?

Why Developers Use Shadcn Pagination

Benefits of Pagination

Shadcn Pagination Examples & Variations

Floating Pill Pagination

Features

Premium Ribbon Pagination

Features

Interactive Jump Pagination

Features

Pagination with Next / Previous Option

Features

Collapsible Pagination

Features

Basic Pagination

Features

Key Features of Shadcn UI Pagination

Why Pagination Matters in Modern Web Apps

FAQ

Does Pagination Help with SEO?

Should Pagination Appear on Every Page?

Is Pagination Useful in SaaS Dashboards?

Final Thoughts

Looking for More Shadcn Pagination Components?

Share Your Pagination Component

Built a Shadcn Pagination Variant of your own?

Client side pagination is not good in some cases

The Pagination Pitfall: A React + Spring Boot Cautionary Tale

The Setup: "It’ll Be Fine..."

The Plot Twist: Growth Happens

⚠️ The Mistake: Client-Side Pagination at Scale

✅ The Fix: Server-Side Pagination with Spring Boot + React

Backend (Spring Boot)

Frontend (React)

Lessons Learned

TL;DR

Offset vs Cursor-based Pagination: Choosing The Right Pagination Strategy

What is Pagination & Why Does It Matter?

Two Types Of Pagination Strategy

Offset-Based Pagination

Pros of offset-based pagination

Cons of offset-based pagination

Performance issues with large datasets:

Inconsistent results with real-time data

Cursor-based pagination

Pros of cursor-based pagination

Cons of cursor-based pagination

Comparison of Offset vs. Cursor