Updating Pagination link URL | Community
Skip to main content
ManjulaKumar
Level 2
July 14, 2025
Solved

Updating Pagination link URL

For pagination can we avoid using #1 after the page URL.

For eg -

/abc.html#1

instead have structure like this

/abc/page/1  or 
/abc/?page=1  or 
/abc/page/1.html. with results maybe from 1 -10 in first page

 

    SantoshSai
    SantoshSaiAccepted solution
    New Participant
    July 14, 2025

    Hi @manjulakumar,

    Yes, you can and should avoid using #1 (fragment identifiers) in URLs for pagination in AEM. Here's a breakdown of your options and best practices:

    • Fragment (#) is not sent to the server; it’s processed only by the browser.

    • You can’t handle it on the server side (e.g., AEM servlet, component logic).

    • It’s bad for SEO: search engines may ignore it or index only the first page.

    • It can interfere with analytics and routing in SPA/MFE frameworks.

    Recommended Alternatives

    1. /abc/page/1.html

    2. /abc/?page=1

    3. /abc/page/1

    Santosh Sai
    View reply

    4 replies

    kautuk_sahni
    kautuk_sahni
    Employee
    July 31, 2025

    @manjulakumar Did you find the suggestions helpful? If you need more information, please let us know. If a response resolved your issue, kindly mark it as correct to help others in the future. Alternatively, if you discovered a solution on your own, we'd appreciate it if you could share it with the community. Thank you !

    Translate
    Kautuk Sahni
    Kamal_Kishor
    Kamal_Kishor
    New Participant
    July 15, 2025

    @manjulakumar -
    What is your use-case? Is there a specific reason to avoid '#'?
    It may be a good idea to have '#' for pagination if your pagination logic is driven from client side (browser)

    Also, results on your pagination always fixed, I am trying to think from caching perspective (if your whole page should be cached for pagination perspective).

    thanks.

    Translate
      BrianKasingli
      BrianKasingli
      New Participant
      July 14, 2025

      Hello @manjulakumar,

      Yes, it’s definitely possible to move away from the #1 fragment style in your pagination URLs. That # part is handled only in the browser—it doesn’t trigger a server request—so it's not ideal for scenarios where the backend (like AEM) needs to process different pages of results.

      URL structures like /abc?page=1 or /abc/page/1.html, you can handle this by writing a custom servlet in AEM that uses the Query Builder API. By passing the page parameter, your servlet can calculate the correct offset and return results for each page dynamically. The Query Builder is great for this because it integrates well with AEM’s permissions and content structure.

      # Search with "your_search_term" and get results for Page 1 curl -X GET "http://your_server/bin/findPagePaths?q=your_search_term&page=1" # Search with "another_search_term" and get results for Page 2 curl -X GET "http://your_server/bin/findPagePaths?q=another_search_term&page=2"

       

      In fact, I’ve written an article that shows exactly how to do this:

      AEM Effective Pagination with Query Builder API - https://sourcedcode.com/blog/aem/aem-effective-pagination-with-query-builder-api

      Translate
        SantoshSai
        SantoshSaiAccepted solution
        New Participant
        July 14, 2025

        Hi @manjulakumar,

        Yes, you can and should avoid using #1 (fragment identifiers) in URLs for pagination in AEM. Here's a breakdown of your options and best practices:

        • Fragment (#) is not sent to the server; it’s processed only by the browser.

        • You can’t handle it on the server side (e.g., AEM servlet, component logic).

        • It’s bad for SEO: search engines may ignore it or index only the first page.

        • It can interfere with analytics and routing in SPA/MFE frameworks.

        Recommended Alternatives

        1. /abc/page/1.html

        2. /abc/?page=1

        3. /abc/page/1

        Translate
        Santosh Sai
          Terms & ConditionsAccessibility statement

          Loading footer...