Start With the Old and New URL Structures
In WordPress, a permalink structure is a template used to construct post URLs. It is configured under Settings > Permalinks. A template might include a year, month, category, post ID, or post slug. A conversion project compares the structure currently used with the structure you intend to publish.
Record both patterns before changing settings. Also capture actual old URLs from your XML sitemap, analytics, Search Console, and any crawl exports. Individual exceptions and custom content may not follow the default structure.
Know Which WordPress Tokens Carry the URL Information
The tokens below describe familiar WordPress post permalink components. They are not interchangeable with regular expressions or Apache rewrite directives.
A structure like /%year%/%monthnum%/%postname%/ produces a different URL shape from /%postname%/. WordPress uses its rewrite system to resolve a requested path to a resource. That internal resolution is separate from issuing an HTTP redirect from an obsolete URL.
A Worked Example of Removing Dates From Post URLs
Imagine a WordPress site replacing a year/month/slug structure with post name only. The following addresses illustrate the desired mapping, not a live conversion test:
A pattern-based rule could discard the date folders and preserve the trailing slug, provided those slugs still exist and uniquely identify the right destination. If two posts once shared the same slug under different dates, a single general rule could send both to one destination. Identify collisions before relying on pattern matching.
Understand the Difference Between Rewrites and Redirects
A rewrite rule can route a requested path internally to WordPress without changing the address shown in the browser. A redirect returns an HTTP response instructing the client to request another address. For permanent URL changes, the usual migration task is to redirect each old public URL to its final new URL, commonly with an HTTP 301 or 308 status.
Saving a new permalink structure updates how WordPress resolves the new paths. It does not eliminate the need to test historical URLs. Some older URLs may be handled by WordPress or plugins automatically; others will need explicit redirects. Never assume that changing Settings > Permalinks repairs every existing backlink.
Choose a General Pattern Only When It Is Predictable
General rules work best when a stable portion of each old address can be carried directly into the new address. They are riskier when the new location depends on data not present in the old path, such as a replacement category, a renamed slug, or a merged article.
If the migration involves hundreds of URLs with editorial changes, prepare an inventory first with the Website Migration URL Mapper. A converter can assist with predictable syntax; it cannot decide whether two pages serve the same search intent.
Understand an Illustrative Regular Expression
For the Redirection WordPress plugin, the following example illustrates matching year/month/day paths ending in a single slug. It is not universal server syntax and is not a verified output from the tool on this page:
Source: ^/\d{4}/\d{2}/\d{2}/([^/]+)/?$
Target: /$1/
Match type: Regular expression
Redirect type: 301 (permanent)
The numeric groups match date segments; ([^/]+) captures the slug; and $1 places that captured slug in the target. This example is deliberately anchored at both ends so it does not accidentally match paths with extra segments. If the old structure contains only a year and month, or a category before the slug, this expression is inappropriate and must be revised.
Test against exclusions: dated archive pages, attachment URLs, custom paths, and any routes that look similar but should remain unchanged. If you are importing rules into a plugin, use its documented match mode and target syntax. The Redirect Format Converter for WordPress Plugins addresses the separate problem of preparing rules for different plugin import formats.
Do Not Paste a Plugin Pattern Into Apache or Nginx
WordPress rewrite tokens, plugin regular expressions, Apache mod_rewrite directives, and Nginx rewrite or return syntax belong to different layers. A regex written for Redirection is not automatically a valid .htaccess directive. Nor does a rule saved in WordPress necessarily cover a request that never reaches WordPress.
Check the actual web server and migration architecture before deployment. Apache rules are often placed in a reviewed .htaccess or virtual host configuration; Nginx rules belong in server configuration; WordPress plugins manage routing within the WordPress environment. Compare server-specific output with the Htaccess Redirect Generator only if Apache is involved. Take a backup before changing server files.
Watch for Trailing Slashes, Prefixes, and Special Cases
The presence or absence of a trailing slash can create an extra redirect hop if canonicalization and migration rules disagree. Similar conflicts arise between http and https, www and non-www, and a root path versus /blog/. When you change multiple conventions at once, aim for one direct redirect from the historical URL to the final canonical address.
Inspect query strings, encoded characters, multilingual slugs, paginated archives, custom post types, category bases, feeds, and media URLs separately. Rules that assume every path is a blog post may intercept unrelated pages or create an infinite loop.
Validate Rules Before Activating Them
On staging, test popular posts, varied dates, archives, and URLs that should not match. Record intended destinations and observed responses.
- Export the current URL list and back up WordPress and server configuration.
- Write down the old and new permalink patterns, plus manually overridden slugs.
- Review the proposed expression or URL map for collisions and missing targets.
- Deploy to staging and test both matching and nonmatching URLs.
- Check the HTTP status, final URL, and content on each destination.
- Confirm that there are no loops, unnecessary chains, or redirects to unrelated pages.
- Apply the validated rules to production and monitor errors after launch.
After implementation, a Redirect Rule Tester may help evaluate planned rules, while a Bulk HTTP Status and Redirect Checker can be useful for checking actual responses where supported. These are separate checks: interpreting a rule is not the same as requesting a live URL.
What a Successful Redirect Response Should Show
For a permanently moved post, a successful old-URL request generally returns a permanent redirect and leads to the intended new document. A destination page should resolve normally and display the expected content. Watch for these common outcomes:
Some genuinely removed pages should return 404 or 410 when no suitable replacement exists. Sending every missing URL to the homepage is not a sound substitute for relevant mapping.
Update WordPress and Search Signals After the Change
Once the new structure is live, update internal navigation, contextual links, XML sitemap entries, canonical references, and any hreflang annotations that point to changed URLs. Make sure new pages can be crawled and indexed as intended, and check the Search Console performance and indexing reports for unexpected changes.
Google recommends mapping old URLs to corresponding new pages, using server-side permanent redirects when possible, avoiding redirect chains, and keeping redirects for at least a year. Preserve them longer when old bookmarks and backlinks remain useful. Compare old and new pages with Before-and-After Migration Page Comparison.
