Change only the slug or structure required by a concrete need. Proceed when old-to-new destinations, redirect coverage and a focused recovery route are verified; retain a working structure when the migration benefit is small.
Changing WordPress permalinks changes the addresses people use to reach your content. On an established site, treat it as a small URL migration: record the old addresses, prepare their destinations, make the setting change and verify both routes. A successful Save message does not prove that old links still work.
This guide uses official WordPress and Google documentation checked on 13 October 2026. It covers post slugs and permalink structure on the same domain. The examples and test plan are editorial guidance, not evidence from a hands-on migration or a ranking experiment.
Decide whether the address needs changing
A shorter address can be easier to share, but an established working URL does not need changing every time you improve its title. Consider the effect on bookmarks, search results, newsletters and links from other websites before removing dates or categories across an archive.
Separate three changes: editing one post’s slug, changing the default post URL structure, and changing the domain or hostname. WordPress exposes the individual slug in the post settings sidebar; Settings, Permalinks controls the broader structure. See the official post settings reference and Permalinks screen.
If only one address contains a typo, a site-wide structure change creates unnecessary work. If the domain itself is changing, use our separate WordPress domain-change guide. Keep unrelated hosting, design and plugin changes outside this operation where practical.
If the site uses Plain permalinks, its public post addresses use an ID query such as https://example.com/?p=123. Changing a post slug alone does not give that ID-based address a readable path. Moving to a non-Plain structure is a separate site-wide change: review the mapping and routing, then verify the old ID links as well as the new paths. See WordPress’s permalink types and structure tags.
Record the current structure and affected URLs
Save the current permalink selection and any custom structure before editing it. WordPress documents Plain, date-based, Numeric, Post name and custom formats, with separate optional category and tag bases. Its permalink customisation guide explains the available structure tags.
Build a list of actual published addresses rather than guessing every old URL from today’s title. Use the site’s current sitemap, content list and available link or access reports. Include older posts, valuable downloads and special post types that the proposed change might affect.
Record an intended destination beside every affected address. These are fictional mapping examples:
| Old path | Intended destination | Reason to verify |
|---|---|---|
| /2024/05/repair-guide/ | /repair-guide/ | Same article after removing the date structure. |
| /brake-repiar/ | /brake-repair/ | One corrected slug; other articles should remain unchanged. |
| /2023/09/workshop-news/ | Decision required | The old announcement may have no relevant replacement. |
Do not send every old page to the homepage merely to eliminate visible errors. Identify the closest genuine replacement where one exists. A page that is no longer available may need an honest not-found response rather than an unrelated destination.
Make recovery practical before editing
WordPress’s backup handbook distinguishes files from the database: a typical full recovery needs both. For this change, also preserve the current redirect configuration and the permalink setting. Knowing those values can make a focused reversal easier than restoring the whole website.
Use a staging copy when available to rehearse the structure and redirect logic. Check that its own domain and access controls remain appropriate. A staging success is useful evidence, but the live server, caches and redirect layers still need checking.
Choose a quiet change window and decide who can restore the previous configuration if the new addresses fail. For an active shop or membership site, a broad database rollback can overwrite new activity. Prefer a configuration repair when it solves the problem; our WordPress recovery guide covers checking that recovery is usable.
Prepare redirects without assuming WordPress covers everything
WordPress has an old-slug redirect function, but its documented source applies conditions and explicitly skips hierarchical post types. That is not a guarantee that every historical address, archive or changed structure will redirect. See wp_old_slug_redirect for the limited mechanism.
Choose a redirect implementation supported by your host or existing site tools. For permanent moves, Google recommends server-side permanent redirects where possible, including HTTP 301 or 308. See Google’s redirect guidance. The right implementation depends on the server; one copied rule is not a universal configuration.
Test a pattern against exceptions before applying it broadly. A rule that removes every numeric path segment could also affect a product identifier or an unrelated page. Keep the original-to-destination table as your acceptance list even if a pattern implements most of it.
Apply the smallest intended change
- For one post, open its settings, inspect the complete current address and change only the intended slug. Save or update the post.
- For the overall format, open Settings, Permalinks, choose the reviewed structure and save it. Leave category and tag bases unchanged unless they are explicitly part of the plan.
- Apply the prepared redirects in coordination with the new destinations becoming available.
- Read any server-configuration notice before assuming the change is complete.
The Permalinks documentation describes Apache .htaccess-related rewrite notices. That does not make an Apache file the correct fix for every server. WordPress has separate Nginx configuration guidance. Ask the host to verify routing for the actual installation when needed; avoid removing security rules or broadly relaxing file permissions.
Check the setting once and investigate the result. Repeatedly switching between formats without recording what changed makes broken routes and cached redirects harder to understand.
Align the links that advertise the new URLs
Update links you control in navigation, articles, buttons and related-content blocks. Check relevant canonical metadata and sitemap output too. Google’s URL migration guidance recommends mapping old and new addresses and updating the signals that point to them.
A canonical annotation helps identify a preferred version to search engines; it does not move a visitor from a broken old address. Google also advises consistency between canonical annotations, sitemaps and internal links. See its canonicalisation guidance.
Check important external profiles and campaigns you can edit. Their links should use the intended destination rather than adding an avoidable redirect. Preserve useful query parameters deliberately; do not assume a rule handles every tracking or application parameter safely.
Verify old and new routes separately
- Open each important new URL while logged out and confirm the intended content, images and page title.
- Open its old URL and inspect the redirect destination and status using the browser’s network tools or a suitable HTTP check.
- Check that the redirect reaches the final destination without a loop or an unnecessary chain.
- Test an unaffected page, a category/archive route and any essential form or shop journey.
- Inspect the sitemap and a representative canonical value for the intended new address.
- Record the test time and failures before clearing relevant caches and checking again.
A homepage that loads does not establish that dated article links, pagination or special content still works. For a large archive, a URL-list check is more useful than a few random clicks; investigate exceptions instead of accepting a high success percentage that misses your important pages.
Monitor, troubleshoot and retain the redirects
New URLs return 404: inspect permalink routing and the server notice before rewriting content. Only old URLs fail: inspect the redirect mapping. A loop appears: compare host, CDN, plugin and application rules for conflicting destinations. Search still shows an old URL: compare crawl timing and current output before changing the configuration again.
Google recommends keeping migration redirects as long as possible, generally at least a year, and notes that search visibility can fluctuate while the change is processed. Its current move guidance says Change of Address is not needed for path changes within the same domain. Keep monitoring broken links and update the links you own rather than treating the migration as finished immediately after saving.
Proceed when the destinations, redirects and recovery route have been verified. Keep the existing structure when the benefit is small and the migration plan is incomplete. A stable, understandable address is valuable because readers can continue reaching the answer they wanted.
Sources and verification
Editorial review 2026-10-13. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- WordPress: post and page settings sidebarChecked Individual post/page slug controls differ from site-wide structure; published permalink viewing.
Limits: Current documented interface, not a UI test on a particular WordPress version; no universal automatic old-page redirect promised. - WordPress: Settings Permalinks screenChecked Global structure options, separate category/tag bases, Save Changes and Apache-related rewrite notices.
Limits: Conflicting statements about installation defaults are not repeated; .htaccess guidance is not applied universally to Nginx or managed hosting. - WordPress: customise permalinksChecked Supported structure tags, post-name/date/custom structures and requirement for appropriate server routing. Plain uses an ID query; a post-name slug is a separate structure component.
Limits: Readable URLs are not presented as a guaranteed ranking improvement; no plugin-specific custom post-type behaviour assumed. - WordPress: backups handbookChecked Typical full WordPress recovery requires files and database.
Limits: Article recommends preserving settings/redirect configuration and focused repair, not a broad database rollback over newer shop/member data. - WordPress: old slug redirect implementationChecked Old-slug redirect is conditional, runs for certain 404/name cases and skips hierarchical post types.
Limits: No claim that WordPress never redirects old URLs, or that this function covers every slug, archive, structure or plugin route. - Google: redirects and SearchChecked Permanent server-side 301/308 guidance and environment-specific implementation.
Limits: No universal rewrite snippet, preserved ranking guarantee or site-specific deployment performed. - WordPress: Nginx handbookChecked Nginx has server-specific WordPress routing; Apache .htaccess is not the universal fix.
Limits: No sample configuration copied or server changed; the article asks host review of the actual installation. - Google: moves with URL changesChecked URL mapping, updating discovery links, generally at least one year redirect retention, potential temporary visibility changes and no Change of Address for same-domain path changes.
Limits: No fixed recovery timeline, traffic prediction or successful search migration inferred; examples and acceptance checklist are original editorial planning. - Google: canonical URL consolidationChecked Canonical, sitemap and internal-link consistency; annotation does not function as a visitor redirect.
Limits: No claim that a canonical fixes a broken old URL or forces Google to choose the declared URL.