A site duplicator is a method for pulling a website's whole content model, its pages, copy, metadata and media URLs, into structured data you can rebuild in your own stack. It reconstructs content, not code or CSS. This one fell out of a weekend spent taking an awards-tier studio site apart to understand why it wins.
I do this when a site stops me. Not to copy it. To figure out the one decision that makes it work, because that decision usually transfers to something I actually need to build.
The site that stopped me had a homepage that wasn't a grid. You sat inside a dark void, and the studio's work floated on the inside of a sphere around you. Drag to look about, heavy and eased, and the card nearest your eyeline pulled into focus while the rest fell back. Tap one and the case study slid in. The trick wasn't the sphere on its own. It was that a single idea ran through the cursor, the type, the motion and the copy, so the site demonstrated the craft instead of listing it.
I wanted to know if I could rebuild that cleanly in my own stack, and how long it would take.
Phase one shipped in a day
The interaction I rebuilt is a globe of work that expands into an infinite scrolling tube. At rest it's a compact object, a curved-quad globe with a slow diagonal tumble that pauses when your cursor is over it. Click, and the camera flies from outside into the centre while every tile morphs from its slot on the globe to its slot on a cylinder. Then you're inside a tube gallery that scrolls forever in both directions, tiles recycling at the edges with a fade so nothing pops.
Vanilla Three.js and GSAP. Phase one, the working version, shipped in a day. A Phase two rewrite in Astro followed, mostly to make it fast and responsive rather than to change the feel.
I'll be honest about what that first day actually was. Most of it wasn't the graphics. The graphics were a known problem with known tools. The part that ate the hours, and the part worth keeping, was getting the content out of the original site in a shape I could build against.
The reusable bit wasn't the interaction
Here's the shift that turned a one-off into a method. I assumed the valuable thing was the globe. It wasn't. The valuable thing was how I pulled the source site's entire content model into clean, structured data before I wrote a line of scene code.
A modern studio site is dozens of pages, each with a title, a tagline, several paragraphs of verbatim copy, discipline tags, and a run of images on a CDN. Doing that by hand is a day of tab-switching and copy-paste errors. So I split the work across parallel subagents. Each one got an exact list of URLs and an exact output schema, fetched its batch, and handed back one fixed record per page: slug, tags, tagline, the copy verbatim, the ordered image URLs. Two or three agents running at once turned an afternoon of scraping into a few minutes.
One hard rule made the whole thing behave: only the fetch tool and web search are allowed to pull a URL. No curl, no wget, no Python requests dressed up as a browser. If the fetch tool is blocked on a domain, you stop and say so. That single restriction keeps the method honest and keeps it from wandering into things it shouldn't do.
The output is one shared data file, one object per item, with a couple of helper functions to build the right image sizes. The gallery reads from it. The case-study pages read from it. Swap a project, and you edit one object and drop new images in one folder.
It reconstructs content, it does not copy the site
This is the line I want to be careful about, because it's the difference between a useful method and a bad idea.
The fetch tool gives you rendered text and asset URLs. It does not give you the site's code, styling, or the interaction itself. So the method can rebuild a faithful content model, but the look and the motion you have to recreate by eye, in your own build, from your own decisions. That's the honest version and also the more useful one, because a content model is portable and someone else's CSS is a liability.
There's a second honesty point I'll put plainly. My rebuilt showcase currently runs on the original studio's work as placeholder content, sitting behind a noindex wall while I swap my own work in one card at a time. That's placeholder scaffolding so every tile and every subpage exists to test against. It is not mine, it isn't public, and I'm not going to dress it up as a finished portfolio. The parts that are genuinely mine are the engine and the extraction method. Those are what I'm sharing here.
The repeatable move: a working demo per card
The thing I'd point a reader at, if you build anything with a portfolio in it, is this. Instead of a screenshot behind each showcase card, build a small working demo that actually runs. One card, one self-contained interaction you can click into.
I've specced a set of these, each a builder-space concept mapped to a reusable card archetype. One is actually built so far. The rest are specifications waiting their turn, and I'm not going to pretend a dozen live demos exist when one does. Every asset in them is local or code-built. No AI-generated imagery, partly on principle and partly because generated images date a portfolio fast.
The method itself is documented end to end, from homepage recon to the final data file, which puts it about one step from a packaged skill I could run on any site in a single command. That's the next job.
What would you rebuild?
The lesson I keep relearning: when something impressive stops you, the transferable value is rarely the surface. It's the one structural decision underneath, and orchestrated subagents are very good at extracting that decision fast so you can rebuild it clean.
So here's the question I'll leave you with. What site, or what single interaction, has stopped you lately and made you want to know how it works? Pick the one thing you'd rebuild, and tell me what it is. That's usually the whole project hiding inside a smaller one.
Frequently Asked Questions
What is a site duplicator?
A method for pulling a website's whole content model, its pages, copy, metadata and media URLs, into structured data you can rebuild in your own stack. It reconstructs content, not code or CSS, which is the useful half anyway. A content model is portable. Someone else's stylesheet is a liability.
Is copying a website's design legal or ethical?
This method doesn't copy a site. A fetch tool returns rendered text and asset URLs, not source code, styling, or the interaction itself, so the look and the motion have to be recreated by eye in your own build. Using another studio's work as visible portfolio content wouldn't be acceptable, which is why my rebuilt showcase sits behind a noindex wall while my own work replaces the placeholders one card at a time.
How do AI subagents speed up content extraction?
A modern studio site is dozens of pages, each with a title, tagline, verbatim copy, tags, and a run of CDN images. By hand that's a day of tab-switching and copy-paste errors. Give each subagent an exact list of URLs and an exact output schema, run two or three at once, and the afternoon of scraping becomes a few minutes.
What rule keeps automated fetching honest?
Only the fetch tool and web search may pull a URL. No curl, no wget, no Python requests dressed up as a browser. If the fetch tool is blocked on a domain, the run stops and says so. That single restriction is what keeps the method from wandering into things it shouldn't do.
How long does rebuilding a complex web interaction take?
Phase one of the globe-to-tube gallery, vanilla Three.js and GSAP, shipped in a day, with a later rewrite mostly for speed and responsiveness. Most of that first day wasn't the graphics, which were a known problem with known tools. It was getting the content out of the original site in a shape worth building against.
Want help building systems like this for your organization?
Want a system like this built around your own work? Let's talk.