WordPress automatically manages redirects to maintain consistent URLs, protect SEO, and prevent broken links when slugs or structures change.
This can help prevent duplicate content issues by ensuring there’s only one canonical URL for each piece of content.
Canonical Redirects
WordPress enforces canonical URLs for each page using the redirect_canonical function/hook. This function creates behind-the-scenes redirects in the following cases:
URL Normalization
Redirects non-canonical URLs to their preferred versions
Example: example.com/post-name/ → example.com/post-name (if trailing slashes are disabled)
Protocol Standardization
Ensures consistent use of HTTP or HTTPS
Redirects http:// to https:// (or vice versa based on site settings)
WWW vs Non-WWW Handling
Redirects between www.example.com and example.com based on WordPress settings
Pagination Handling
Manages pagination URLs to prevent duplicate content
Example: Redirects /page/1/ to / (since page 1 is the same as the main page)
Feed URL Management
Standardizes feed URLs
Redirects various feed URL formats to the canonical feed URL
Example Redirects
All of the following are controlled and added by the redirect_canonical function.
/index.php?p=123→/my-post//my-post/?utm_source=google→/my-post//my-post→/my-post/(if trailing slashes are enabled)
Disabling
In rare cases you may want to disable this, like if you’re handling precise redirects yourself, or with another plugin or tool like Rank Math SEO.
remove_action( 'template_redirect', 'redirect_canonical' );
Old Slug Redirects
When a post or page slug changes, WordPress saves the old slug in the wp_postmeta table as _wp_old_slug. If someone visits /old-slug/, WordPress automatically issues a 301 redirect to the new permalink.
This preserves backlinks and SEO authority when content is renamed, which is important, but it’s the #1 cause of confusion when someone asks me:
Why is /some-page/ redirecting to /services/newer-fancy-url-for-some-page/?
WordPress has likely done this, and diagnosing and fixing the issue can be a bit tricky.
Attachment Redirects
When an attachment URL is accessed directly, WordPress uses redirect_attachment() to redirect the visitor to the parent post.
This prevents attachment pages from acting as thin or duplicate content.
Login & Admin Redirects
Core functions handle administrative and user redirects, such as login and logout flows:
wp_redirect()wp_safe_redirect()
These functions send HTTP headers and prevent redirects to unsafe external domains.
Server-Level Redirects
WordPress uses server-level URL rewrites for creating pretty URLs through the CMS. This is done by adding rules to an Apache .htaccess file with mod_rewrite to route all requests through index.php.
This is less common today as nginx is the defacto standard for handling WordPress web servers. In nginx the rules do the same thing, but look different:
Equivalent rewrite for Nginx:
location / {
try_files $uri $uri/ /index.php?$args;
}
Tracing Redirects
Summary of Built-in WordPress Redirects
| Redirect Type | Trigger | Purpose |
|---|---|---|
| Canonical | URL mismatch | Normalizes URLs |
| Old Slug | Slug changed | Preserves SEO and backlinks |
| Attachment | Direct media access | Redirects to parent post |
| Admin/Login | Auth or admin action | Secure redirection |
| Server-Level | Web server rules | Route requests to WordPress |
Most automatic redirects come from:
redirect_canonical()(canonicalization)_wp_old_slug(legacy slugs)- Server-level rewrites (routing)
Plugins and custom rules can extend this further, but WordPress core alone covers many common redirect cases automatically. In almost all cases it’s a good thing, but when there’s trouble in WP with redirects it can often be the source of the issue. It’s important to understand what’s going on under the hood.