I Cloned My Dog-Name Site to Build a Cat-Name Site. The Routing Layer Bit Back.

I run a dog-name site. A few weeks ago a reader emailed asking the obvious question: "Do you have one for cats?"

I didn't. But I had a fully built PHP content site sitting right there — browse names by breed, by origin, by color, by size; a name-detail page for every entry; clean URLs all the way down. Cats are just dogs with a different attitude and a smaller breed list, right? I figured I'd clone the whole thing in an afternoon.

It did not take an afternoon. And the part that ate the time wasn't the data or the templates — it was the routing layer. This is the story of what doesn't copy over when you "just clone" a content site, written down so the next person (or future me) doesn't repeat it.

The shape of the thing

Both sites are plain PHP — no framework. Every page is a file under pages/, and a clean URL gets rewritten to it with a query string. So /breeds/letter/a/page/2 becomes pages/breeds.php?letter=a&page=2. Nice URLs for users and search engines, ordinary PHP underneath.

The catch is that the rewrite has to happen in two completely different places, because the site runs in two completely different environments.

In production it's Apache, so the rules live in .htaccess:

# /breeds, /breeds/letter/{a}, /breeds/page/{n}
RewriteRule ^breeds(?:/letter/([a-z]))?(?:/page/(\d+))?/?$ pages/breeds.php?letter=$1&page=$2 [L,QSA,NC]

Locally I develop with PHP's built-in server (php -S localhost:8080 router.php), which knows nothing about .htaccess. So the same route has to exist again, as a preg_match in router.php:

if (preg_match('#^/breeds(?:/letter/([a-z]))?(?:/page/(\d+))?/?$#i', $uri, $m)) {
    $_GET['letter'] = $m[1] ?? '';
    $_GET['page']   = $m[2] ?? '';
    require __DIR__ . '/pages/breeds.php';
    return true;
}

One logical route, two physical definitions. On a single site that's already a low-grade tax: every time I add a route I edit two files and keep two regexes in sync. It works, I'd made my peace with it.

Cloning doubled the tax into something worse

Here's the thing I didn't think through before I copied the folder. The site has dozens of routes — name detail, categories, the dictionary, search, comparison pages, a pile of 301s for legacy URLs. Each one already lived in two places. Clone the site, and now every route lives in four places, across two repos.

The first time I added a cat-specific route, I added it to the cat site's .htaccess, tested it on production, and it worked. Then a week later I went to test something locally and got a 404 — because I'd never mirrored that rule into the cat site's router.php. The local and production routing had silently drifted apart. On the dog site I'd trained myself to edit both. On the fresh clone, I hadn't built that muscle yet, and the duplication just quietly rotted.

That's the trap with cloning: you copy the code, but you don't copy the discipline the code silently depends on.

What actually didn't transfer

Beyond routing, a few assumptions I'd hardcoded for dogs leaked through:

• Breed counts. The dog site assumes a long breed list with its own pagination thresholds. Cats have far fewer recognized breeds, so pages that were comfortably full on one site looked empty on the other. The layout "worked" but felt broken.
• Category vocabulary. "Working dogs," "herding," "guardian" — none of that maps to cats. The category system was generic enough to run with cat data, but the seed categories were dog-shaped, so half of them were nonsense until I redid them.
• Copy and microcopy. Every "your new puppy" string. Cloning finds these the hard way, one user-facing typo at a time.

None of these were hard. They were just invisible until real data hit them — which is exactly the kind of thing a clone hides from you, because the code compiles and the page renders. It's the content that's wrong, and content doesn't throw exceptions.

What I'd do instead (and am slowly refactoring toward)

The honest takeaway: I shouldn't have cloned a site. I should have built one engine and two instances.

Concretely, the routing table should be defined once, as data, not twice as code:

// routes.php — single source of truth
return [
    ['pattern' => '#^/breeds(?:/letter/([a-z]))?(?:/page/(\d+))?/?$#i',
     'page'    => 'breeds.php',
     'params'  => ['letter', 'page']],
    // ...
];

router.php loops over that array for local dev. And a small build script can generate the .htaccess rewrite block from the same table for production. One definition, two consumers — instead of four hand-maintained copies. The entity ("dog" vs "cat") becomes a config value: breed list, categories, and copy strings get injected, while the engine stays identical.

I'm not all the way there yet — the cat site shipped on the cloned codebase because shipping beat refactoring. But every route I touch now, I move into the shared table instead of duplicating it. The fork is slowly converging back into an engine.

If you want to see the two instances side by side, the cat site is live at icatnames.com and the original dog site it grew out of is idognames.com — same bones, different animal, and (now) a slowly shrinking amount of duplicated routing.

The lesson in one line

Cloning copies your code but not the invisible discipline it relies on. If a site has any duplicated-but-must-stay-in-sync layer, a clone doesn't double your maintenance — it squares it.

How do the rest of you handle dev-vs-prod routing parity without a framework? I'd genuinely like to hear if there's a cleaner pattern than "generate one from the other."