Plan redirects for changed language URLs

POM Translate performs several current-state redirects, but it is not a historical redirect manager.

Redirects provided by routing

• A prefixed path that resolves to an object but does not match its current localized form receives a 301 redirect to that canonical path.
• An eligible unprefixed request receives a 301 when the base language is configured to use a subdirectory.
• Browser-language detection can send a visitor to a preferred locale with a 302 redirect.
• WordPress canonical redirects are adjusted so they do not strip a valid locale prefix or point away from the localized path.

These behaviors depend on the plugin being able to resolve the incoming address under the current slug data.

Changes that need a migration plan

Arrange explicit redirects outside the slug editor when you:

• replace a previously published localized post or term slug;
• change the base-language prefix setting;
• remove an enabled language;
• alter a post-type or taxonomy rewrite base;
• change a parent in a hierarchical page or taxonomy;
• replace a public custom URL used in campaigns or external sites.

Once an old slug is no longer stored, POM Translate may not know which object that historical value represented.

Publish a URL change safely

1. Record the old URL and its destination object.
2. Save the new slug or language setting.
3. Copy the newly generated canonical URL.
4. Configure a permanent redirect from the exact old address to the exact new address using your established redirect layer.
5. Preserve required query parameters where appropriate.
6. Test with redirect following disabled first.
7. Confirm one hop, status 301, final status 200, correct locale, canonical URL, and hreflang.
8. Update internal links and clear edge or page caches.

Avoid redirecting every old language URL to the home page. A one-to-one destination preserves visitor intent and search signals.