How to Write SEO-Friendly URLs and Restructure Them Without Losing Rankings

If you're about to publish a new page, or you're looking at an old one and wondering whether its address is holding it back, this guide walks you through both. By the end you'll be able to write SEO-friendly URLs for new pages, and you'll have a checklist for changing an existing address without wrecking the rankings that page has already earned. It covers one address at a time, so it doesn't get into site-wide folder structures or navigation redesigns.

Here's the short version. For a new page, pick a short, descriptive slug that tells a reader what the page is about, and separate the words with hyphens. For an existing page, first decide whether the change is really needed. If it is, send the old address to the new one with a permanent redirect, update the links and sitemap that point to it, and watch the results in Search Console. A permanent redirect does not lose PageRank by itself, but nobody can promise that rankings won't wobble for a while as Google recrawls the page.

A quick note on words. The URL is the whole address of a page. The slug is the readable part at the end that names the page, like seo-friendly-urls. We'll use slug examples throughout so we're not repeating full domains.

Step 1: Decide whether the address needs to change

Start with a question that saves a lot of people a lot of work: does this page need a new address at all?

If the page isn't published yet, you can skip ahead, because you get to choose the slug freely. If it's already live and indexed, write down the actual reason you want to change it. Good reasons look like a slug that misleads readers about what the page covers, or a page that has changed so much that its old name no longer fits. Before you commit, open Search Console and look at how the page is doing now, and check which important pages link to it. If you're not sure which pages are worth the effort, a content audit for decaying pages can help you rank them.

If the old slug is a little imperfect but still describes a page that's doing well, it's usually fine to leave it alone. Google's guidance favors descriptive addresses, but that isn't a promise that swapping one keyword variation for another will improve rankings. It's a judgment call about risk, not a rule with a threshold. Any change, even a small cosmetic one, creates a new address that has to be handled correctly.

You're done with this step when you've either decided to keep the published address, or you can say in one sentence why the new address is worth the migration.

Common mistake: Renaming every established page just to add a target keyword or swap out an underscore. That's a lot of moves for a benefit nobody has shown to be real.

Step 2: Write one readable slug for the page

This is the core of URL slug optimization, and it's simpler than most guides make it sound. Choose words that describe this specific page and that your audience would actually use. Keep the words you need to tell it apart from your other pages, and drop the rest.

A few habits cover most of it:

• Separate words with hyphens. Google recommends hyphens over underscores because they help people and search engines tell the words apart.
• Pick one capitalization style and stick with it. Lowercase is a sensible convention, though it isn't a Google requirement. Google treats different capitalization in a path as different addresses, so consistency is what matters.
• Use one clear topic phrase instead of several variations of it.
• Keep a word like "how" if taking it out would make the slug unclear. Stop words aren't banned.

Here's how that looks in practice.

These are examples of good editorial choices. They aren't proof that any particular slug earns a ranking boost. There's also no supported universal length limit, so don't chase a character count. Aim for clear and brief, and stop there. If you'd like a fuller picture of URL structure best practices, Google publishes its own URL structure guidance, and it's worth a read.

You're done when someone who has never seen the page can guess its topic from the slug, and the spelling is consistent with the rest of your site.

Common mistake: Treating the slug as a place to stuff every keyword you can think of. One natural topic phrase does more for a reader than five variants strung together.

Step 3: Check the actual address before you publish

The slug field in your editor and the address that ends up live aren't always the same thing, so preview the real one. Look for capitalization you didn't intend, repeated words, a string of generated numbers, and parameters that don't change what's on the page.

Parameters aren't bad by nature. If a parameter picks genuinely different content, or the page needs it to work, leave it. What you're trying to catch are the extras, like session IDs and tracking strings that create a new address without creating a new page. Google also advises against relying on a fragment (the part after a #) to show the main content of a page, since Google generally doesn't support fragments for changing content. If your address has non-English characters or special characters in it, make sure the links are correctly percent-encoded instead of assuming everything you can see is safe to paste.

Then pick a trailing-slash habit that matches how the page is really published. Google treats the slash and no-slash versions as separate addresses, and neither one has a ranking edge. What you want is for the alternates not to end up as competing live copies of the same page.

You're done when the intended address loads the intended page, and the other capitalization and slash versions either redirect to it or don't exist.

Pro tip: Check the final address in a browser after publishing, not just in the CMS preview. It takes ten seconds and catches most of the surprises.

Step 4: Record the old address and prepare the destination

This is where changing URLs SEO-wise gets serious, so slow down a little. Before you touch an established address, make a one-row record with the exact old address, the exact new one, who owns the change, and the date.

Then capture a baseline. In Search Console's Performance report, note the page's clicks, impressions, main queries, and average position over a period you can compare later. Also note whether the old address is currently indexed and which canonical Google picked for it. A baseline won't guarantee that your totals match afterward, but it gives you something real to compare against when you're trying to work out what happened.

Now get the destination ready. It should serve the page you intend, and it should still answer whatever the searcher came for. Check that crawlers can reach it, that it isn't carrying a leftover noindex tag or a robots rule from staging, and that if it declares a canonical, it declares itself and not the old address. Google specifically asks you to check the new page's canonical annotations and robots rules during a move. Keeping the useful substance of the page while changing only the address also makes the outcome much easier to read.

If the change is a big one, try to pick a quieter traffic period and a time when someone can test and fix things right away. Google gives that scheduling advice for site moves. You don't need to treat a particular weekday as a rule for a single page.

You're done when the destination is live-ready, matches the reason for the move, and you have the exact old-to-new pair written down.

Common mistake: Pointing the old address at a page that's only vaguely related, launching a thin replacement, or leaving a staging noindex in place. Each one quietly undoes the move.

Step 5: Publish the destination and redirect the old address

Make the destination live first. Then set up a server-side 301 or 308 redirect from the exact old address straight to the exact new one. Both of those codes tell search engines the move is permanent. A 302, 303, or 307 is a temporary redirect, and it's for moves that really are temporary. Where you set the redirect depends on your hosting, server, or CMS, so check how yours handles it.

Look for older redirects too. If some earlier address already points to the old page, update it so it goes directly to the final destination. Chains, where one redirect leads to another that leads to another, slow people down and make the setup harder to trust. Googlebot can follow up to 10 hops, but that's a technical limit and not a plan. If you can't avoid a chain, Google says ideally no more than 3 redirects and fewer than 5.

Test the two addresses separately. The old one should return a permanent redirect that lands in the right place, and the new one should load the real page, normally with a 200 status. You can check that with an HTTP status checker or your browser's developer tools. Open the page you land on and look at it, since a "saved" message in a CMS doesn't tell you what a visitor sees.

Keep the redirect in place for as long as you can, generally at least a year. Don't remove it just because the new page has started showing up in search, since people and links outside your control may still be using the old address. The redirect guidance from Google Search Central covers the details, and its site move documentation explains the timing advice.

You're done when a request for the exact old address reaches the correct new page in a single permanent redirect, and the new page serves successfully.

Common mistake: Sending the old address to "some working page" so it doesn't 404. If the page moved or has a clear equivalent, redirect to that equivalent. If you removed it and there's nothing similar to replace it, Google advises returning a 404 or 410 instead of inventing a destination. It's also worth knowing that a deleted page can't be promised its old rankings. If you're weighing a redirect against removing a page altogether, our guide to consolidating, redirecting, or deleting low-value pages helps you make that call.

Step 6: Line up the canonical, the sitemap, and your links

A redirect handles visitors and crawlers who arrive at the old address, but it isn't the only signal Google reads. The canonical, the sitemap, and your own links should all agree with it.

Start with links you control. Go through your existing pages and update any contextual links that point at the old address so they point straight to the new one. Check templates and reusable blocks too, since those can keep emitting the old address on many pages at once. This cuts out needless redirect hops and gives Google a direct route to the page. If you've never run a proper internal link audit, how to run an internal link audit walks through it, and if you need to fix links across a lot of older posts, there's a guide to adding internal links to an existing back catalog. Also confirm that at least one crawlable HTML link leads to the new page, which is a basic part of internal linking for AI search as well.

Next, set the new page's canonical to the new address. If you keep an XML sitemap, swap the old entry for the new, fully qualified address, and submit the updated sitemap in Search Console if that fits your setup. A sitemap is a hint and not an order, so submitting it doesn't guarantee that Google will crawl or index the page. Don't bump the last-modified date just to attract a crawl either. Google uses that date when it's consistently accurate, and it should reflect a significant update. Our piece on whether XML sitemaps help crawlers covers what a sitemap can and can't do.

There's one more distinction that trips people up. A redirect and a canonical annotation are not the same thing. A redirect sends visitors and crawlers to another address. A canonical annotation names a preferred version while the annotated page stays reachable. For a real permanent move, Google recommends a server-side permanent redirect when it's possible. A canonical annotation is the alternative when redirecting isn't an option, for example if both slash versions have to stay reachable.

You're done when your internal links, the sitemap entry, and the new page's canonical all point to the new address, and a crawlable link reaches it directly.

Common mistake: Leaving a self-referencing canonical on the old address, or keeping both the old and new versions in the sitemap as if both were preferred. Mixed signals make it harder for Google to settle on the address you want.

Step 7: Inspect both addresses after the change

Once the redirect is live, open Search Console and check both addresses, because they tell you different things.

For the new address, use the URL Inspection tool. Read the indexed result and the page indexing section, including the canonical Google selected. Then run Test live URL to see how the page looks to Google right now. If the page is eligible but hasn't been recrawled yet, you can use Request indexing for that single address. Google's URL Inspection help page explains what each view means.

The two views aren't the same. The ordinary inspection shows the version Google most recently indexed, and the live test fetches the page today. The live test also can't predict which canonical Google will choose in the end, and it doesn't check every indexing condition. Google says an indexing request often takes about a day, but it can take longer, including a week or two, and a request doesn't guarantee inclusion.

For the old address, check that it redirects. In the Page indexing report, "Page with redirect" is an expected, non-indexed status for a former address. It isn't a problem, and it doesn't say anything on its own about whether the new page got indexed. If you're also thinking about how Search Console compares with AI visibility reporting, this comparison of DeepSmith and Google Search Console explains why you still need Search Console for the Google side.

You're done when the new page passes the live test, you can see its indexed status and Google-selected canonical as Google processes them, and the old address redirects where it should. If the indexed data hasn't caught up yet, write that down and keep monitoring.

Common mistake: Reading "URL is on Google" as proof of ranking, or treating the old address's "Page with redirect" status as something broken. Repeatedly requesting indexing won't fix a destination that's blocked or points its canonical somewhere else, and there's a separate guide on getting crawlers to recrawl updated content faster if speed is your concern.

Step 8: Monitor performance and fix what breaks

The last step runs for a few weeks, and it's mostly patient watching. In Search Console's Performance report, use the Pages dimension and compare the same date ranges you used for the baseline. Look at clicks, impressions, queries, and average position together, since one day's average position isn't a verdict. Recent data can be preliminary, and page-level reporting can be a little messy when a canonical changes, so a simple old-row-plus-new-row comparison won't always add up cleanly.

Also check the Page indexing report, inspect both addresses again, and skim your server or CMS error logs for surprise 404s, loops, or redirects landing on the wrong page.

If visibility drops, work through the causes in order:

1. Does the old address permanently redirect to the right page?
2. Does the new page load successfully?
3. Is the new page crawlable and indexable?
4. Is its canonical the new address?
5. Do your internal links and the sitemap agree?
6. Is the new page still a useful answer for the searcher?

Fix a technical mismatch before you assume the slug itself caused the drop. Google says that bigger moves can cause temporary ranking changes while it recrawls and reindexes. Its statement that permanent redirects don't lose PageRank is a statement about link signals, and it isn't a promise that rankings, clicks, or recovery dates will match what you had before. If someone asks you for an exact recovery date, it's fine to say that nobody can give one. Broken or made-up addresses are a related case, and we cover whether to redirect AI-hallucinated links separately. If you'd like a bigger picture of how this works when a whole site moves, there's a helpful piece on enterprise site migration and AI visibility.

You're done when the redirect is still in place, you understand the new page's indexing and canonical status, you've compared its performance against the baseline, and every error has an owner and a fix.

Common mistake: Removing the redirect after a few days, or reading normal processing lag as proof the page is broken.

Quick checklist for the whole process

What to do next

Apply the slug habits from Step 2 to the next page you publish. That's the easy win, because you're choosing an address before anything depends on it. Then pick one existing address that has a real reason to change and run the migration checklist on it as a small pilot. Once you've done it once, the rest of your pages get a lot less scary.

If you'd like some help with the production side, DeepSmith's Content Studio shows publishing metadata, including a slug, and it builds internal links against your sitemap while it generates an article, so a new piece goes out with its slug, metadata, and links already in view. Redirect rules, sitemap submission, and the post-change checks still belong to you and your CMS. You can start a 7-day free trial of DeepSmith and see how it fits into your publishing routine.