WordPress 301 Redirects: Move a Page Without Breaking Links

WordPress & Web Development / URL changes

To move a WordPress page permanently, redirect its old URL to the closest relevant new URL with an HTTP 301 response. Confirm that the destination works, add one narrowly scoped rule, and test the old address while logged out. Then update your own links to point directly to the new address.

A redirect is useful when a page actually moves. It is not a reason to keep renaming URLs, a substitute for fixing broken content, or a guarantee of unchanged search rankings. The practical goal is straightforward: someone following an old bookmark should reach the information they expected.

This guide covers ordinary public content pages and posts. Form submissions, checkout endpoints, APIs, and login flows need separate application-aware handling. Documentation reviewed on 24 October 2026.

Choose 301, 302, or no redirect

A 301 says the resource has a permanent new address. A 302 represents a temporary move. Google recommends permanent server-side redirects when you want a changed URL reflected in Search; its redirect documentation distinguishes permanent and temporary signals. Choose according to the intended move, rather than whether a tool makes one option easier to select.

The HTTP standard also defines 307 and 308 redirects that preserve the request method. In contrast, clients may change a POST request to GET after a 301 or 302. That distinction is documented in RFC 9110; it is why a content-page recipe should not be copied blindly onto a payment callback.

For removed pages, return the status you intend. Google’s HTTP status guidance explains that 4xx URLs are removed from its index over time, while an error-looking page returned with 200 can become a soft 404. A custom “not found” design still needs the correct response.

Does WordPress redirect an old slug automatically?

Sometimes. WordPress includes an old-slug redirect handler that attempts to find a post from a previous slug and sends a 301 when it finds a match. Its implementation explicitly skips hierarchical post types. Ordinary pages are therefore a different case from standard blog posts; other plugins or hosting rules may add behavior of their own.

Do not assume that a successful redirect for one post proves that a page, category change, or entire permalink restructure is covered. Request the exact old address and inspect what your site actually returns. If it already reaches the correct final URL with the intended status, record that behavior before adding another rule.

Map old URLs before editing anything

Make a small change record containing the full old address, intended destination, reason, owner, and date. Add the redirect location too: WordPress, hosting configuration, or CDN. This gives the next administrator somewhere to look when a rule behaves unexpectedly.

The following is a hypothetical mapping for a business site, not a set of rules to import unchanged:

Open every destination before changing the source. Check its content, publication status, and public accessibility. A live page with the wrong information is still a bad destination. When consolidating several pages, confirm that the consolidated page actually covers the needs previously served by each one.

Keep a recoverable backup and a copy of the current redirect rules. Ryvenora’s explanation of WordPress exports versus full backups helps distinguish a content export from a recovery copy that includes configuration and files. For a small URL change, also record the exact rule you will disable if testing fails.

Create a narrowly scoped single-page redirect

First identify the redirect facility already used on the site. Avoid spreading the same move across several plugins and infrastructure panels. If a maintained redirect manager is already available, use its documented workflow. A host-managed rule can also be appropriate; ask which layer owns the URL before editing server configuration.

For a concrete WordPress example, the Redirection plugin’s create and manage guide documents source and target rules. For the hypothetical first mapping above:

1. In the redirect manager, create a rule with source path /website-care/.
2. Set the target to the complete intended HTTPS URL, such as https://example.com/wordpress-maintenance/.
3. Choose the permanent 301 status for this permanent move.
4. Keep regular-expression matching off for this one exact path.
5. Review the query-string and trailing-slash options, then save and test.

Field names and placement can vary by tool. This is a rule specification, not a claim that the plugin is installed on your site or that every interface looks identical.

Decide what query parameters should do

A visit to /website-care/?utm_source=newsletter is worth testing separately. Redirection’s URL matching documentation distinguishes exact query matching, ignoring parameters, and ignoring while passing them to the target. It also describes case and trailing-slash options.

Choose deliberately. Tracking parameters may need to survive a move; a parameter that selects a product, language, or account action may change the meaning of the request. Do not turn on “ignore everything” without checking real inbound URL examples. Keep a parameterized test alongside the plain-path test in your change record.

Test the response, then read the destination

Use a logged-out browser session to open the full old URL. Confirm the address changes to the exact destination and that its content is usable on mobile as well as desktop. Then inspect the browser’s Network panel, keeping requests visible across navigation, or use an HTTP redirect checker that shows each response.

A simplified hypothetical response for the old address would look like this:

HTTP/1.1 301 Moved Permanently
Location: https://example.com/wordpress-maintenance/

Follow the destination and verify a successful response containing the intended page. Merely seeing “200” is insufficient: a login screen or a branded error message can also be returned incorrectly with that status. Google’s status-code documentation notes that successful responses do not guarantee indexing.

• The exact old URL returns the intended redirect status.
• The Location value points to the final public address.
• The final page loads without another content-move redirect.
• Important query parameters behave as planned.
• A nearby unrelated URL is unaffected.
• The new page’s links, images, and primary action still work.

If you use a patterned rule later, add negative tests: addresses that look similar but must not match. For instance, moving one service page should not silently capture every URL containing the word “care.” Test the boundary of a rule as carefully as its intended match.

Fix chains, loops, and unexpected results

The old URL reaches another old URL

A chain has an intermediate stop: the first address redirects to a second address, which redirects again. Edit your content-move rule to use the final destination where possible. Google recommends direct destinations in its site-move guidance. Check whether HTTPS or hostname normalization adds another hop before deciding which rule needs changing.

The browser reports too many redirects

A loop sends a request back to a previously visited address. Look for opposing rules, a target that matches its own source pattern, or conflicting hostname and HTTPS rules. Write down each observed Location value. Disable or correct the specific offending rule, then test again; avoid making several unrelated changes at once.

You changed the rule, but the old behavior persists

A 301 can be cached under the HTTP specification. Check the browser, WordPress cache, host cache, and CDN as separate possible locations. Redirection’s troubleshooting documentation also flags caching and Cloudflare among common problems. Clear the relevant cached response and repeat a fresh request rather than repeatedly editing a rule that may already be correct.

Every missing page goes to the homepage

Replace that blanket approach with reviewed mappings. Google’s migration guidance warns that irrelevant mass redirects can confuse visitors and be treated as soft 404s. Keep a real not-found response where no suitable replacement exists. Fixing a genuine broken inbound link is different from hiding every error.

Update links and monitor the move

Update your own links, navigation entries, and campaign destinations to the new address. Check the canonical URL and sitemap for consistency. Google’s canonicalization guidance recommends consistent canonical signals and internal links to the preferred URL. A canonical annotation does not navigate a visitor away from a broken old address.

Review redirect and 404 logs after the change. Redirection’s logging documentation describes records including visited URL, target, time, and request method. Use these to identify missed variants, while choosing a logging scope and retention period appropriate for your site. A rule with no recorded hits may be unused, or logging may simply be disabled.

For broader migrations, Google advises keeping redirects for at least a year and preferably longer where useful. Keep your mapping and revisit it during later redesigns so old rules continue pointing to current destinations. Monitor Search Console for unexpected errors, but do not promise a particular reindexing date or unchanged traffic.

Frequently asked questions