Changing your URL structure: when it is worth it and how to do 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.

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.

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. 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. 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. 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. 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. 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.

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.

# 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;

// 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. 1

   Deploy to a staging host

   Mirror production data if you can. Load the redirect rules there first.

2. 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. 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.

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 host serving 301s for as long as you can. At least a year. Longer is better when possible, as of 2026.

1. 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. 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. 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. 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.

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.

• 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.

// 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' },
  };
}

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.