WordPress Pagination Broken: Fix 404 on Page 2 and Beyond

Your homepage loads fine. Individual posts and pages load fine. But click "Next" at the bottom of the blog or shop page and you land on a 404. This is one of the more confusing WordPress bugs to search for, because it looks identical to a "broken permalinks" problem but the usual fix - resaving permalinks - often does nothing.

Symptom: What You're Actually Seeing

Pagination-specific 404s have a distinct pattern, and it's worth confirming you're looking at the right problem before you touch anything:

• yourdomain.com/blog/ loads normally, showing the first set of posts.
• yourdomain.com/blog/page/2/ returns a 404, either from WordPress itself or from the server.
• Single posts, pages, and category archives all load fine when visited directly.
• It often only shows up on specific pages - usually the blog index, a shop archive, or a custom page template with a post loop - not site-wide.

If every inner URL 404s, including single posts, that's a rewrite-rule problem, not this. This post is specifically about the case where normal URLs work and only the "next page" link breaks.

Cause 1: Stale Rewrite Rules

WordPress stores its pagination rewrite rule (among hundreds of others) in the wp_options table. Anything that changes your permalink structure, moves the site to a new domain, or restores from an old backup can leave that cached rule out of sync with your actual settings - even though single-post URLs, which use a simpler rule, still resolve correctly.

Fix: Go to Settings → Permalinks in wp-admin and click Save Changes without changing anything. This forces WordPress to regenerate every rewrite rule, pagination included. If you have WP-CLI access over SSH, this is faster and doesn't need a browser session:

wp rewrite flush --hard

Try page 2 again immediately after. This alone fixes the majority of pagination 404s.

Cause 2: A Static Front Page With the Blog Set to "Posts Page"

If you've set a static page as your homepage under Settings → Reading and pointed "Posts page" at a separate page (commonly called Blog or News), pagination on that page has a quirk: WordPress expects /blog/page/2/, but some themes and older tutorials link to /page/2/ instead, which resolves against the homepage's rewrite rules and 404s.

Fix: Check the exact slug your Posts page uses (Pages in wp-admin), and make sure your theme's pagination links are generated by WordPress functions like the_posts_pagination() or paginate_links() rather than hardcoded. If a page builder or child theme hardcodes the link, correct it to use the Posts page slug.

Cause 3: A Custom Query Overriding the Main Loop

This is the most common cause on custom-built themes and page builders. If a theme's front-page.php or a page template runs its own WP_Query to list posts instead of using the default query, it has to be told which page it's on manually. Without that, every page of results shows page 1's posts, and WordPress's own pagination logic (which reads the URL) doesn't line up with what the custom query actually returned - leading to a 404 once you're past the total page count it calculated.

Fix: Any custom WP_Query used for a paginated loop needs the current page number passed in explicitly:

$paged = (get_query_var('paged')) ? get_query_var('paged') : (get_query_var('page') ? get_query_var('page') : 1);

$query = new WP_Query(array(
    'post_type' => 'post',
    'posts_per_page' => 10,
    'paged' => $paged,
));

Note the get_query_var('page') fallback - on a static front page, WordPress uses page instead of paged for the query var, which is a common source of this bug even in code that looks correct at first glance.

If this is happening inside a page builder (Elementor, Divi, etc.) rather than custom PHP, check the loop widget's pagination setting - most have a toggle that's easy to leave off, or a "basic" pagination type that doesn't read the URL correctly under a static front page.

Cause 4: Caching Plugin or CDN Serving a Cached 404

If page 2 worked before and stopped after a plugin update, migration, or DNS change, check whether your caching layer is serving a stale response. A full-page cache plugin (or Cloudflare, if you're using it) can cache a 404 that happened once - during a deploy, for example - and keep serving it long after the underlying page started working again.

Fix:

• Purge your caching plugin (LiteSpeed Cache, WP Super Cache, W3 Total Cache, etc.) completely, not just the homepage.
• If you're on Cloudflare, go to Caching → Configuration and Purge Everything, then retest.
• Load the page in an incognito window or curl it directly to rule out browser cache:

curl -I https://yourdomain.com/blog/page/2/

Cause 5: .htaccess Missing the Pagination Rewrite Block

On Apache/cPanel hosting, WordPress's standard .htaccess block includes a general rule that covers pagination automatically. But if a security plugin, manual edit, or restored backup left an incomplete .htaccess, single posts can still resolve (they often match earlier, more specific rules) while /page/2/ falls through and hits the server's default 404 instead of ever reaching WordPress.

Fix: In cPanel's File Manager, open .htaccess in your site's root and confirm it has the full WordPress block between the markers:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

If it's missing entirely or truncated, delete it and resave permalinks in wp-admin to have WordPress regenerate it from scratch.

Quick Diagnosis Table

Prevention

• After any permalink structure change, migration, or restore, flush permalinks as a standard step - don't wait for a 404 report to remember.
• If you write custom loops, always pass paged (with the page fallback for static front pages) rather than assuming WordPress will infer it.
• Keep a known-good copy of your .htaccess block somewhere outside the site root, so a bad restore or plugin conflict is a two-minute fix instead of a guessing game.
• Test pagination specifically after any caching or CDN change - it's the part of a site people forget to click through during a quick QA pass.