In September 2026 we rebuilt a 118 page WordPress site as a static site in one week. 114 pages went live with zero broken links, and about forty plugins came out and did not go back in.
The headline is the wrong part to read. Building 114 pages is not hard and it is not where the week went. What took the time was working out what the site was actually doing, and that is the part nobody writes up, so here it is.
The fast parts, so you can stop thinking about them
Pulling the content out took an afternoon. WordPress will hand you every page as structured data, and once you have it, converting the body copy to markdown is a script you write once and run.
Building the templates took about a day and a half. Most sites of this size have five or six page shapes, not 118. Once the shapes exist, the pages fill themselves.
Getting it deployed and fast took an hour, because a static site has almost nothing to be slow about. There is no database query to optimise, no cache to warm and no plugin to profile. This is genuinely the easy half and anybody quoting you a lot of money for it should be asked what the money is for.
So that is roughly two and a half days of the week. Here is the rest.
Finding out what forty plugins were doing
Nobody at the firm could tell us what most of them were for. That is not a criticism, it is the normal state of a site that has been alive for nine years and had four different people touch it. Plugins accumulate the way cables accumulate behind a desk.
Sorting them took the best part of two days, and the categories came out like this.
More than half were doing nothing at all. Installed for a campaign in 2019, deactivated, never deleted. Or active and idle: an analytics plugin for a service the firm stopped paying for, a social sharing bar that had been hidden by CSS for years, three separate SEO plugins of which one was configured and two were arguing with it.
A handful were doing something that the platform now does natively, which is the honest reason a lot of plugins existed at all. Image resizing. Lazy loading. A table of contents.
And then there were the ones that were load bearing in ways nobody knew. A redirect manager holding a couple of hundred redirects accumulated over years, none of them documented anywhere else, which is the single most dangerous thing to find late. A form handler that was quietly mailing submissions to an address that belonged to somebody who had left. A gallery plugin that was the only thing rendering three of the pages, so those pages looked empty in the export and we nearly shipped them blank. A caching plugin that was masking a slow query rather than solving it, which stopped mattering the moment there was no database.
Every one of those had to be found by reading the rendered site and comparing it to the exported content, page by page. There is no tool for that. It is a person with two browser windows.
The redirect map, which is most of what "zero broken links" means
A URL that worked yesterday has to work today. That includes URLs nobody links to any more, because somebody has one in an email from 2021 and a search engine has all of them.
So the job is: crawl the old site, get every URL it answers on, decide where each one goes on the new site, write that map down as a file, and then crawl the new site and confirm every single one of them resolves. Not "should resolve". Resolves, checked, with a status code.
That is where "zero broken links" comes from. It is the output of a check somebody ran, with a status code recorded beside every line, rather than an assurance about the quality of the new site. The old site's own internal links were part of it too: a nine year old site is full of links to pages that were deleted in 2020, and those were already broken before we touched anything. Handing back a list of them was one of the more useful things in the whole job, and it cost nothing except looking.
Budget a day for this on a site of this size. It is dull, it is entirely mechanical, and it is the difference between a rebuild and an outage.
Content that was not in the content
Some of the words on that site were not in any page. They were in a widget area, or in a footer assembled in a page builder, or set as a background image with the text baked into the pixels, or held in a plugin's own settings table. Phone numbers were in four places and two of them disagreed.
Finding those is the same two browser windows exercise as the plugins. Fixing them is the good part: everything that a person will ever need to change lives in one file now, so the phone number cannot disagree with itself again.
The decisions only the owner could make
This is the real bottleneck on every rebuild and it has nothing to do with engineering.
Four pages did not come across. One was a duplicate of another with a slightly different title, from a campaign. One was an empty category archive that existed because the platform generated it. Two were pages whose only content was a plugin shortcode for a service the firm no longer used. Each of those needed somebody at the firm to look at it and say "delete that", and getting four decisions out of a busy person takes longer than making 114 pages.
The comments on the old blog posts did not come across either. There were not many and most were spam, and the firm decided that was acceptable. Somebody else might not, and that decision has to be made out loud before the switch rather than discovered afterwards.
The staff also lost the ability to drag boxes around on a page. They gained an editor where they change words and press publish, and the layout stays correct because nobody can break it. Whether that is a loss or a gain depends entirely on the firm, and it is a conversation to have at the start.
What an owner should ask for
If somebody is quoting you a rebuild, ask for these five things in writing. If the answer to any of them is vague, that is the whole answer.
- The redirect map as a file you keep, with every old URL and where it goes.
- A crawl of the old site and a crawl of the new one, with the status codes, so "zero broken links" is a report rather than an assurance.
- Your content in a portable format that is not locked to whatever they built it in.
- A written list of what each removed plugin was doing and what replaced it, including the ones where the answer is "nothing, and that is fine".
- Confirmation of where the form submissions go now, tested with a real submission that somebody received.
Also make sure the domain and the DNS are in your name and you can log in. That one is not about the rebuild. It is about the day you decide to work with somebody else.
What it costs
A marketing site of up to ten pages here is $6,500 and a week is typical. Anything larger gets a fixed quote after the free review, and the 118 page job is the reference for what the larger end looks like. The software and sites page has the rest.
The answer
The pages were never the work. The work was the archaeology: finding out what nine years of plugins were doing, writing down every URL the old site answered on and proving the new one answers on all of them, and getting a busy owner to make four decisions about four pages.
If a quote for a rebuild is priced on page count alone, it has not accounted for any of that, and the part it has not accounted for is the part that decides whether your site is still reachable on Monday.