What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
There is no single WordPress setting called “exclude a folder.” The correct fix depends on what you mean: removing a global prefix from one custom post type, changing a category or tag base, or keeping a real directory and its files outside WordPress. Custom post types are controlled in PHP, taxonomy bases are controlled by the Permalinks screen (but cannot be removed there), and physical directories must be routed by Apache or Nginx before WordPress receives the request.
Choose the matching method below, regenerate rewrite rules, and test old and new URLs. If a public URL is changing, add redirects so bookmarks and search results continue to work.
Recommended Free Tools
First identify which kind of folder you want to exclude
WordPress uses the word “folder” for several unrelated URL patterns. A URL such as /blog/book/title/ may contain a front base from the site-wide permalink structure, while /category/news/ contains a taxonomy base. A directory such as /downloads/manual.pdf may be a real folder on disk, or it may simply be a WordPress page or rewrite path. These cases are handled at different layers.
A global front base on one post type
If your permalink structure is /blog/%postname%/, WordPress can prepend /blog/ to a custom post type. The post type registration can opt out with with_front => false. This is the usual solution when a post type should use /library/title/ while normal posts continue using /blog/title/.
#1 Best Overall
A category or tag base
Category and tag archives have their own bases, normally /category/ and /tag/. You can rename those values in the Permalinks screen, for example to /topics/, but WordPress documentation states that the core fields cannot remove the bases completely.
A real directory or another application
A directory containing downloads, an API, or a second application is outside the WordPress permalink UI. The web server must match that path before the general WordPress rule sends unmatched requests to index.php.
Compare the available approaches
| Requirement | Correct layer | Typical change | Main risk |
|---|---|---|---|
| Remove the global front base from one custom post type | Post-type registration in PHP | rewrite => ['slug' => 'library', 'with_front' => false] |
Conflicts with pages, taxonomies, or another post type using the same path |
| Rename a category or tag prefix | Settings > Permalinks | Change Optional Category base or Tag base | Existing archive URLs need redirects |
| Remove a taxonomy base entirely | Custom rewrite code or a maintained plugin | Generate base-less taxonomy rules and resolve collisions | Ambiguous URLs, pagination and feed failures, maintenance work |
| Keep a physical folder or another application outside WordPress | Apache or Nginx | Route the path before the WordPress catch-all | A server-rule mistake can affect every site or application on the host |
| Refresh changed rules | WordPress or WP-CLI | Save the Permalinks screen or run wp rewrite structure |
Changing PHP alone leaves stale stored rules |
Remove a global prefix from a custom post type
Use an explicit rewrite slug and disable the front base when registering the post type. The WordPress developer reference describes register_post_type() as the place to define custom-post-type permalinks.
Register the post type with its own path
register_post_type('book', [
'public' => true,
'has_archive' => true,
'rewrite' => [
'slug' => 'library',
'with_front' => false,
],
]);
With a site-wide structure that includes /blog/, this registration produces URLs such as /library/example-book/ instead of /blog/library/example-book/. The slug is the public path; with_front => false prevents the global front base from being prepended. Pick a slug that is not already used by a page, taxonomy, media route, or another post type.
Apply the change safely
- Back up the site and record the current URLs for the post type and its archive.
- Change the registration in the plugin or theme that owns the post type. A plugin is preferable for content that must survive a theme change.
- Deploy the code to staging first and open one single item, the archive, feeds, and pagination.
- In production, open Settings > Permalinks and click Save Changes once. You do not need to change the selected structure; saving asks WordPress to regenerate its rewrite rules.
- Check the old URL. If it no longer resolves, add a permanent redirect from the old path to the new one.
Flush rules only on activation or deployment
Do not call flush_rewrite_rules() on every request. It writes the stored rules and can create unnecessary work. A plugin that registers the post type can flush when activated and deactivated instead:
function my_register_book() {
register_post_type('book', [
'public' => true,
'has_archive' => true,
'rewrite' => [
'slug' => 'library',
'with_front' => false,
],
]);
}
add_action('init', 'my_register_book');
function my_plugin_activate() {
my_register_book();
flush_rewrite_rules();
}
register_activation_hook(__FILE__, 'my_plugin_activate');
function my_plugin_deactivate() {
flush_rewrite_rules();
}
register_deactivation_hook(__FILE__, 'my_plugin_deactivate');
The registration still belongs on the init hook. The activation callback registers it before flushing so WordPress can include the new rules.
Rename a category or tag base
For a supported base change, use the core settings rather than editing rewrite rules by hand.
- Sign in as an administrator.
- Open Settings > Permalinks.
- Leave the selected permalink structure unchanged unless you intend to change every post URL.
- Under Optional, enter a new value in Category base or Tag base. For example, entering
topicschanges/category/news/to/topics/news/. - Click Save Changes.
- Open an archive, a paginated archive, and a feed to confirm that each uses the new base.
WordPress documentation describes the defaults as category and tag: they can be changed, but they cannot be removed from URLs altogether through these fields. If the requirement is truly /news/ instead of /topics/news/, use custom rewrite code or a maintained plugin and test every conflicting route.
What it takes to remove a taxonomy base entirely
Base-less taxonomy URLs are not a checkbox in core because WordPress must distinguish a taxonomy term from a page, post, author archive, search request, feed, or another term. A custom implementation usually removes the base from generated links and adds matching rewrite rules, then resolves which object owns each ambiguous path.
When custom code is justified
- You have a documented URL requirement for a small, stable taxonomy.
- You can reserve the term namespace and prevent pages or posts from taking the same slugs.
- You can test archives, child terms, pagination, feeds, canonical redirects, sitemaps, and REST or headless consumers.
- You have a rollback plan and someone responsible for maintaining the rules after WordPress, the theme, or other URL code changes.
When a plugin is safer
A maintained permalink plugin can package rule generation and link filters, reducing bespoke code. The official Custom Post Type Permalinks listing documents filters that can exclude a specific post type from rewrite support. Treat such a plugin as a code dependency: check its maintenance activity, test it with the active theme and other URL customizations, and keep a staging copy before updating.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsRank #3
Neither approach eliminates migration work. A base-less term can collide with an existing page tomorrow, so maintain a reserved-slug list and test new content in the editorial workflow.
Keep a real folder outside WordPress
If /downloads/ is an actual directory or a separate application, do not try to exclude it from the Permalinks screen. WordPress only sees a request after the web server has decided where to send it. The dedicated path must be matched before the general rule that forwards unknown requests to index.php.
Apache
On Apache, an Alias or a more specific virtual-host location can map the public path to a directory. The directory must allow the intended access, and the mapping must be evaluated ahead of the WordPress catch-all. A representative configuration is:
Alias /downloads/ /srv/www/downloads/
<Directory /srv/www/downloads>
Require all granted
Options -Indexes
</Directory>
Use the actual document root and filesystem path for your server. If the WordPress .htaccess block is in the document root, do not add a broad rule that sends /downloads/ back to index.php. Reload Apache after validating the configuration, then request a known file, a missing file, and an ordinary WordPress page.
Nginx
Nginx uses ordered location blocks. Put a more specific block for the directory before the general WordPress block. A common pattern is:
Rank #4
location ^~ /downloads/ {
alias /srv/www/downloads/;
try_files $uri $uri/ =404;
}
location / {
try_files $uri $uri/ /index.php?$args;
}
Confirm the alias, permissions, PHP handling, and trailing-slash behavior with your host’s configuration conventions. The objective is that an existing file or application route is handled by its own location and never reaches the WordPress fallback.
Verify the boundary
- An existing file under the excluded path returns from the directory or application.
- A missing file under that path returns the intended 404 instead of a WordPress page.
- A normal page, post, category archive, and custom post type still resolve through WordPress.
- HTTPS, caching, access logging, and authentication behave consistently on both sides of the boundary.
Back up the virtual-host and .htaccess files before editing. A server rule applies to the entire virtual host, so a typo can expose files, break PHP routing, or change another application’s URLs.
Refresh WordPress rewrite rules
Changing registration code or a taxonomy setting does not necessarily update the stored rewrite rules immediately. The simplest refresh is Settings > Permalinks > Save Changes. WordPress may write .htaccess automatically when the file is writable; otherwise it displays rules for you to install manually.
Free tools Windows power users keep installed
One-click scans. No signup required.
Use WP-CLI for repeatable deployments
WP-CLI can set the structure and optional bases in one command. For example:
wp rewrite structure '/%postname%/' --category-base=topics --tag-base=labels
The command updates WordPress’s stored structure. The --hard option also updates .htaccess when the installation is configured for that operation:
Best Value
wp rewrite structure '/%postname%/' --category-base=topics --tag-base=labels --hard
Run commands as the correct site user, back up the current server rules, and inspect the resulting file before applying a production change. On a multisite installation, confirm that you are operating on the intended site.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Redirects and SEO migration when a path changes
A permalink change creates a new address; it does not automatically make every old address a permanent redirect. Build a redirect map containing each old pattern and its exact destination. Use a 301 redirect for a permanent move, preserve the relevant path or post identifier, and avoid sending every old URL to the home page.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchMigration checklist
- Export or record representative old URLs before deployment.
- Redirect single posts, archives, feeds, and paginated pages where their structures changed.
- Update internal links, navigation, XML sitemaps, canonical URLs, structured data, and API consumers.
- Check redirect chains; an old URL should reach the final URL in one hop whenever possible.
- Monitor server logs and search-console coverage for 404s and unexpected redirects after launch.
- Keep the redirects for as long as visitors and external links depend on the old paths.
Changing only one custom post type is easier to migrate than changing the global structure. A global change can affect posts, pages, date archives, feeds, and attachment links, so schedule it as a site-wide URL migration rather than a small settings edit.
Troubleshoot common failures
The new custom post type URL returns 404
- Confirm the post type registration runs on every request and uses the intended slug.
- Open Settings > Permalinks and click Save Changes to flush rules.
- Check for a page, taxonomy, or other post type already using the slug.
- Inspect server rewrite support and verify that requests reach WordPress’s front controller.
- Test again with caches and security rules temporarily accounted for.
The URL still contains the global prefix
Inspect the registration for the exact nested array: rewrite must contain with_front => false. If another plugin re-registers the post type later, its arguments may win. Search the codebase for every registration, then flush rules after the final version is active.
Category or tag links are broken after renaming
Confirm that the new base contains only the intended path segment, save the Permalinks screen again, and test term archives, feeds, pagination, and redirects. Check that no page or post already occupies the new base.
The physical directory is being rendered by WordPress
The specific Apache or Nginx rule is either missing, ordered after the catch-all, or pointing to the wrong filesystem path. Test the server configuration, inspect access logs to see which handler receives the request, and correct the virtual-host rule before changing WordPress code.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Permalinks work until the next deployment
Do not rely on a manual flush that is lost during deployment. Put post-type registration in version-controlled code, flush on plugin activation or as an explicit deployment step, and include server configuration in the same change review.
A practical decision sequence
- Write down the desired public URL and classify the path as a custom post type, taxonomy, physical directory, or another application.
- Check for collisions with pages, posts, terms, feeds, author archives, search, and API routes.
- Choose the smallest layer that can solve the problem: core settings for a supported rename, registration code for a post type, server routing for a real directory.
- Apply the change on staging and test one item plus every archive and secondary route.
- Regenerate rewrite rules, deploy redirects, and verify old and new URLs.
- Monitor logs and retain a rollback copy of PHP and server configuration.
WordPress describes permalinks as the permanent URLs of posts, pages, categories, and other archive pages. Treat an exclusion as a URL design and routing change, not merely a cosmetic folder rename: the correct layer, refreshed rules, collision checks, and redirects determine whether the result remains reliable.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

