Synthetic Industry

Inspectable example · updated 2026-10-11

Synthetic example: a ten-row redirect map with a chain, a loop and a home-page dump, before and after

Ten invented old addresses show the common faults in a restructure, with the expected results after a map in which each old address has exactly one destination.

An example, not a customer case study. Scope and evidence limitations are described below.

The invented site

A made-up consultancy site restructured its services pages into a new section and merged two team pages. The domain stays the same. The ten old addresses below are paths only and are invented. The "before" column is what a test of the current rules found; the "after" column is the expected result once each old address is mapped to exactly one new address, with chains collapsed. Two old addresses may share a destination, as rows 4 and 5 do.

  • Paths are shown without the domain.
  • Each redirect step is a response such as 301; a "hop" is one redirect followed. "Ends at" gives the page the last redirect reaches and its status in brackets.

Before and after

Row 1 already redirects, but to a page that is not the mapped equivalent. Row 3 hops twice before reaching a page. Rows 4 and 5 loop: after the merge /about/jo redirects to /about/sam and /about/sam redirects back to /about/jo, so neither ever reaches a page. Rows 6 and 7 both end at the home page. Row 9 is a temporary redirect (302), which is not a permanent canonical signal. After the map, every row with an equivalent ends in a single permanent redirect and a working page; the row with no equivalent is listed for a decision rather than sent to the home page.

  • Columns: row, old path, before (first status, number of hops, where it ends), new path (mapped), after (first status, number of hops, final status).

If the matrix is wider than the box, scroll horizontally to read every column. Keyboard: focus the matrix and use Left/Right.

#  | old path             | before                                    | new path (mapped)            | after
1  | /services/web        | 301, 1 hop, ends at /web/ (200)           | /services/web-design/        | 301, 1 hop, 200
2  | /services/seo        | 404, 0 hops                               | /services/search-visibility/ | 301, 1 hop, 200
3  | /services/design     | 301, 2 hops via /design, ends at /ui (200)| /services/web-design/        | 301, 1 hop, 200
4  | /about/jo            | 301, 2 hops: /about/sam then back (loop)  | /about/team/                 | 301, 1 hop, 200
5  | /about/sam           | 301, 2 hops: /about/jo then back (loop)   | /about/team/                 | 301, 1 hop, 200
6  | /old-offer           | 301, 1 hop, ends at / (home, 200)         | none: needs a decision       | rule removed, 404 until decided
7  | /news/2019-update    | 301, 1 hop, ends at / (home, 200)         | /news/                       | 301, 1 hop, 200
8  | /contact-us          | 200, 0 hops                               | /contact/                    | 301, 1 hop, 200
9  | /downloads/brochure  | 302, 1 hop, ends at /resources/ (200)     | /resources/brochure/         | 301, 1 hop, 200
10 | /?p=14               | 404, 0 hops                               | /blog/the-new-post-slug/     | 301, 1 hop, 200

Why these rows were handled this way

Row 3 shows the point of collapsing chains: the old address should go straight to its final page. Rows 4 and 5 show a loop that the map removes by pointing both merged team pages to the one new team page. Row 6 would have been sent to the home page, which Google's guidance says may be treated as a soft 404 when many unrelated addresses go there; it is held for a human choice. Row 7 has a sensible parent in the news section, so the home page is not needed. Row 8 still answers 200, so it duplicates the new contact page until it redirects. Row 9 becomes a permanent redirect because the move is permanent. Row 10 is an old numbered address that now returns 404; a rule for it has to match the query part (?p=14) as well as the path, so the test checks that row on its own rather than assuming it works.

  • A loop usually appears when two rules point at each other after a merge.
  • A redirect to the home page is a decision, not a default.

What this example does not show

It does not show real addresses, real traffic or any ranking effect, and its results are invented. It says nothing about how many hops a particular server will allow or how quickly a search engine will notice. It also does not cover a domain change, which has extra steps. A real map would also record the reason for each row, the source of each old address and the date of the test.

  • Do not infer that all sites have the same faults.

Use it to specify an enquiry

Send your old-address list or its source, a description of what changed and the method your host accepts for redirects. The redirect job has a published test price of GBP 450 for up to 300 addresses on one WordPress domain, is accepted when every mapped row reaches its destination in one permanent redirect and every destination names itself, and does not promise ranking or traffic. The price is an untested proposal and payment follows the agreed checks.

  • Send paths and counts, never logins.

Sources and limits