How to Change URL Slugs Without Losing SEO
Changing a URL slug after a page is already indexed and receiving traffic is one of the riskier SEO operations you can perform — and one of the most common. Poor slug choices made at launch, CMS migrations, site rebrandings, and content reorganizations all create scenarios where URLs need to change. This guide explains how to change URL slugs safely, preserve your SEO equity, implement proper redirects, and monitor the transition so you can catch any problems quickly.
When to Change a URL Slug — and When Not To
Not every imperfect URL slug is worth changing. The decision depends on the page's current SEO performance and the magnitude of the improvement the new slug provides. Change the slug when: the current slug is genuinely harming discoverability or click-through rate — for example, it contains the wrong keyword entirely, or it is a meaningless auto-generated ID like post-4827. Change it when the content has been substantially republished under a new topic focus and the current slug no longer reflects the page's target keyword. Change it during a planned site migration where URL structure changes are unavoidable and being handled systematically. Do not change the slug when: the page ranks well for its target keyword and the slug is merely imperfect rather than wrong. A slug like create-seo-slugs that ranks on page one does not need to become create-seo-friendly-url-slugs. Changing a high-performing URL slug risks disrupting the ranking even with a perfect 301 redirect. The redirect preserves most but not all of the original URL's equity, and the re-indexing process introduces a window of ranking volatility. Do not change slugs in bulk without testing. Changing hundreds of URLs simultaneously multiplies the risk of redirect configuration errors, missed redirects, and canonical tag conflicts. If you must change many URLs, do it in batches and monitor each batch before proceeding. The cardinal rule: the higher the page's current organic traffic, the more carefully you should evaluate whether the SEO benefit of the new slug justifies the migration risk. For pages with minimal organic traffic, slug changes carry low risk and are worth doing for housekeeping purposes. For your top-performing pages, set a high bar.
Implementing 301 Redirects Correctly
A 301 redirect is a permanent redirect that tells browsers and search engines: this resource has permanently moved to a new URL. It is the mechanism that preserves your SEO equity when changing a URL slug. A 301 redirect passes approximately 90 to 99 percent of the original URL's link equity to the new URL, according to Google's consistent statements over many years. The remaining fraction is the technical cost of the redirect hop. For pages with extensive backlink profiles, this small loss is real but typically does not produce meaningful ranking drops if the redirect is implemented correctly. On WordPress, 301 redirects for slug changes can be implemented with a plugin like Redirection or RankMath Pro's redirect manager. When you change a post's slug, some plugins automatically create a 301 from the old URL. Verify that the redirect is active by testing the old URL in your browser or with a redirect checker. On Shopify, redirects are managed under Online Store > Navigation > URL Redirects. Adding a redirect here creates a 301 from the old path to the new path. Shopify does not automatically create redirects when you change a product URL handle — you must manually add the redirect after making the handle change. On Nginx, add a redirect to your server configuration: return 301 https://example.com/new-slug; On Apache, add a redirect to .htaccess: Redirect 301 /old-slug https://example.com/new-slug After implementing the redirect, test it with a tool like httpstatus.io or by checking the response headers in your browser's developer tools. Confirm the response code is 301 (not 302, which is temporary) and that the Location header points to the correct new URL. Test the redirect chain — if the new URL itself redirects again, you have a redirect chain that should be resolved by pointing the original redirect directly to the final destination.
Updating Internal Links and Canonical Tags
A 301 redirect handles external links and search engine indexing, but internal links pointing to the old URL should also be updated to avoid unnecessary redirect hops on every internal page load. Internal redirect hops waste crawl budget on large sites, slow page load for the small number of users who follow them, and create a technical debt that accumulates if never cleaned up. After changing a URL slug, run a site crawl with a tool like Screaming Frog or Sitebulb to find all internal links pointing to the old URL. Update those links to point directly to the new URL. For WordPress sites, the Better Search Replace plugin can batch-update links across your entire database — replacing old URL references in post content, widgets, menus, and theme options. Run this carefully on a staging environment first to confirm the replacement scope before applying to production. The canonical tag on the new URL should self-reference the new URL. If the canonical tag was not updated during the slug change and still points to the old URL, you have created a canonical conflict: the page is served at the new URL but declares the old URL as the canonical. Search engines will be confused about which URL to index. Verify the canonical tag after every URL change. Your XML sitemap should be updated to include the new URL and remove the old one. Most CMS sitemaps auto-regenerate on a schedule, but force a regeneration after a bulk URL change to ensure Google's next crawl discovers the updated URLs quickly. Update any hardcoded links in your theme header, footer, navigation menus, and sidebar widgets. These are easy to miss during an internal link audit because they do not appear in post content but are served on many or all pages of your site.
Monitoring After Changing URL Slugs
The monitoring period after changing URL slugs is as important as the migration itself. Issues that were not visible in testing often emerge once real users and crawlers encounter the new URLs at scale. After implementing the redirect and updating internal links, submit the new URL for indexing in Google Search Console using the URL Inspection tool. Request indexing to speed up Google's re-crawl of the new URL and its discovery of the 301 redirect from the old URL. Monitor Google Search Console for coverage errors on the old URL. After Google processes the 301 redirect, the old URL should transition from Indexed to Redirected in the Coverage report. This transition may take one to four weeks depending on your crawl frequency. If the old URL remains indexed without redirecting, check that your 301 is correctly configured. Track organic traffic to the affected pages using Google Analytics or Search Console's Performance report filtered to the new URL. Compare week-over-week traffic for two to four weeks post-migration. A temporary dip during re-indexing is normal and expected. A sustained decline suggests the redirect is not passing equity correctly or the new URL has a different canonical or indexability issue. Check your backlink profile for links pointing to the old URL. Reach out to major referring domains to update their links to the new URL directly — this eliminates the redirect hop for those links and ensures maximum equity transfer. For minor referring domains, the 301 redirect handles the equity transfer adequately without outreach. Set up an alert in Search Console to notify you of any new 404 errors in the Coverage report. New 404s during a post-migration monitoring period typically indicate missed internal links or external links that were not covered by your redirect implementation.
Frequently Asked Questions
- How long does it take for Google to index a new URL after a 301 redirect?
- Google typically discovers and processes a 301 redirect within one to four weeks for pages that are regularly crawled. High-traffic, frequently updated sites with strong crawl budgets may see the transition within days. Smaller sites with infrequent crawls may take longer. You can accelerate the process by submitting the new URL for indexing via Google Search Console's URL Inspection tool and ensuring the new URL is included in your XML sitemap. Monitor the Coverage report in Search Console for the old URL's status to confirm when Google has processed the redirect.
- Do 301 redirects lose any link equity?
- Google's official position is that properly implemented 301 redirects pass the link equity (PageRank) from the old URL to the new URL. In practice, most SEOs observe a small, temporary ranking dip after URL changes even with correct 301s, which typically recovers within a few weeks as Google re-evaluates the new URL. The consensus estimate is that 301s retain 90 to 99 percent of link equity. Redirect chains (A redirects to B which redirects to C) lose more equity at each hop — which is why you should always point redirects directly to the final destination URL rather than through an intermediate step.
- Can I change a URL slug back to the original if the new one hurts rankings?
- Yes. If you change a slug and observe a significant ranking drop that does not recover after four to six weeks, reverting to the original slug is a valid recovery option. Change the slug back to the original, remove or update the 301 redirect, update internal links to the original URL, and update the canonical tag. The original URL will need to be re-indexed, which again takes one to four weeks. Document the before-and-after traffic data carefully so you can evaluate whether the revert actually caused recovery or whether other factors were at play.