Rebuild vs patch: how I decide
Not every tired site needs a full rebuild. If the stack is sound, SEO is intact, and the pain is speed, security, or a few broken flows, we patch and harden first — often cheaper and lower risk.
A rebuild earns its keep when editing is painful, the theme/plugin pile cannot be unwound safely, design and information architecture no longer match the business, or every fix creates two new problems. I will recommend the smaller path when it is honest.
Protecting URLs, content, and redirects is part of any rebuild - not an afterthought. That is also why technical SEO and PageSpeed work often sit next to a rebuild.
A rebuild should feel like progress, not risk
People usually arrive here after years of patching. The site looks tired, editing is painful, or performance and security feel shaky. The fear underneath is simple: "If we rebuild, will we lose Google?"
We inventory what must survive, choose an honest stack, and plan cutover — so launch day is a switch, not a surprise.
Stack choices grounded in how you work
Marketing sites with infrequent updates often thrive as static-first builds. Teams that edit daily, run memberships, or need complex WooCommerce usually stay on WordPress - cleaned up and faster.
I will not push a fashionable stack that fights your workflow. The goal is a site your team can actually run.
Built by someone who still maintains products
I develop sites end to end and I still ship and maintain my own products. That habit shows up in rebuilds: clearer structure, fewer fragile hacks, and documentation so you are not stuck after launch.
