This article introduces the potential impact areas I’ve listed when performing URL refactoring.

Prerequisites

Suppose you want to refactor the URL

https://example.com/item/123

to

https://example.com/items/123

changing from item to items.

I’ve listed below the potential impact areas for performing this refactoring.

? We’re not discussing here whether modifications that change URLs should be called ‘refactoring’ or not.

Impact on External Sites/Channels and Site Analysis Tools

When performing URL refactoring, you need to be mindful of URLs linked from:

• External sites
• Email newsletters
• Social media

Changing URLs without consideration will create dead links.

It also affects metrics in access analysis services like Google Analytics. If you’re aggregating access logs, you’ll need to update those aggregation programs as well.

Response Strategy

Don't Refactor in the First Place

First, let’s consider the cost-effectiveness of this refactoring.

Compare what you gain versus what you lose by changing from singular to plural form, adding an ‘s’, and if you gain more, then proceed with refactoring.

However, changing URLs carelessly just because “having an ‘s’ is correct” or based solely on engineer ego can create major bugs where the original URLs become inaccessible.

301 Redirect

• Configure AWS ALB or Nginx to 301 redirect requests to /item/:id to /items/:id
• Rewrite all code in the source code that makes requests to /item/:id

I think it’s good to respond with this two-step approach.

That’s all from the Gemba on absolutely wanting to avoid dead links or broken functionality due to URL refactoring.