Blog post archives show the full list of articles. Category pages show grouped content. Page 2 returns a 404. Or the next/previous links appear but clicking them loads the same page again. Or the archive shows all posts on page 1 with no pagination appearing at all. WordPress pagination fix covers all these failure patterns — each has a specific cause that traces back to WordPress’s paging system, custom query configurations, or permalink settings. We go deeper on the whole subject in our WordPress Errors Complete Guide.
WordPress Pagination Fix — The Permalink Flush First Step
Before investigating any specific WordPress pagination fix, flush permalinks. Settings → Permalinks → Save Changes without modifying anything. This regenerates the rewrite rules that control how WordPress processes /page/2/ URLs. Stale or corrupted rewrite rules are the single most common cause of pagination 404 errors, and the flush takes 5 seconds. Test pagination after flushing — if the 404 resolves, no further investigation is needed.
The most common pagination failure is page 2 of an archive returning 404. WordPress generates paginated archive URLs as /category/slug/page/2/ or /page/2/ for the blog index. The “page” segment is processed by WordPress’s rewrite rules — if these rules are not correctly registered, WordPress cannot match the URL and returns 404. After a WordPress update, plugin installation, or custom post type registration, rewrite rules sometimes need regeneration. The permalink flush is WordPress’s built-in rewrite rule regeneration — it should be the first step for any URL-related issue including WordPress pagination fix requirements.
If the permalink flush does not resolve the issue, check the WordPress homepage offset setting: Settings → Reading → Blog pages show at most X posts. If this is set to 0, WordPress tries to show 0 posts per page which breaks pagination calculations. Set it to a positive number (10–20 is typical) and flush permalinks again. For custom post type archives with pagination issues, also confirm the custom post type was registered with 'has_archive' => true — without this, the archive URL does not exist and page 2 will always 404. According to the WordPress developer documentation, the $paged query variable is the internal variable WordPress uses to track the current page number — custom queries that override the main query must preserve this variable to maintain correct WordPress pagination fix behaviour across the entire template.
Custom Query Pagination — The Most Common Developer Error
Custom query pagination is the most frequent developer-introduced WordPress pagination fix requirement comes from incorrectly implemented custom WP_Query instances that do not account for pagination correctly. The pattern is consistent: pagination works on the default WordPress blog index but breaks on pages using a custom query loop.
The incorrect approach (broken WordPress pagination fix):
<?php
$args = ['post_type' => 'post', 'posts_per_page' => 10];
$query = new WP_Query($args);
while ($query->have_posts()) { $query->the_post(); /* show post */ }
echo paginate_links(['total' => $query->max_num_pages]);
?>The correct approach (working pagination):
<?php
$paged = get_query_var('paged') ?: 1;
$args = [
'post_type' => 'post',
'posts_per_page' => 10,
'paged' => $paged, // This line is critical
];
$query = new WP_Query($args);
while ($query->have_posts()) { $query->the_post(); /* show post */ }
echo paginate_links(['total' => $query->max_num_pages]);
wp_reset_postdata();
?>The critical difference: passing the paged argument to WP_Query using the current page number from get_query_var(‘paged’). Without this, WP_Query always fetches page 1 regardless of the URL — visitors on /page/2/ see the same posts as /page/1/ and the pagination links are non-functional. This single missing line is responsible for the vast majority of WordPress pagination fix requests from developers who have correctly set up pagination links but find they all show the same content. Our guide on WordPress template tags covers paginate_links() and the other pagination template functions that pair with the corrected WP_Query to produce fully functional archive pagination.
Fixing Pagination on Static Front Page Setups
Static front page setups have a specific WordPress pagination fix requirement: the blog index page’s pagination uses get_query_var(‘page’) (without the ‘d’) rather than get_query_var(‘paged’).
When using a static page, WordPress pagination fix requires the ‘page’ variable: /page-slug/page/2/ for the blog page’s pagination, and the page number is stored in the ‘page’ query variable rather than ‘paged’. Custom queries on these pages must use: $paged = get_query_var('page') ?: 1; instead of $paged = get_query_var('paged') ?: 1;. Using the wrong query variable means the query always uses paged=0 (defaulting to page 1) regardless of the URL the visitor is on. This specific ‘page’ versus ‘paged’ distinction trips up experienced developers — always check the Reading settings to determine which variable to use for the current page type.
The pre_get_posts hook is the correct way to modify the main query’s pagination settings — changing the posts_per_page or other query arguments for the blog index without writing a custom WP_Query: add_action('pre_get_posts', function($query) { if ($query->is_home() && $query->is_main_query()) { $query->set('posts_per_page', 12); } });. This modifies the main WordPress query before it executes, preserving the correct paged variable handling and pagination URL generation without requiring a custom WP_Query implementation. The pre_get_posts approach is always preferable to custom WP_Query for the main query because it maintains WordPress’s built-in pagination variable detection — a significant WordPress pagination fix advantage over the custom query approach that requires manual paged variable management. Our guide on fixing WordPress excerpt not showing covers the template function context where these same query modifications apply to controlling how posts display on archive and pagination pages.
Infinite Scroll and AJAX Pagination Issues
Themes and plugins that implement infinite scroll or AJAX-based “Load More” pagination replace the standard WordPress pagination fix flow with JavaScript-driven content loading. These implementations require specific configuration to avoid common failure patterns.
Jetpack’s Infinite Scroll feature is the most widely used WordPress infinite scroll implementation. Common issues: scroll not triggering new posts (fix: ensure the footer selector in Jetpack → Settings → Performance → Infinite Scroll matches the theme’s footer element selector), posts repeating on every scroll (fix: the query is not passing the page offset correctly — check whether the theme’s loop template is intercepting the AJAX request correctly), or infinite scroll breaking other page elements (fix: Jetpack Infinite Scroll adds classes to the body element when active — ensure the theme does not have conflicting scripts that reset body classes on each new content load).
Custom AJAX pagination using WordPress’s admin-ajax.php endpoint requires: a nonce for security verification, the current paged value passed with each AJAX request, and the query returning the correct paged results. The AJAX handler on the PHP side must create a WP_Query with the received paged value and return the HTML for the new posts. Without correctly passing and receiving the page number, every AJAX request returns page 1 content. WordPress pagination fix for AJAX setups: check the browser console → network requests during “Load More” → verify the request payload includes the correct page number → verify the server response contains different content from the previous page. If the request correctly sends page 2 but receives page 1 content, the server-side AJAX handler is not using the paged argument correctly. Our guide on WordPress enqueue scripts covers the wp_localize_script function that passes the admin-ajax.php URL and nonce from PHP to the JavaScript that handles AJAX pagination requests — correctly implementing this data passing is a prerequisite for working AJAX-based WordPress pagination fix implementations.
Previous Next Post Links and Single Post Pagination
Single post WordPress pagination fix covers two different navigation types: “Previous Post / Next Post” links that navigate between different posts in chronological order, and multi-page single posts that split a long post across multiple pages using the <!--nextpage--> tag.
Previous/Next post links: the_post_navigation() and get_the_post_navigation() are the current template functions for these links. Common issues: links not appearing (the functions must be called inside a WordPress Loop), links navigating to posts from different categories when only same-category navigation is desired (add 'in_same_term' => true, 'taxonomy' => 'category' parameters), or links showing private or password-protected posts that the visitor cannot access (WordPress filters these out automatically for logged-out visitors but sometimes includes them for admins — test in an incognito window). Custom post types with their own archives need to confirm the posts_nav_link() or the_post_navigation() functions are called within the correct loop context for that post type.
Multi-page posts using <!–nextpage–> create post pagination that is entirely separate from archive pagination. WordPress pagination fix for <!–nextpage–> broken links: the_content() must be called (not a custom excerpt or content modification that bypasses the_content filter) for nextpage tags to be processed into pagination links. The wp_link_pages() template function generates the page links for multi-page posts and must be included in the single post template near the_content(). If wp_link_pages() is missing from single.php or the relevant template part, multi-page posts show only page 1 content with no navigation to additional pages — the nextpage tags are stripped without generating page links. Add wp_link_pages() immediately after the_content() in the relevant template file to restore multi-page post navigation. Reviews from the WordPress developer community confirm that the missing ‘paged’ argument in custom WP_Query instances and the confusion between ‘paged’ and ‘page’ query variables on static front page setups together account for the majority of developer-reported WordPress pagination fix requirements that persist after a permalink flush. Our guide on fixing WordPress category page 404 errors covers the related permalink and rewrite rule issues that affect category archive pagination as part of the broader URL resolution system that WordPress pagination fix measures address.
WooCommerce shop pagination has its own WordPress pagination fix considerations separate from standard WordPress archive pagination. The WooCommerce shop page at /shop/ uses WooCommerce’s own pagination system rather than WordPress’s standard paging. Products per page is controlled by WooCommerce → Settings → Products → General → Products displayed per row and rows per page. If shop pagination breaks after a WordPress or WooCommerce update, check these WooCommerce-specific settings first before investigating WordPress’s permalink system. WooCommerce’s pagination also respects the woocommerce_product_query hook — custom modifications to the WooCommerce product query must preserve the paged argument or pagination breaks. A common mistake: using pre_get_posts to modify the WooCommerce shop query breaks the shop if the modification does not check is_woocommerce() first, unintentionally applying the modification to the main WordPress query and disrupting its pagination.
Caching and WordPress pagination fix interact in a way that causes pagination to appear broken when it is actually working correctly but the cache is serving stale page 1 content to page 2 requests. A caching plugin that does not differentiate between /archive/ and /archive/page/2/ serves the same cached page 1 HTML for both URLs. Fix: configure the caching plugin to cache paginated archives as separate pages — WP Rocket correctly caches paginated pages by default; LiteSpeed Cache requires confirming that “Separate cache for query strings” includes the page parameter; server-level caching (Varnish, Nginx FastCGI cache) requires configuration to treat URLs with different paths as different cache keys. After clearing all caches and confirming the caching plugin is configured correctly for paginated pages, test pagination in an incognito browser window where no locally-cached version can interfere with the test — this definitively separates a real WordPress pagination fix requirement from a cache configuration issue that gives the appearance of broken pagination.
SEO considerations for WordPress pagination fix implementations include rel=prev and rel=next link tags that signal the relationship between paginated archive pages to search engines. WordPress automatically adds these link tags to the HTML head when native WordPress pagination functions are used — paginate_links() and get_the_post_navigation() generate the correct canonical relationships. When pagination is implemented with custom JavaScript or AJAX that does not generate proper HTML pages for each page number, search engines cannot index the paginated content since it is not accessible at a crawlable URL. For SEO-critical archive pagination, always ensure each page number has a unique, crawlable URL (/page/2/, /page/3/) rather than JavaScript-only load-more patterns that do not change the URL. The paginated archive URLs should also be included in the XML sitemap — Rank Math and Yoast include paginated archive URLs in sitemaps by default, ensuring search engines discover and crawl all paginated content pages for comprehensive index coverage across the full archive. Our guide on creating a WordPress XML sitemap covers the sitemap configuration that includes paginated archive pages as part of the complete site URL structure submitted to search engines.
Testing WordPress pagination fix completeness after implementing a fix requires systematically checking multiple pages of each archive type on the site. A testing matrix: blog index page 1 → page 2 → last page, category archive page 1 → page 2, tag archive, author archive, search results page 2, custom post type archive. Any of these that return 404 or duplicate content require separate investigation — a fix that resolves blog index pagination may not automatically fix custom taxonomy archive pagination if the issue is in the taxonomy rewrite rules rather than the global paging configuration. Document which archives are affected and which work correctly to isolate the scope of the fix needed before implementing changes, preventing over-engineering a broad solution when a targeted fix for the specific broken archive type is sufficient.
