Replacing WordPress: How I Rebuilt Two Websites with Claude Code

When I first went freelance in 2019, I quickly built a portfolio website using a WordPress theme. It looked smart, needed relatively little customisation and gave me somewhere to showcase my work.

The intention was to build up a portfolio through blogs and case studies, but in reality I had far more client work than expected and never found the time to document it properly.

When I launched Product Scope in 2022, I knew I needed a new website, although by then writing up several years of projects, products and features felt like a huge task before I had even considered the website itself.

I started properly in 2024, using AI to speed up the editing and review process, and by the end of the year I had a decent amount of content ready to publish but still no website to publish it on.

Building the Product Scope website

I bought another WordPress theme, assuming I could install it, replace the content and make a few adjustments.

What I had not realised was how dependent the theme was on Qi Blocks and how much of the example website I would need to recreate myself, because it was less a completed website and more a collection of components that could be assembled into one.

Possibly a silly assumption, but themes are often sold in a way that makes the process look much easier than it is, and there is a real skill involved in putting together a good WordPress site.

I spent months learning how the theme worked, adjusting layouts and trying to make the design consistent, dealing with columns that behaved differently between pages, widths that looked correct on desktop but broke on mobile, images that moved, spacing that changed and font settings that seemed to be hidden in several different places.

At one point, I was using AI to write increasingly specific CSS fixes for the mobile layout, until I realised I was patching the wrong structure and went back through the example templates, worked out how they had been built and recreated the pages using the same block patterns.

After months of work, I finally launched the Product Scope website in July 2025 and then turned my attention to a client's website. Because I could reuse much of the same process, that build was considerably faster, although it still took around two months and launched shortly before Christmas 2025.

Both websites worked and looked professional, and at that point I considered the job done.

Deciding to rebuild

A few weeks ago, the client had been making updates to the website and was struggling to get some of the revised sections to behave properly on mobile.

She had spent half a day trying to correct one of the layouts and, when she showed it to me, I could see the problem. WordPress page builders allow sections to be configured differently for desktop, tablet and mobile, but making those settings work consistently can be extremely fiddly.

I was about to explain how she could adjust the responsive settings when I could see how frustrated she was. At almost exactly the same moment, I thought that I could probably rebuild the entire website in Claude Code in a way that would be easier to maintain and give me much more control.

The starting point was not a blank canvas. The site already had its structure, copy, imagery and overall design, so my first step was to ask Claude Code to inspect the existing website and document what it found. I wanted it to capture the pages, navigation, content, visual patterns and reusable components in Markdown files before it began rebuilding anything.

This was important because I did not want Claude to redesign the site based on generic assumptions. I wanted it to understand what already existed, preserve the parts that worked and then recreate them in a much simpler technical structure.

Within around an hour, Claude had produced local versions of most of the site. They were not exact, but the overall structure, page content and majority of the design were there, which probably represented around 60 per cent of the finished result.

I then compared each page against screenshots of the original site and asked Claude to correct what was missing. It pulled in the remaining imagery, adjusted layouts, improved spacing and brought the design much closer to the existing version.

That got the site to around 80 per cent, but the remaining work took much more attention. I reviewed each section individually, challenged generic design choices, corrected responsive behaviour and tested different versions until the pages felt complete.

Claude Code can produce something functional very quickly, but without direction it tends to fall back on recognisable AI design patterns, such as oversized headings, repeated card layouts and decorative gradients. The quality came from reviewing what it produced, rejecting what did not fit and continuing to refine it.

Within two days, the client site had been rebuilt using HTML, CSS and a limited amount of JavaScript. The new version was more consistent, better suited to the content and much easier to control, with properly sized images, responsive behaviour that made sense and no need to fight decisions built into a theme or page builder.

She has been happy with the result, and rather than needing me for every change, she has since added and adjusted sections herself using Claude Code, working from the structure and hosting I set up. That was the point of moving away from a page builder in the first place: she now has much more control over the site and can make routine changes without depending on me to implement them.

After completing that site, I used the same process to rebuild Product Scope. That took around a week because the site was larger, included more content and required additional work around articles, case studies, SEO and publishing.

At the beginning of July 2026, the static Product Scope site replaced the WordPress version that had taken me months to put together.

Why it worked better

I do not think WordPress is dead, as it is used by millions of websites and still makes sense for many organisations, but I no longer think it should be the automatic choice for every small business or portfolio website.

Both sites are mainly informational, containing pages, case studies, articles, images and contact forms, and neither requires customer accounts, comments, ecommerce, complex permissions or a large editorial team.

For that type of website, WordPress introduced a lot of machinery for functionality I did not use.

More control

With WordPress, I was constrained by the theme, the page builder and the way individual components had been designed.

I could customise them, but only within the assumptions made by someone else, and going beyond those assumptions usually meant adding CSS overrides, adjusting several responsive settings or looking for another plugin.

With the static sites, I can ask Claude Code to produce several versions of a section, review them in the browser and combine the best parts, or provide a screenshot, describe what is wrong and see an updated version within seconds.

I am still limited by what I can design, describe and assess, but that is far less restrictive than working inside a page builder.

Faster changes

Building a new WordPress page previously involved creating the page, copying sections, replacing content, selecting images and correcting the responsive layout, and even when using an existing template it could take more than an hour.

With the new site, I can give Claude the copy, the images and another page to use as a structural reference, and it can generate the first version in minutes.

That does not mean the page is finished in minutes, as I still need to review the hierarchy, spacing, responsive behaviour and overall design, but the difference is that my time is spent reviewing and improving rather than assembling every block manually.

Less maintenance

The WordPress sites had the core platform, a theme, a page builder and several plugins, all of which needed to remain compatible and up to date.

I also paid for a security plugin and periodically needed to investigate alerts, updates or conflicts. None of this was particularly difficult, but it created a lot of maintenance around two fairly simple websites.

The new sites have no content-management database or public administration area, and most pages are plain HTML and CSS, with JavaScript only where it serves a clear purpose. There are still security considerations, but there are fewer moving parts and much less to maintain.

It suits how I work

I am not a designer or a developer, and while I understand code, can define requirements and can work through technical problems, I would not have built either of these websites manually from a blank folder.

What I can do is organise a project, define an outcome, assess what has been delivered and direct an iterative process, which is essentially what I do as a Product Manager.

Claude Code provides the implementation capability, but I still need to establish the structure, spot inconsistencies, make design decisions and decide when something is ready.

I also work much better when I have something visual to react to rather than starting with a blank canvas, and this process suits me because Claude can create the first version quickly and I can then review and improve it.

Reviewing the site as a whole

Once the individual pages were complete, I stopped looking at them separately and reviewed the website as a system.

I checked whether colours were being applied consistently, whether fonts, headings and buttons were aligned, whether spacing followed a predictable rhythm and whether the mobile layouts genuinely worked rather than simply being compressed versions of the desktop design.

I documented the design system so future pages could reuse the same components instead of introducing new styling every time, and I also asked Claude to review what was missing rather than only checking what had already been built.

I refined the privacy information, removed Google Analytics and moved the site to cookieless Cloudflare Web Analytics, while also hosting the fonts directly rather than loading them from Google.

Claude also helped generate favicons, social sharing images, SEO data and the sitemap, although I did not rely on a single review to decide that the site was ready.

I requested separate code, security, accessibility and performance reviews, which found genuine issues, including areas where form submissions needed stricter handling and old code that could have caused problems if it was reused later.

Claude wrote much of the implementation, but I still needed to review and challenge its work because functioning code is not automatically production-ready.

GitHub, staging and releases

I placed each website in a private GitHub repository so there was a single source of truth and a full version history.

Changes are committed to GitHub and automatically deployed to a staging website, where they can be checked before being deliberately released to the live site.

This also makes collaboration easier because a client does not need to understand FTP, server folders or WordPress page builders. She can ask Claude Code to make a change, review it on staging and publish it once she is happy.

If something goes wrong, the site can be returned to an earlier version, which feels much safer than editing a live WordPress page and hoping that changing one section does not affect another.

Static does not mean basic

The sites are mainly static, but that does not mean every page is completely fixed.

I wanted to prepare articles in advance, so the Product Scope site supports scheduled publishing, with each article having a publication date and the site only displaying it once that date has been reached.

The article index, category pages, related content, previous and next links, SEO metadata and sitemap are generated through a small collection of scripts.

The contact form is handled through a Cloudflare Worker, which validates submissions, applies spam protection and sends the data to Make to manage the email workflow, so the website itself does not need a traditional backend for any of this.

The same principle applies to many small business websites, where booking can be handled by a specialist service, payments through a hosted Stripe page and forms through Make or another automation tool.

Restaurants, hotels, consultants and local businesses do not necessarily need all of those functions built into WordPress, as in many cases they are already better handled by specialist products.

There are clear exceptions, as a publishing team producing content every day probably needs a proper CMS, an ecommerce business needs structured product and order management, and larger organisations may need approval workflows and more detailed permissions.

However, a large proportion of portfolio and professional service websites do not need those things, and for those sites I no longer think WordPress should be the default.

What I learnt

The interesting part of this project is not simply that Claude Code can generate HTML and CSS, but that it can inspect an existing website, work across an entire codebase, document patterns, maintain consistency and help prepare something for production.

Previously, my ability to deliver a custom site was limited by my ability to write every part of it, but now it is more dependent on whether I can explain what I want, assess the result and test it properly.

Claude did not get everything right the first time, as it misunderstood requirements, made design decisions I did not like and sometimes changed one thing while accidentally affecting another.

Despite that, I was never completely stuck or blocked, which is very different from spending hours trying to understand why one WordPress column behaves differently from another.

I completed most of the work using Claude Code with Opus through a £90 monthly Claude plan, and I did not hit the usage limits despite using Claude for plenty of other work alongside these projects.

The result is that I now have two websites that are easier to change, easier to maintain and much closer to what I originally wanted, and while WordPress still makes sense for many websites, for a largely static business site like Product Scope I cannot see myself choosing it again.

Having now completed the process twice, I have a much clearer understanding of where this approach works, how to structure the rebuild and which parts require the most attention. Product Scope took around a week rather than several months, even though it was a larger site with articles, case studies, scheduled publishing, SEO and a contact workflow.

That makes this a service I can now offer with some confidence to organisations in a similar position: businesses with relatively straightforward websites that have become difficult to maintain because of themes, page builders, plugins and layers of custom CSS. The work still requires careful planning, design judgement, testing and review, but the underlying process is now proven and I would expect the next rebuild to be faster again.