Fix WordPress 404 Errors: Rewrite Slug and URL Conflicts

If some of your WordPress URLs return a 404 error while the rest load normally, this is typically caused by stale rewrite rules or a conflict between content types sharing the same URL format.

Each custom post type has a permalink structure, and part of that structure is the rewrite slug. WordPress reads this slug to decide which content to load from the database for a given URL.

You can override it when registering the post type, but using the same slug for multiple content types often leads to 404 errors or redirect loops.

This guide covers how to identify these conflicts, resolve them, and keep your custom post types loading correctly.

Why Only Some of Your URLs Return Error 404

When troubleshooting a 404 error, first check whether every URL on your site is affected or only specific ones. This simple check often points directly to the underlying cause.

• If every URL, including the homepage, returns an error 404, the problem is usually related to the server configuration or rewrite rules that have not been flushed.
• If the homepage, regular posts and pages work correctly but only a particular custom post type's URLs return a 404 error, the problem usually comes from a rewrite rule conflict.

To understand why this happens, it helps to know how WordPress matches a URL to the content it should display.

What is a Rewrite Slug and How to Change It

When you register a custom post type or taxonomy, the rewrite slug is the segment of the URL that appears before the individual post or term name. WordPress uses it to build the rewrite rule (see next section) and to tell one content type apart from another within a URL.

You define it via the rewrite argument when registering the content type.

function custom_post_type_registration() {
	 $args = array(
		'public' => true,
		'label' => 'Book',
		'supports' => array( 'title', 'editor', 'thumbnail' ),
		'rewrite' => array( 'slug' => 'publication' ),
	 );
	 register_post_type( 'book', $args );
}
add_action( 'init', 'custom_post_type_registration' );

For example, suppose your custom post type is named "Book" and you set its rewrite slug to publication . The sample permalink then looks like this:

https://example.com/publication/a-sample-cpt-permalink

If you omit the rewrite argument, WordPress uses the post type name instead, so the base becomes book :

https://example.com/book/a-sample-cpt-permalink

How WordPress Decides Which Content a URL Points To

WordPress stores its rewrite rules in a list known as the rewrite rules array. Each rule is a regular expression that is checked against a requested URL to determine which content should be retrieved from the database.

A standard rule for posts and pages is:

^/([^/]+)/?$

This pattern matches a simple URL such as https://example.com/about/hello-world/ and tells WordPress to load the page with the slug hello-world (the child page of the parent page about ).

This first-match rule functions correctly when each content type has its own distinct permalink format. Problems begin when different rules match the same URL, which is where most conflicts typically occur.

Where These URL Conflicts Actually Come From

The rewrite system is simple and efficient, but that simplicity is also the source of most URL conflicts. WordPress checks the rules one by one and stops at the first match. If two content types use the same permalink structure, both rules match the same URL.

The first matching rule always takes precedence. If that rule belongs to a different content type than the requested URL, WordPress returns a 404 response. This happens silently, without any admin notice or warning. Below are the most common setups where this happens.

A Page and a Custom Post Type With the Same Slug

Many of the people who ask whether Permalink Manager can fix their URL conflict turn out to have the same kind of setup. This happens when a page, for example "Cars" using the slug cars , shares its permalink structure with a custom post type that uses the same slug.

In this situation, accessing the page URL may return a 404 error even if the page is published. This happens when the page slug matches a rewrite rule used by a custom post type, so WordPress tries to load the custom post type archive instead of the standard page.

For this reason, many themes and plugins use unusual-looking slugs such as portfolio-item for their custom post types.

If you do not need both to use the same slug, there is no need for a custom permalink plugin or a code snippet. The usual fix is simply to keep the two slugs distinct. You can change the page slug, or adjust the rewrite slug of the affected custom post type.

Setting the Rewrite Slug to a Single Slash

This case is a variation of the issue described above. The difference is that it affects more than one page. It happens when the rewrite rules for standard pages overlap with the malformed permalink rules for custom post type items.

This overlap occurs when a custom post type's rewrite slug is set to / , which removes its base.

...
'rewrite' => array( 'slug' => '/' ),
...

At first glance this looks correct, but it will not behave the way you expect. Setting the slug this way overwrites the rewrite rules for built-in posts and pages, which leads to broken links, 404 errors, and content that can no longer be reached.

The reason is how WordPress handles permalinks. By design, it does not allow the same permalink format to be shared across different content types.

When a custom post type has no distinct rewrite slug, WordPress may resolve URLs in one of two ways depending on rule priority. In both cases, part of the content may become unavailable:

1. WordPress may treat your pages and posts as custom post type items, so those pages and posts return 404 errors.
2. Or WordPress may ignore the custom post type's rewrite rules, so the custom post type items return 404 errors instead.

Why Removing WooCommerce URL Bases Causes 404 Errors?

Removing the /product/ or /product-category/ base from WooCommerce URLs can cause URL conflicts and lead to 404 errors on a website. WordPress does not warn users that changing or removing these rewrite bases may affect existing links.

WooCommerce relies on WordPress rewrite rules to determine which content should be displayed for each URL. If product URLs use the same pattern as pages, categories, or other content types, WordPress may find more than one possible match.

In such cases, WordPress uses the first matching rule, which can result in incorrect URL handling and unavailable store pages.

This issue commonly appears after removing the /product/ or /product-category/ base, replacing it with a dot, or using the same base for both URL types in "Settings -> Permalinks".

To resolve it, check for conflicting rewrite structures, restore unique URL bases where possible, and flush WordPress rewrite rules after making changes.

Cache, Stale Rewrite Rules or Server Misconfiguration

Most 404 errors are caused by conflicts in rewrite rules or an outdated rewrite rules array, but this is not the only possible cause.

The problem can also be caused by cached content, either at the server level or in the browser. In such cases, testing the page in an incognito or private browsing window helps rule out browser cache interference.

If the error page appears as plain text with no styling, like in the examples below, this usually points to a missing or corrupt .htaccess file, or an NGINX configuration issue.

How to Fix It

Flush the Rewrite Rules

Stale rewrite rules are one of the most common causes of 404 errors that appear after updating a plugin or theme, or server migrations. WordPress keeps rewrite rules cached in the database, and they are not always regenerated automatically.

Flushing the rewrite rules often fixes the problem without additional troubleshooting. Follow the steps below to proceed:

1. Go to the admin page "Settings -> Permalinks".
2. Flush the rewrite rules and clear their cache by clicking "Save changes" even if no change has been made.

If the 404 errors no longer appear after this step, you are all set and no further action is needed. If they persist, please continue with the troubleshooting steps below.

Keep Rewrite Slugs Unique

If flushing the rewrite rules did not fix the problem, the cause is most likely two content types sharing the same base. Review your custom post types and taxonomies, and confirm that each one uses a unique rewrite slug. To prevent URL conflict, avoid overriding the rewrite slug unless necessary.

WordPress sets it to the post type name by default, and that name is already unique. Change it only when you need a custom structure, and when you do, make sure the new value is not already used by a page, another post type, or a taxonomy.

Implement Custom Permalinks

If you need the same permalink format across several custom post types and/or taxonomies, for example to mimic hierarchical content structure, you can use a tailored code snippet that overwrites the 'query' object before WordPress builds the database query.

If you would rather avoid code, or the snippet does not work as expected, a dedicated custom permalink plugin is usually the better choice.

Fix Server-Level 404 Errors

To make the pretty permalink system work, WordPress needs either an .htaccess file (if you're using Apache) or an NGINX configuration file (for NGINX servers). These files help WordPress understand how to process and route URLs.

When you install WordPress, it automatically generates a .htaccess file. This file is used by Apache, or by NGINX servers if Apache is set up as the reverse proxy. This file includes important settings that determine how URLs are processed.

If the .htaccess file is missing or corrupted, WordPress cannot properly update the settings, which could cause server-level "404" errors with URLs.

Sometimes, the file exists but cannot be changed due to permission settings (CHMODs). Another possibility is that a faulty plugin may have deleted or modified it, overwriting any previous changes.

If your website still shows "404 errors" after flushing the rewrite rules in the admin panel, and you have FTP access, consider creating a .htaccess file in the root directory and inserting the default code.

The default configuration file code is shown below. If the .htaccess file is not present, you will need to create it manually. Please copy, paste, and save the file with the default contents provided below.

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

Why URL Conflicts Break Elementor and Bricks Editors

URL conflicts can prevent both Elementor and Bricks editors from opening correctly because both builders rely on loading the correct preview URL. If another taxonomy or post type uses the same permalink format, WordPress may resolve the request to the wrong content.

As a result, Elementor or Bricks may fail to load and display messages such as " Invalid post type " or " The preview could not be loaded ".

The issue is usually not limited to the editor. The same conflict may affect front-end URLs, which can return a 404 Not Found error. If the editor does not load correctly, check whether other website URLs are also affected.

If you use Elementor, you can temporarily work around this issue by adding a custom code snippet that forces the editor to use query-based preview URLs instead of conflicting permalinks. This allows the editor to load even when a permalink conflict exists.