Category archives — the pages at /category/your-category/ that list all posts in a category — return a 404 Not Found error even though the category exists in the WordPress admin and posts are assigned to it. Or recently created categories work fine while old ones return 404. Or all category pages return 404 after a WordPress update or permalink change. WordPress category page 404 errors are almost always a permalink and rewrite rule problem, not a content problem — the category and its posts exist, but WordPress cannot generate the correct URL to serve them. For the bigger picture, our WordPress Errors Complete Guide pulls everything together.
WordPress Category Page 404 — The Permalink Flush Fix
The fastest fix for a WordPress category page 404 is resaving the permalink structure. WordPress stores URL routing rules in a rewrite rules cache that becomes stale after WordPress updates, plugin installations, and category slug changes. When the rewrite rules do not include the current category slugs, requests for category archive URLs return 404 because the routing system cannot match the URL to a WordPress query.
Navigate to WordPress admin → Settings → Permalinks → scroll to the bottom → click Save Changes without modifying anything. This action regenerates the complete rewrite rules from scratch — including all registered post types, taxonomies, categories, and tags. After saving, visit the category archive URL that was returning 404. In the vast majority of WordPress category page 404 cases, this single action resolves the issue immediately. The permalink flush should always be the first action when any WordPress archive URL returns 404, because it costs nothing and resolves the most common causes without requiring any investigation.
If the permalink resave does not resolve the WordPress category page 404, check whether the category has any published posts assigned to it. An empty category (a category with no published posts) may return 404 depending on the theme’s archive template — some themes deliberately return 404 for empty archives rather than showing an empty listing page. Assign at least one published post to the category and test again. Also verify the category slug has not been accidentally changed to a value that conflicts with a page or post slug — WordPress resolves conflicts between category slugs and page slugs by serving the page, which means the category archive becomes inaccessible via its normal URL. Check the category slug in Posts → Categories → edit the category and look at the Slug field. Our guide on fixing WordPress 404 errors covers the full permalink flush and .htaccess repair procedure that applies to all WordPress URL resolution failures, including the category page 404 as a specific instance.
Slug Conflicts and Category Base Issues
A slug-conflict-caused WordPress category page 404 is particularly subtle — the URL appears correct, the permalink flush has been done, but the category archive still returns 404 because the URL is being claimed by a page or post rather than the category archive.
WordPress URL routing follows a priority order: if a page exists with the slug “news” and a category also has the slug “news,” WordPress serves the page at /news/ and the category archive becomes inaccessible. The WordPress category page 404 fix: change the category slug to something unique (Posts → Categories → edit the category → change the Slug field) or change the page slug. After changing either slug, flush permalinks again. For sites where category slugs and page slugs must remain the same for business or SEO reasons, the category base setting provides a prefix: Settings → Permalinks → Optional → Category base → enter a prefix (e.g., “topic”) so category URLs become /topic/news/ instead of /news/, eliminating the conflict with the page at /news/.
The category base setting also affects all WordPress category page 404-prone URL patterns site-wide — changing it from empty (default) to a prefix creates a sitewide URL structure change that should be handled carefully to avoid creating 404 errors for previously indexed category URLs. If the category base is changed, add 301 redirects from the old category URLs to the new prefixed URLs using a redirect plugin (Redirection, Rank Math’s redirect module) or .htaccess RewriteRule entries. Without redirects, any external links or indexed URLs pointing to the old category path return 404 after the base change, negatively affecting SEO and user experience for existing referrals. The Redirection plugin can automatically detect the old URLs and generate the redirect rules when category slugs or the category base is changed, provided it is active before the change is made and has been logging 404 errors — its 404 monitor captures the old URLs being requested so redirect rules can be created from them. According to the WordPress developer documentation, the category base must be unique and cannot conflict with any registered post type slug, page slug, or taxonomy slug — WordPress does not automatically resolve these conflicts and the result is unpredictable URL routing.
Plugin and .htaccess Causes
When permalink flushing does not resolve WordPress category page 404, a plugin or .htaccess configuration is intercepting the category URL before WordPress can process it. This is less common than the permalink issue but produces identical visible symptoms.
Test with plugins disabled to isolate a WordPress category page 404 plugin conflict: Health Check → Troubleshooting Mode → enable → visit the category URL. If the category archive now loads, a plugin is interfering with the URL routing. Re-enable plugins one at a time → test the category URL after each → the plugin whose activation causes the 404 return is the conflict. Common plugin types that cause this: SEO plugins that add custom rewrite rules conflicting with WordPress’s category routing, redirect plugins that have a blanket rule capturing all /category/* URLs, and custom post type plugins that register post type slugs matching category slugs. Also check the .htaccess file for any custom rules above the WordPress block that might capture category URL patterns — rules like RewriteRule ^category/(.*) /somewhere-else/$1 redirect category requests away from WordPress before WordPress processes them.
A WordPress multisite installation has an additional cause for WordPress category page 404 on subsites: the subsite’s rewrite rules must be correctly configured in the network’s web server configuration. For subdirectory multisite (network.com/subsite/), the web server must be configured to route all requests under /subsite/ through WordPress — if only the root domain’s URLs are routed correctly, the subsite’s category archives return 404 from the web server before WordPress processes the request. Verify the multisite .htaccess includes the complete network routing rules (not just the standard single-site block) and that the rules correctly handle subdirectory paths. Our guide on setting up WordPress multisite covers the .htaccess and Nginx configuration that must be correctly structured for all subsite URLs including category archives to resolve correctly.
Custom Taxonomy Category Page 404
Custom taxonomies — taxonomies registered by plugins or theme code alongside the built-in “category” taxonomy — produce WordPress category page 404-equivalent errors when their archive URLs return 404. The fix is the same (permalink flush) but the underlying cause may include incorrect taxonomy registration arguments.
Verify the custom taxonomy is registered with archive support: the taxonomy registration must include 'rewrite' => ['slug' => 'your-slug'] and the post type the taxonomy is attached to must be registered with 'publicly_queryable' => true. A taxonomy registered with 'rewrite' => false does not get URL routing — its archives return 404 permanently regardless of permalink flushes. Add or correct the rewrite argument in the taxonomy registration code → flush permalinks → test the archive URL. For taxonomies registered by third-party plugins where the registration code cannot be modified, use the register_taxonomy_args filter to add rewrite support: add_filter('register_taxonomy_args', function($args, $taxonomy) { if ($taxonomy === 'your_taxonomy') { $args['rewrite'] = ['slug' => 'your-slug']; } return $args; }, 10, 2);. This filter modifies the registration arguments before WordPress processes them, adding rewrite support without modifying the plugin’s code.
Pagination of category archives — page 2 and beyond at /category/name/page/2/ — sometimes produces WordPress category page 404 errors even when page 1 loads correctly. This specific pattern indicates the pagination rewrite rules are broken but the base archive URL is resolving. Run the permalink flush → test page 2. If page 2 still returns 404 after the flush, check whether a plugin or theme is setting a custom posts_per_page of 0 (which prevents pagination from generating URLs) or whether the web server’s rewrite configuration does not correctly handle the /page/N/ suffix in the URL. For Nginx servers specifically, the try_files directive must be configured to handle paginated archive URLs: try_files $uri $uri/ /index.php?$args; — without the ?$args parameter, query string information required for pagination is stripped before WordPress processes the request, causing paginated archive pages to return 404. Reviews from the WordPress support community confirm that permalink flushing resolves WordPress category page 404 errors in the majority of cases, with slug conflicts and plugin rewrite rule interference explaining most of the remaining cases that persist after a flush.
Checking the WordPress database directly confirms whether category archive data exists when WordPress category page 404 errors persist despite plugin isolation and permalink flushes: via phpMyAdmin → select the WordPress database → run SELECT * FROM wp_terms WHERE slug = 'your-category-slug';. If the query returns a row, the category exists in the database. Follow with SELECT * FROM wp_term_taxonomy WHERE term_id = [id from above] AND taxonomy = 'category'; — if this returns a row with a count greater than 0, the category has posts assigned. If the database confirms the category exists with posts but the URL still returns 404, the issue is definitively in the URL routing layer (rewrite rules, .htaccess, or web server configuration) rather than in the WordPress data — focus the investigation entirely on the permalink and .htaccess sections rather than checking whether the category data exists.
Theme template issues cause a specific variant of WordPress category page 404 where WordPress processes the category archive request correctly but the theme’s category.php or archive.php template contains a redirect or exit call that prevents the content from rendering. Enable debug mode → visit the category URL → check /wp-content/debug.log for any errors or notices at the time of the 404 → check whether the template is generating a wp_redirect() call with a 404 status. Switch to a default theme temporarily to confirm whether the issue is theme-specific — if the category archive loads on Twenty Twenty-Four but returns 404 on the active theme, the active theme’s archive template contains the problem. Review the theme’s archive.php, category.php, and functions.php for any conditional redirect logic that might be routing category archive requests to a 404 page under certain conditions.
WordPress multipage category archives — categories displayed across multiple pages — sometimes produce WordPress category page 404 on page 2 and beyond while page 1 works correctly. This pagination-specific 404 occurs when the category archive’s posts_per_page setting is set to a value that would produce more pages than actually exist. For example: a category with 5 posts, posts_per_page set to 3, and someone requesting /category/name/page/3/ — page 3 does not exist (only pages 1 and 2 are needed for 5 posts), so WordPress correctly returns a 404. This is expected WordPress behaviour — pagination beyond the last existing page correctly returns 404. However, if page 2 returns 404 when the category has enough posts to require pagination, the paged rewrite rules need to be regenerated via the permalink flush described at the start of this guide. Our guide on fixing WordPress block editor issues covers the REST API and URL routing framework that also underlies category archive URL resolution in sites where the block editor and REST API are active.
Caching plugins sometimes cache a 404 response for a category archive URL, causing the category page to continue returning 404 even after the underlying issue is fixed. This cached-404 scenario is particularly confusing because the fix has been correctly applied (permalink flush done, slug conflict resolved) but the category page still shows a 404 — because the caching plugin is serving the cached 404 response from before the fix. After resolving the underlying cause of the WordPress category page 404, always purge all caches completely (caching plugin → purge all, CDN → purge everything, browser → hard refresh) before testing whether the fix worked. If the category page now loads after a cache purge, configure the caching plugin to not cache 404 responses: WP Rocket → Advanced Rules → Never Cache URLs → do not add 404 pages to the cache. LiteSpeed Cache similarly has an option to avoid caching 404 responses, preventing the issue from recurring when any URL temporarily returns 404 and the cached 404 persists after the URL becomes valid.
