WordPress Redesign: 8 Guaranteed Ways to Botch It Beautifully

The StartingUp Summer keeps digging through its drawers. The worst mistakes that ruin a WordPress redesign are laid out in this pamphlet written in 2022, exhumed while drawing up the autopsy of our drafts AI made obsolete. It hasn't aged a bit, and we're serving it to you as is: very loose tone and period directness included.

Pulling off a site redesign is complicated: you have to account for a large number of factors and listen to different concerns that you don't necessarily master on your own.

Against the grain of the usual advice, today I'm handing you every trick you need to guarantee your project is a total wreck. Scared by the idea? You'll see it's easier than it looks!

This method is inspired by the best agencies and software publishers in France and the world.

It's their secret sauce and they're going to hate me for handing you, for free, their best recipes like this.

It's aimed at developers just as much as decision-makers of every stripe: business owners, (micro-)managers, project managers, web agency clients.

Normally, this kind of secret takes years to obtain or costs a fortune. But today I'm making an exception and handing you all this advice for free.

I want everyone to get the chance to botch their own redesign too: the idea here is to waste as much money, time and resources as possible.

It's even possible to burn people out or make them quit their job.

And the great part is, unlike most other methods, here you only need to apply part of the advice to pull off your own botch job.

• How do you keep your site from loading fast and make sure you have a slower site than your competitors'?
• How do you find more room to grow on Google by losing every ranking you have?
• How do you make sure your site is already outdated so you can redo it all over again in under a year?
• What's the magic choice that will maximize the botch job and make it fully irreversible?

I'll tell you everything for free in the rest of this article!

Since sarcasm can land badly in writing, let me be clear: this article is written tongue-in-cheek and is not investment advice. This stunt was performed by a professional, do not try this at home. Eat your fruits and vegetables.

The rest of this article is a purely fictional work.

Any resemblance to real situations can only be the result of pure coincidence. Thank goodness everyone knows this kind of thing never actually happens.

Our botch-job objective will focus on these 4 goals:

• Deliver our project late
• Wreck our site's performance irreversibly
• Torpedo our pages' rankings on Google
• Make sure everyone ends up angry (we're aiming for at least one resignation and/or one burnout)

Here we go, here are the 8 methods to get there:

I can only advise you to work out the entirety of your container without worrying about the content you're going to put into it. Trust me, it'll be much easier to botch everything by trying, after the fact, to cram your content shoehorn-style into an already-built template.

To do this, shamelessly resort to Lorem Ipsum and visual placeholders. Don't try to stick to existing content or anticipate what your client will want to put in there: the content will just have to adapt, end of story.

At one of my previous jobs, I regularly got told that we "shouldn't stifle the designer's creativity with constraints." Unbeatable logic. The result was almost always the same: sites with zero SEO optimization, with content that systematically had to be rewritten to fit into the boxes designed for it.

A good botched redesign inevitably comes with degraded SEO performance compared to the previous version. The trick here is to thoroughly blow up your site's page architecture.

To pull that off, start by making sure you change all your URLs, because Google just loves that. You can also decide to strip your pages of any excess text to "keep up with the times." Don't hesitate to merge several pages into one.

If you decide to put all your pages at the root and abandon any notion of hierarchy, that's a winning combo. It'll turn into a big mush that Google will absolutely feast on.

Once this work is finally done, don't set up any redirect plan from your old URLs to the new ones: search engines will drop the page from their index and visitors who had bookmarked old pages will run straight into a lovely 404 page. Now we're talking.

Why bother offering pages readable by search-engine robots? You're the one feeding their lucrative business after all, not the other way around; let them figure out the page content on their own!

So, don't bother making your content properly tagged for indexing robots: load your content via JS on the fly, with filters and pagination that only appear once JavaScript has run, with zero prior server-side rendering.

One of the surest ways to botch a WordPress redesign is to use a premium theme or a hefty page-builder plugin. You can, of course, go for the combo and use both.

Off the top of my head there's the venerable Divi theme, or the WPBakery, Elementor, Divi Builder plugins (don't hold it against me, I'm not linking to them). There are plenty of others I haven't mentioned, but don't worry, even if your plugin isn't on the list you can still botch your redesign just fine: what matters is that it's a page builder offering you tons of pre-built sections with a pile of unoptimized animations that don't adapt to mobile.

These tools are perfect because, since you're going to use them to build the entirety of your pages, they'll make the botch job irreversible. They're also very easy to get written into the specs by a client, a boss or a (micro-)manager: you can sell them the (false) promise that they'll be able to edit their own content and skip hiring a developer for front-end integration. Because yes, these are tools aimed at non-developers, and the whole point here is to make any future development impossible.

The other advantage here is that you get to keep the surprise for delivery day! Because yes, at first your project will move fast since you won't have to code anything. Sure, at first you risk getting some credit for this clever tech choice, with your client possibly congratulating you for hacking the game and avoiding a web integrator. You might even end up giving gorgeous demos thanks to the beautiful, heavy animations the builder ships with.

But don't panic: if your client uncovers the surprise a bit too early by pointing out that your site is slow, you can try to muddy the waters with a line like: "Oh, of course, I haven't optimized everything yet, and besides we're on a pretty underpowered staging server, you'll see, it'll be fast in production!". You'll see, your comment should put everyone back in their place and let you keep sabotaging things without a hitch.

Bottom line: hold the line! As soon as the project ships, everyone will finally notice that the site is apocalyptically slow, that GTmetrix and PageSpeed Insights crash whenever you try to check your web performance score, that there are still untranslated bits of English left in your templates, and that there's an ugly horizontal scroll on mobile. On the admin side, nobody will understand how to enter content, the interface will be so heavy, complicated and inconsistent, and the few brave enough to try will break the entire homepage layout just by trying to edit one word in a section.

Every plugin comes with its own little CSS file, its associated JS. Make sure to use as many as possible for the slightest need and avoid hiring a developer who actually knows what they're doing. Go all in, ideally more than 20 plugins, and don't hesitate to go well beyond that!

These plugins can be useful for problems as varied as they come: adding a banner at the top of your page, organizing the display order of pages in a section, embedding social-sharing buttons... It's true there's really no other way to do that (with ACF, for instance)... No, definitely, I can't think of one.

The goal is to write as little code as possible, while making sure the site takes as long as possible to load.

And it's well known, visitors are usually patient, especially on mobile. They actually find it suspicious when a site loads too fast. A hefty load time is a sign of robustness in your infrastructure, it shows you have a lot to say.

Generally speaking, you can consider that 20% of the population lives with a disability that keeps them from browsing the web as easily as the other 80%. The conditions are numerous: color blindness, blindness, paralysis... And depending on the niche the site sits in, that figure can even turn out to be much higher!

These disabilities can affect your site's usability, or make your content hard to understand.

So the question is: why bother making your services accessible to this segment of the population, when they could just turn to your competitors instead? You certainly don't want to grow your revenue, that would inevitably overwork your teams, wouldn't it?

So don't bother making your site accessible: color contrast and compatibility, alt text on images, link and button descriptions, best practices, all of that is for killjoys.

Nothing is too good during this delightful early project phase: you set no limits for yourself, forbid nothing, and say yes to everything.

That said, beware of teamwork: if the client, the web designer, the SEO specialist, the back-end developer and the front-end integrator all speak up, or worse, talk to each other, the risk is that they'll agree on doing things properly. That is absolutely not what we want! It would be best if the various people involved in this redesign barely spoke to each other at all, or only on rare occasions.

If you've managed to turn them against each other on previous projects, that's a bonus! Put that lack of cooperation to good use for this new botch job.

But if they're still inclined to talk, or even asking for it, there's still a very good technique. Funnel all the communication through a single person with a somewhat generalist background who doesn't actually master any of the subjects, someone who will style themselves the project's facilitator, trying to teach everyone their own job. Having become the whole team's bottleneck, they'll pretend to arbitrate between concepts they only half-know the terms and notions of, without really accounting for the stakes involved: this way, they can give more weight to a whim than to a technical requirement, and endlessly redefine the spec, even well after a budget and delivery-time estimate has been locked in.

Thanks to this kind of organization, you'll end up with:

• The total absence of breadcrumbs (or better yet, tucked away in the footer)
• Pages with zero text content but with 5 MB images
• The presence of 5 different fonts, in 4 different weights
• Over-a-minute-long videos in 4K quality used as decoration for a section
• Internet Explorer 9 compatibility that absolutely nobody cares about

If you've followed the previous advice closely, here's the one that ties them all together in the dark: estimate the time and resources needed by wetting your finger, following nothing but your gut, your own personal interest of the moment, and whatever the client wants to hear.

After all, this client didn't come to you for reassuring, realistic expertise, only to buy themselves a dream! That's what you need to sell them!

The downside if you let a developer or someone "technical" estimate the time and resources needed to properly complete the project is that they might actually give you a realistic estimate! That isn't the goal we're pursuing here: the objective, if it needs restating, is to make as many bad choices as possible that will weigh on the whole project, the team's morale and the company's financial health. Don't forget, the goal is to shrink the team by driving people to burnout and resignation!

If you sense that boring people might threaten this strategy, there's a really simple trick: to make your bad-faith estimate look like serious work anyway, you can pull out the magic Scrum card (also works with the term "Agile"). This way, you can have fun creating little cards on tools like the free version of Trello or Jira, all while staying just as bad-faith, of course: put unrealistic estimates and skip the "glue" needed between all the features you're describing. Within an hour, your rigged estimate will look much more serious, and above all, it'll now be up to your critics to justify their objections, instead of you having to defend work that was "done by the book."

That's the best way to push developers into coding half-assed. And that'll create you plenty of problems down the line: your site is likely to have piled up a huge amount of technical debt before it's even live.

I could give you plenty more advice like this, but you have to stop somewhere.

In the meantime, you can also dig deeper into the subject with this article by Mehdi on his blog JeSuisUnDev: How to Make Absolutely Sure You Ruin Your Software Project (in French).

As you've probably noticed, unlike success, which often requires ticking a lot of boxes at once, failure is much easier to reach: all it takes is neglecting a single one of these points for everything to fall apart.

We can easily conclude that failure is easier to reach than success! The world really is well designed after all…

Traffic stats have dropped since launch.

You're on your third crisis meeting of the week about the "site that's slow and has dropped on Google" topic.

You do some tap-dancing, arguing that "activity on the site is cyclical and that we're in a slow period for business," but your lie probably won't hold up much longer.

It takes you 30 seconds to load a page in the back office.

You can no longer update WordPress without breaking everything... And you don't know it yet, but within a year you'll have to pay again for the licenses of the no-code tools you used.

The project manager handling content has gone on sick leave, and the developer has gone completely dark.

Looking for a replacement on a freelance marketplace, you're stunned to notice that no developer wants to touch your project anymore. To be fair, you're asking them to work for free, since your company's web budget for the next 3 years is now exhausted.

You realize that, actually, botching this redesign wasn't such a great idea after all, and you wonder how to do things differently next time. Of course, even though this was a massive team effort, underfunded and led by a decision-maker who had no idea what they were doing, you go looking for a single culprit, and it definitely shouldn't be you.

You're considering a redesign: it's the circle of life, perpetuating itself.

</sarcasmMode>

First, start by drawing lessons from the points above so you don't repeat the same mistakes in the future!

Know that on the points raised, it's never too late in a project's timeline to turn back, given how strongly they each promise to lead to a crash. In other words, you're better off canceling the launch than going ahead with it head-down regardless.

Also know that nothing is set in stone and that it's always possible to walk back bad choices, even after launch, though it comes at a certain cost and some non-negotiable trade-offs. On the SEO side, you'll unfortunately sometimes have to wait several months after the fixes before recovering your previous rankings. On the development side, you'll need to find a reliable vendor willing to do the dirty work, or roll up your own sleeves and get your hands dirty.

In 17 years working on WordPress projects, I've seen it all. If I'm pointing out the mistakes I've come across in this article, it's because I've learned to own these problems and found solutions for every single one of these points.

If you're running into one of these problems, you can reach out to me and we can look together at how to limit the damage. These engagements generally include a full audit followed by a report with recommendations ranked by priority.

Often, the main recommendation is to redo everything, properly this time. And if I don't get the client's full buy-in on the diagnosis, I unfortunately cut the conversation short: nothing good will come of it, and the same bad choices will be doomed to repeat themselves.