Structural changes need redirects so old paths do not break

What it is

When a class moves, old URLs, old nav paths, and old search hits are still being opened. Redirects send those arrivals to the new canonical place, rather than leaving a 404 or a dead “this section has been redesigned” page. A structural change that ships only a new tree and does not migrate old paths serves people who start again from home, and punishes everyone who arrives with old coordinates. Redirects are part of the structural change, not an operations patch afterwards.

Avoiding broken links includes human and machine links: bookmarks, mail, search engines, stale in-site menus, QR codes.

Why it happens

An old path is a cached coordinate. If the server declares with a 301 or equivalent that “the object for this coordinate now lives there,” callers (browsers, search engines, share previews) update their cache, and accumulation starts to turn. A 404 writes “does not exist” into that cache, which takes longer to undo. Soft 404s (the page loads with a “not found” message) are worse: callers think success, people think the object is gone.

One-to-one moves redirect cleanly. One-to-many (one old class split into three) has no single right target; the redirect should land on a parent or a choice page that explains the children. Dumping everyone into one child makes the other two look deleted.

Studying it

Measure the fate of real old URLs after the change; do not only tree-test the new tree.

• Paradigms: extract old paths from logs and inbound links, request each after the change, record the terminus (new canonical / 404 / soft 404 / wrong object); then run known-item tasks with veterans carrying bookmarks.
• Independent variables: presence of 301, split landing on parent versus one child, redirect-chain length, whether the sitemap was updated.
• Dependent variables: share of old paths reaching the canonical object, wrong-object arrivals, time for search listings to update, task success.
• Methodological note: crawling the new sitemap will not see broken links. The pre-change URL set is the test set. Long chains (A→B→C) drop in some clients; measure chain length. “They could find it from home” does not count as old-path success.

Where it stops holding

Malicious or junk old URLs need not be migrated into the new tree; an explicit 410 or a kept 404 avoids sending junk weight into the new structure. Legally retired content must not redirect to a “similar” page that impersonates still-in-force; it should reach an explanation page. Internal alias routes (several canonical URLs for one object) should collapse to one canonical before public 301s, or search engines see loops. Pure client-side routing that changes the front end without a server redirect still breaks external inbound links.

Applying it

• Ship an old→new map with the structural plan, live at the same moment. One-to-many lands on an explainable parent or choice page; do not pick a child at random.
• Sitemap, in-site search index, share metadata, and nav cut to the new canonical on the same day.
• Watch 404s and soft 404s for four weeks; missed old paths go into the map. Do not wait for a user report.
• Verify twenty top inbound links and twenty bookmark-style paths from before the change: all should 301 to the right object. Any 404 or wrong object means the structural change is not done at the lookup layer.

Related

• Within the group: G1.11.1 A taxonomy should leave room for future content, not fill up around what is known today · G1.11.2 Premature classes for tiny sets lose meaning as content grows · G1.11.3 The cost of changing architecture rises with inbound links, bookmarks, and settled mental models · G1.11.5 Governance decides who may add or merge classes, or the taxonomy inflates without order · G1.11.6 Imbalanced class use is a signal to restructure; do not rely on intuition alone
• Adjacent: G4.02 Deep linking · G1.07 Content inventory and audit · G1.10 Controlled vocabularies and synonyms
• Search terms: URL redirect · taxonomy migration · broken links