Rewrite your slugs.
Redirect every URL.

Because neither gives you a redirect for the URLs you just changed. A direct database write skips the record WordPress uses to 301 the old address, so every renamed URL starts returning a 404 to anyone who had it bookmarked, linked or indexed. Slug Sync writes that record, exports the redirect map, shows you a collision-accurate preview before anything changes, and can undo the whole run afterwards. If nothing is indexed yet and the rename is all you need, WP-CLI is genuinely fine — use it.

Yes. Products are a public post type, so they are handled exactly like posts and pages, and they are the case the plugin was built for — imported catalogues are where slugs and titles drift furthest apart. Product variations are a separate post type and are never touched.

For posts, products and custom post types, no — the plugin records each previous slug the way WordPress does, so old URLs keep 301-ing to the new ones, and the exported redirect map is a second layer for anything you would rather handle in a dedicated redirect plugin. Pages are the exception: WordPress records old slugs only for content that does not nest inside a parent, so a renamed page needs the map rather than the built-in 301. One step is on you with the free plugin: purge your page cache and CDN once the run finishes. Pro does that for you. Sitemaps need no resubmission — Google retired its ping endpoint in 2023, so an accurate lastmod is what it reads now.

No. No item limit, no trial, nothing expires, and nothing in it today will move behind the paid add-on. Pro is separate code: it rewrites the title before a slug is built, syncs term slugs, and closes the steps a rename leaves open. It is not an unlock.

Pro is still in development and does not have a date yet. Join the waiting list on the Pro plan and you will get one email when it ships, and nothing else. The free plugin is finished and fully usable today — Pro adds title rules, term slug sync, and the follow-through after a run on top of it.

One purchase covers unlimited sites under the licensed email address, with no renewal and no site count to manage. The key is verified on your own server, so there is nothing to activate and nothing we can throttle.

The lower post ID keeps the clean slug and the other takes a numeric suffix, which is what WordPress does normally. Both are flagged in the note column of the report, so you can rename them properly if you would rather not have a suffix.

Yes. Every applied run gets a timestamped entry with an Undo button that restores the slugs recorded for that specific run. Anything you edited since then is skipped rather than overwritten.

WordPress has no old-slug redirect for terms at all. Renaming a category breaks its URL outright, with nothing catching the old one — and no redirect plugin fills that gap either, including the biggest of them, which monitors posts and pages only. That is exactly why term slugs are not in the free plugin: Pro syncs them and catches the old URL itself, alongside the exported redirect map.

No. Variations are a separate post type and are never listed.

Almost always a page cache. A cached page is served without WordPress running at all, so the 301 recorded against the old slug never gets the chance to fire. Purge the page cache and the CDN, then re-check in a private window, because a browser caches a 301 aggressively once it has seen one. If it still 404s, the post was not published when the run happened — draft permalinks are query strings rather than real URLs, so there is no old address to carry across. Pro purges the cache at the end of a run so this does not come up. If the URL was a page, there is a third cause: WordPress keeps no old-slug record for pages at all, so those rely on the exported redirect map rather than a built-in 301.

It renames them the same way, but the redirects work differently, and that is a WordPress limitation rather than a plugin one. WordPress only records a previous slug for content that does not nest inside a parent, so a renamed page gets no automatic 301 — import the exported redirect map instead. There is a second consequence worth knowing: a page's URL contains its parents' slugs, so renaming a parent also changes the URL of every page beneath it. Those child URLs are not in the reports, which list only the items whose own slug changed. Check what sits under anything you rename. Posts, products and custom post types are unaffected by either point, and the plugin says all of this on screen the moment you select a nesting type.

For posts, products and custom post types, no. WordPress itself 301s the old slug and the free plugin makes sure that record is written. For pages you do: WordPress keeps no old-slug record for content that nests inside a parent, so load the exported CSV into a redirect plugin after renaming any. Keep one anyway if you want manual redirects, regex rules or a site-wide 404 log — the CSV loads straight into it. The one thing no redirect plugin covers is terms: the largest of them monitors posts, pages and custom post types only, so a renamed category breaks its URL with nothing catching it. That is the gap Pro closes.

Left alone, WordPress keeps the original characters and the browser percent-encodes them, so Кофеварка becomes a 54-character slug beginning %D0%9A, and a Japanese title can run past 70. It works, but it is unreadable in a search result, unusable in a message, and a nightmare to read out over the phone. Pro's transliteration rewrites the title into Latin script first — Кофеварка to kofevarka, 咖啡机 to kafeiji — so the slug is legible before it is ever built.