Websites are like pet mice: if you’re not careful, you can end up owning way too many. As a marketer, it’s all too easy to find yourself surrounded by websites: websites for new products, websites inherited from companies you’ve acquired, websites you created to avoid bothering your overloaded IT team, and websites someone spun up in a fit of enthusiasm in 2015. Left unchecked, this kind of digital ecosystem becomes a drain on your care and attention. 

But getting rid of all these websites is work. A brand and content strategy may be required to ensure a smooth transition of users and content. Your main site may have problems of its own that drove the creation of all these sites in the first place. And while website consolidation is often worthwhile, it can be hard to know when the benefits will truly outweigh the costs. 

At BFM, we typically see these questions arise when clients embark upon a full site redesign. Some redesigns are driven by the need to consolidate. In other cases, the client is undecided about whether or not to merge websites, and we’re asked to make a recommendation.   

Because this issue comes up so often, we’ve created a guide, 14 Questions to Ask Before Consolidating Websites. These 14 questions span user experience, branding and visual design, content strategy, SEO, and technical requirements – in other words, a wide range of disciplines that contribute to a website build. The guide can’t address every possible issue we might consider, but it does cover the questions we would usually ask in the course of devising a website strategy.  

To give you a sense of what’s in the guide, we’ll share three questions that tackle the consolidation issue from three different standpoints.   

User Experience: Are your audience groups on similar or different user journeys?  

User groups differ in how much information they need to make decisions, how many times they may visit a site before converting, and what content persuades them. B2B purchasers may find comfort in abundant information, while impulse shoppers may appreciate sharp photos, helpful reviews and a quick checkout.  

Website information should be structured and organized to deliver what the user wants, and if users’ wants clash with one another – if one group is looking for simplicity and another for substance – it’s possible they’ll be better served on separate websites.  

The same is true for conversation points. Effective websites prioritize the most important actions that users can take. A website that has five top priorities has none at all. If you want users to perform entirely different sets of equally important actions, these might be better separated.  

Actions that may (but not must!) be kept on separate sites or subdomains include eCommerce (if the business has another strategic objective to focus on, like lead gen) or support (if there is a big database of self-service content that’s only relevant to one group of users). 

Operations: Will merging sites raise regulatory issues?  

In highly regulated industries such as finance or healthcare, specific disclosures may need to accompany certain site content. In some cases, specific content may need to be approved by regulators. These issues may make it impossible or inappropriate to mix content types that are regulated differently. In these cases, compliance teams become an important project stakeholder, because the last thing you want on a website project is compliance-mandated rework.   

Content: Can you take advantage of cross-selling opportunities? 

Clients often come to us with the concern that their own customers don’t understand the full scope of what they do. They rightly see a new website as a chance to introduce additional services in a context where they’re relevant to the user. If this is an important goal, your users will generally have a more consistent experience if the cross-selling is done on the same site. 

If you’re interested in more – or just can’t stand not to know what the other 11 questions are – we encourage you to download the full guide for free via LinkedIn. 


This block is broken or missing. You may be missing content or you might need to enable the original module.