# Changing your URL structure: when it is worth it and how to do it

You only change URLs when the structure holds you back. This guide shows when it is worth it, how to plan it, and how to run it without losing search traffic. It is written for founders who ship their own sites.

Updated 2026-09-14 · Source: https://porteur.ai/guides/changing-url-structure

## When a URL change is worth it

Change URLs only when the current structure creates real problems for users or crawling. A tidy structure helps maintenance, internal linking and analytics. It does not create rankings by itself.

- A broken hierarchy. Example: /blog/post, /docs/getting-started and /pricing are fine, but /kb123 and /oldcontent/2020/scattered break patterns and make breadcrumbs unclear.
- Dates or IDs in slugs you cannot maintain. Example: /blog/2021/how-to-invite-users ties you to the year. Move to /blog/invite-users.
- Parameters in place of paths. Example: /product?cat=blue&sort=popular. Create clean paths like /products/blue?sort=popular or, if filters are crawlable, use a faceted plan.
- Merging duplicate sections. Example: /help and /docs cover the same content. Pick one and redirect the other.
- Protocol or host changes you should do anyway. HTTP to HTTPS, or www to non-www, or a domain change for branding.

A fixed page looks predictable. Example: /guides/getting-started lives under /guides, with /guides/ and /guides/getting-started both internally linked from /guides/ and the breadcrumb shows Guides > Getting started.

## When to leave URLs alone

Do not change URLs for keywords in slugs. It rarely pays for a small site and risks a dip while Google reprocesses signals.

- Cosmetic changes only. Replacing /pricing with /plans for style is not worth a migration.
- Plural or hyphen tweaks. /feature -> /features, or /gettingstarted -> /getting-started, if the current pages rank and earn clicks.
- A new CMS default slug format when you can keep the old format. Many systems let you set the slug per page. Use that, avoid a sweep.

> Rule: if you cannot map every old URL to a single clear new URL, do not proceed yet.

## Plan the move and map every URL

The redirect map is the job. It is a two column table kept in your repository: old URL, new URL. Build it before you touch routes.

1. **Crawl the old site** Use your crawler to fetch every URL that returns 200 and any redirects in front of them. Export to CSV. Include query parameter patterns if used.
2. **Pull sitemaps and Search Console data** Download the current XML sitemap set. In Search Console, export indexed pages and top linked pages. Add them to the list so nothing is missed.
3. **Decide the new structure** Write the new paths in a spec. Example: /kb/* becomes /guides/*, /blog/YYYY/* becomes /blog/*, /product?cat=blue becomes /products/blue.
4. **Map one to one** For each old URL, pick one new URL. No many to one unless the content is merged and the new URL is the canonical replacement. Do not map to the home page.
5. **Flag gaps and collisions** If an old URL has no replacement, decide 410 only if the content is removed with no successor. If two old URLs map to one, choose a canonical new page and merge content first.

Name the file redirect-map.csv and store it next to your routes. Treat it as code. Review it like any other pull request.

## Build and test redirects

Apply the map at the edge or the server. Use 301 for permanent moves. Keep the hop count to one. Avoid redirect chains and loops.

```en
# nginx example using a map
map $request_uri $redirect_to {
  include /etc/nginx/redirect-map.conf; # generated from redirect-map.csv
}
server {
  # 443 is the standard HTTPS port
  listen 443 ssl;
  if ($redirect_to) { return 301 $redirect_to; }
}

# redirect-map.conf
/old/kb/how-to-export  https://yourproduct.com/guides/export-data;
/blog/2021/invite-users https://yourproduct.com/blog/invite-users;
```

```en
// next.config.js redirects example
module.exports = {
  async redirects() {
    return [
      { source: '/old/kb/how-to-export', destination: '/guides/export-data', permanent: true },
      { source: '/blog/2021/:slug', destination: '/blog/:slug', permanent: true },
    ];
  },
};
```

1. **Deploy to a staging host** Mirror production data if you can. Load the redirect rules there first.
2. **Test every old URL** Write a script to request each old URL, follow redirects, and assert the final status is 200 and the hop count is one. Fix misses fast.
3. **Check internal links still resolve** Crawl staging starting at /. Confirm there are no 3xx or 404 on internal links. Update links now, not after the switch.

> Do not redirect old URLs to the home page. At scale this looks like a soft 404 pattern to Google.

## Update internal signals to the new URLs

Align every hint your site gives. Consistency speeds up processing and avoids mixed signals.

- Update all internal links to point to the new URLs. Do not rely on redirects for internal navigation.
- Set rel=canonical tags to the new URLs. Remove canonicals that point to old hosts or old paths.
- Update hreflang link elements to the new URLs if you run variants. Keep region and language codes the same.
- Regenerate your XML sitemaps with only the new URLs. Submit the new sitemap index. Keep the old sitemap accessible for a while.
- Update structured data that contains URLs, such as Organization, BreadcrumbList, Article or Product. Point to the new pages.
- Fix breadcrumbs to match the new hierarchy. Example: Home > Guides > Export data, linking to /guides/ and /guides/export-data.

A fixed page after this step has an internal link to /guides/export-data, a canonical of https://yourproduct.com/guides/export-data, and a matching breadcrumb and sitemap entry.

## Keep the old URLs alive and tell Google

Keep the old host serving 301s for as long as you can. At least a year. Longer is better when possible, as of 2026.

1. **Launch during a calm period** Do not pair the move with a redesign or content rewrite. Move one thing at a time so you can attribute any change.
2. **Submit sitemaps** In Search Console, submit the new sitemap index. Keep the old sitemap listed so Google can re-crawl and see the redirects.
3. **Verify properties** Verify both old and new properties. For a domain change, use the Change of Address tool once 301s are live and both properties are verified.
4. **Monitor crawl and errors** Check the Page indexing report and the Crawl stats report. Fix stray 404s and unexpected 200s on old paths quickly.

For a domain change, the Change of address tool is in Settings. It works for domain-level moves, not for path-only or HTTPS-only moves.

## Special cases you likely face

| Move type | Use Change of Address tool | Key actions |
| --- | --- | --- |
| Domain change, example: example.com to yourproduct.com | Yes | 301 every old URL to its new domain twin, verify both properties, submit the request, keep redirects for at least a year |
| Host normalisation, www to non-www or vice versa | No | Pick one host, 301 the other on every path, set canonicals to the chosen host, verify a Domain property to cover both |
| HTTP to HTTPS | No | 301 each HTTP URL to its HTTPS twin in one hop, update canonicals, sitemaps, hreflang and links, avoid mixed content, consider HSTS |
| Trailing slash policy, /page vs /page/ | No | Choose one, 301 the other, keep internal links consistent across the site |
| Path restructure, example: /kb/* to /guides/* | No | Map one to one, 301, update links, canonicals, structured data and sitemaps |

Google treats www and non-www as different hosts. Choose one and be consistent. Verify a Domain property so you see all hosts in Search Console.

/page and /page/ are different URLs. The root / is the exception. Choose a form per section and redirect the other. Keep internal links in one form only.

For HTTPS, treat it as a site move. One hop 301 to HTTPS, update every signal, and check for mixed content. Browsers mark HTTP as not secure. Google has treated HTTPS as a lightweight ranking signal since 2014.

## Next.js specifics that matter in a move

- Use redirects in next.config.js for one to one rules. Keep permanent: true for 301.
- Set trailingSlash in next.config.js to enforce your chosen slash policy site wide.
- Use the Metadata API to set alternates.canonical per page. metadataBase helps build absolute URLs.
- Update app/sitemap.ts to emit only new URLs. Keep the old sitemap XML accessible elsewhere for a while.
- Update app/robots.ts if you disallow paths that change. Keep robots.txt stable during the move unless you must change it.
- Use next/image and next/font to control performance, but remember the framework does not write titles, choose canonicals, or make content worth indexing.

```en
// next.config.js
const isProd = process.env.NODE_ENV === 'production';
module.exports = {
  trailingSlash: false,
  async redirects() {
    return [
      { source: '/kb/:slug*', destination: '/guides/:slug*', permanent: true },
      { source: '/blog/:year(\\d{4})/:slug', destination: '/blog/:slug', permanent: true },
    ];
  },
};

// app/sitemap.ts
import { type MetadataRoute } from 'next';
export default function sitemap(): MetadataRoute.Sitemap {
  return [
    { url: 'https://yourproduct.com/guides', changeFrequency: 'weekly' },
    { url: 'https://yourproduct.com/guides/export-data', changeFrequency: 'monthly' },
  ];
}

// app/route.ts example for canonical
export async function generateMetadata() {
  return {
    alternates: { canonical: 'https://yourproduct.com/guides/export-data' },
  };
}
```

## What to expect after the switch

Expect fluctuation for some weeks. Some queries will dip before they come back. Watch Search Console and logs rather than rankings alone.

- Track clicks and impressions on the new URLs. Use the Page filter in the Performance report to compare old and new paths.
- Use the URL Inspection tool on a few mapped pages. Confirm Google sees the redirect and the new canonical.
- Watch the Page indexing report for spikes in Not found errors. Fix missed redirects or typos fast.
- Look for soft 404 detections. They can point to many old URLs redirected to weak or irrelevant pages.
- Keep the old sitemap accessible for a while so Google recrawls the legacy URLs and follows the 301s.

If you merged pages, update internal links to favour the new canonical URL. If a page underperforms after the move, review the content and its internal links first.

## Questions

### Will changing my URL structure improve rankings?

Not by itself. A cleaner structure helps crawling, internal linking and maintenance. If your current URLs cause duplication, parameters everywhere, or dead hierarchies, fixing them can remove friction. Expect a short dip while Google processes the redirects and new signals.

### How long should I keep redirects from old URLs?

As long as possible. Keep them for at least a year. Google’s guidance, as of 2026, is to keep redirects permanently when you can. There is no benefit to removing them early.

### Do I need to use the Change of address tool?

Use it only for a domain-level move, for example example.com to yourproduct.com. You need both properties verified and the 301s live first. It does not apply to path changes or HTTPS-only moves.

### Can I change only some slugs and leave the rest?

Yes, but map every changed URL one to one and update internal links and canonicals. Mixed policies, like sometimes using a trailing slash and sometimes not, create duplication. Be consistent in the sections you touch.

### What should I do with query parameters during a restructure?

Keep parameters for state, like sort and filters, but prefer clean paths for core categories. Map parameterised legacy URLs to the closest new path. Avoid creating many crawlable URLs for thin combinations.

### How do I test the migration worked?

Run a script against every old URL to confirm a single 301 ends in 200 on the new page. Crawl the new site for stray 3xx and 404 on internal links. In Search Console, check the Page indexing and Performance reports for the new URLs taking over.

## Read next

- [Website migration SEO checklist: before, during, after](https://porteur.ai/guides/website-migration-seo-checklist): Run a safe website migration: crawl and export, build and test one-to-one redirects, switch cleanly, submit sitemaps, use Search Console, and watch the data.
- [Build a redirect map: one old URL, one new URL, tested](https://porteur.ai/guides/redirect-map): A practical redirect map: where to find old URLs, how to match them, store the table, apply 301s, and test every row for one hop and a 200.
- [Changing your domain without losing search traffic](https://porteur.ai/guides/domain-change-seo): Change domains without tanking your rankings. Map 301s one to one, use Change of Address, update canonicals and hreflang, and keep redirects for a year.
- [www or non-www: pick one, redirect the other](https://porteur.ai/guides/www-vs-non-www): Pick www or non-www, there is no SEO gain either way. 301 redirect every path to the chosen host, set canonicals, and verify a Domain property.
- [Trailing slash: two URLs for one page unless you decide](https://porteur.ai/guides/trailing-slash-seo): Google sees /page and /page/ as different. Pick one form, redirect the other, and keep links and your sitemap consistent. Here is how to do it.
- [Moving from HTTP to HTTPS: the checklist that keeps rankings](https://porteur.ai/guides/http-to-https-migration): Move from HTTP to HTTPS without losing rankings. Use one-hop 301s, update canonicals and sitemaps, fix mixed content, and verify the HTTPS property.
- [URL](https://porteur.ai/glossary/url): A URL is a page’s address. Learn its parts, why variants split equity, what a good URL looks like, and what to fix on a small site.

Paste your URL to get a free check that reads your site and the searches and rivals around it in about thirty seconds, and shows three findings you can act on. Free check: https://porteur.ai/