Skip to main content
veerareddyc1015
Level 3
May 26, 2026
Question

Need Guidance on SEO-Friendly Pagination / Load More Implementation

  • May 26, 2026
  • 2 replies
  • 14 views

Hi Team,

Could you please suggest the best approach for this scenario?

I have a component that reads the latest articles from article pages and displays them on a page. Currently, there are around 1500–2000 articles, and the number keeps increasing daily. Because all article links and HTML are rendered directly in the DOM, the page load time has become very high.

The current implementation is SEO/GEO friendly since search engines like Google can crawl and index all URLs available in the DOM. However, the major issue is the performance and page load time.

I’m looking for suggestions on how to improve the page performance without negatively impacting SEO/GEO. We are also considering approaches such as pagination or a “Load More” option.

 

Thanks in Advance.

Regards

Veera

2 replies

Adobe Employee
May 26, 2026

Hello ​@veerareddyc1015 

For this use case, the best approach is to move away from rendering all 1,500–2,000 article links/cards in the initial page HTML.

Our recommendation is to use a server-rendered paginated listing, with an optional "Load More" experience layered on top as a progressive enhancement.

Best Approach

  1. Render only the first set of articles in the initial HTML

    • For example, show the latest 12–24 articles on first load.
    • This keeps the page lightweight and improves load time, rendering cost, and Core Web Vitals.
  2. Expose crawlable paginated URLs

    • Example:
      • /articles
      • /articles/page/2
      • /articles/page/3
    • This ensures search engines can still discover deeper content without requiring all article links to be present in one large DOM.
  3. Use "Load More" only as an enhancement

    • If desired, the UI can still provide a "Load More" button for users.
    • However, it should be backed by real paginated URLs so the content remains accessible to crawlers even if JavaScript is not executed.
  4. Ensure all article pages are included in the XML sitemap

    • This is important for SEO and helps search engines discover all article detail pages without relying on one archive page containing every link.

-- the best balance

  • Rendering thousands of items in the initial DOM creates unnecessary page weight and slows down performance.
  • Keeping only the first batch in the initial HTML significantly improves user experience.
  • At the same time, crawlable pagination + sitemap coverage preserves SEO, and is a safer approach than relying on a purely client-side "Load More" implementation.
  • This also scales much better as the number of articles continues to grow.

-->What we do not recommend

  • Not recommended: rendering all article links/cards in the initial DOM.
  • Not recommended: a purely JavaScript-driven "Load More" approach with no crawlable paginated URLs behind it.

-->Additional implementation guidance

  • Keep each article card lightweight: title, link, date, image, and short summary only.
  • Make sure the article query is limited to the records needed for the current page.
  • Verify indexing/caching so the listing page remains efficient as content grows.

-->Final recommendation

In short, the preferred solution is:

Server-rendered pagination for SEO, with optional "Load More" for UX.

This gives the best outcome for both performance and search visibility.

Public Adobe documentation supporting this approach

Level 4
May 26, 2026

Great question ​@veerareddyc1015, this is a common challenge as content scales.

The approach suggested above (server-side pagination + optional “Load More”) is definitely the right foundation. I’d like to add a few practical considerations from an SEO + AEM implementation perspective:

1. Focus on crawl depth and discoverability
Even with paginated URLs like /articles/page/2, /page/3, etc., make sure:

  • These pages are linked sequentially (prev/next navigation or visible pagination links)
  • They are not blocked by robots.txt or noindex
  • Google can reach deeper pages within a few clicks

If pagination is too deep, consider:

  • Adding category filters or topic-based grouping
  • Surface important articles higher in the first few pages


2. Avoid over-reliance on client-side rendering
Even though Google can process JS, relying only on client-side “Load More” can:

  • Delay content discovery
  • Increase crawl inefficiency

Best practice:

  • Use server-rendered pagination as primary
  • Treat “Load More” as a progressive enhancement only for UX


3. Optimize initial payload (biggest performance win)
Instead of thinking only pagination vs load more, also optimize:

  • Reduce card payload:
    • Avoid heavy images → use responsive images (srcset)
    • Minimize metadata per card
  • Lazy-load below-the-fold images
  • Cache listing responses aggressively (CDN level if possible)


4. Consider hybrid strategy (often works best)
In real-world AEM implementations, a hybrid approach works well:

  • First page: fast, SEO-optimized (20–30 items)
  • Pagination URLs: fully crawlable
  • “Load More”: enhances UX without replacing pagination
  • Optional: infinite scroll only if it updates URL state properly


5. Sitemap strategy matters more than people expect
Since you have 1500–2000 articles:

  • Ensure all article detail pages are in XML sitemap
  • Pagination pages can be included, but priority is individual article pages
  • This reduces dependency on listing pages for discovery


Final recommendation

  • Server-side pagination (authoritative source for SEO)
  • Lightweight first page (performance-first)
  • "Load More" layered on top for UX
  • Strong internal linking + sitemap coverage

This combination typically gives the best balance between Core Web Vitals, crawl efficiency, and user experience.