Why we rebuilt our website from scratch (and what we learned)

The website of a company that builds websites for a living is a merciless business card: if it doesn't convince, the client wonders what you'll do with theirs. Ours had been running on WordPress for years and it worked, but it no longer reflected how we work. So we rebuilt our site from scratch, moving to a custom platform, and in this article we walk through the choices, the mistakes narrowly avoided and the lessons you can reuse if you're thinking about rebuilding yours.

Why rebuild instead of patching

The question we always ask clients, we asked ourselves too: does it need a rebuild, or is a fix enough? The reasons that made us take the long road:

• The theme had become a tight suit. Every design change went through overrides on top of overrides; the cost of each change grew with every intervention.
• The multilingual setup was handled with plugins. We have offices in Italy and Malta and we needed a site in four languages (Italian, English, Maltese, Albanian) with full control over URLs and translated content, not a translation stuck on top.
• We wanted to show, not just claim. We write about performance and design in our quotes: the site had to be the proof, with animations and attention to detail that a prepackaged theme doesn't allow.

If your reasons are of this kind, structural, a rebuild makes sense. If instead the site has grown tiresome aesthetically but holds up well, a targeted restyling often costs a third and delivers nearly as much.

The technical choices: from WordPress to Next.js

We chose Next.js with server-side rendering and a MySQL database for the dynamic content: blog, portfolio and reviews. The decisions that weighed the most:

• Native multilingual routing. Every page lives under its language prefix, and the content of the four versions is managed as content of equal standing, not as second-class translations. This simplifies both international SEO and maintenance.
• Content in the database, layout in the code. The blog and the portfolio projects live on MySQL and are updated without touching the code; the design, on the other hand, is versioned in Git like any software project, with the history of every change.
• As few dependencies as possible. On WordPress every feature was a plugin, and every plugin an update to watch over. On the custom site the features are our own code: more work at the start, far less recurring maintenance.

It's not the right choice for everyone, and we're the first to say so: for many clients WordPress or PrestaShop remain the most sensible answer. For an agency that lives on development, custom was consistent with what we sell.

SEO during the migration: the part where you don't improvise

Rebuilding a site is the moment when you can burn years of rankings in a week. Our plan, the same one we apply for clients:

1. Inventory of existing URLs from sitemap, analytics and Search Console, including the forgotten pages that were still bringing traffic.
2. 301 redirect map, one by one, from the old URLs to the new ones. Pages with no equivalent should be redirected to the most relevant page, not to the home.
3. Hreflang across the four languages, so Google serves the right version for every search, which is fundamental for us since we answer searches in different markets.
4. Sitemap and Search Console on launch day, with daily monitoring of coverage and 404 errors in the first weeks.

The mistake we see most often in other people's rebuilds is exactly here: money goes into the design and the organic traffic built over years gets forgotten. The redirect is the least photogenic part of the project and the one that protects the revenue.

The numbers we watch now

A new site is not a finish line, it's a measurement baseline. The metrics we've followed since launch:

• Core Web Vitals on real user data, not just in lab tests, because that's what Google uses to evaluate the experience;
• coverage and positions in Search Console, comparing the queries that brought traffic before and after the migration;
• inquiries from the contact form, the only metric that pays the bills: where they come from, from which page, after which journey.

The practical advice: take a snapshot of these numbers before the relaunch. Without the before, the after tells you nothing.

What we learned (useful for you too)

Three lessons we carry into client projects. First: content is the bottleneck, not code; writing and translating the pages into four languages took more discipline than the development. Second: deciding what to remove is worth as much as deciding what to add; we removed pages that existed only because they had always existed. Third: the perfect site doesn't exist and the launch shouldn't be postponed forever; better to go live with a solid base and iterate on data than to delay for detail number one hundred.

Do you need to rebuild your site?

We design websites and eCommerce stores starting from the same question we asked ourselves: rebuild or fix? Sometimes the honest answer is the second, and we'll tell you so. If your site no longer represents you or the migration scares you because of SEO, book a free call: we'll analyze the situation together and propose the path with the least risk.