Portal vs. Website: What’s the Difference?

Websites are for driving traffic, whereas web portals are for limiting traffic to a specific group of users. Most web portals require a user to log in, which allows the site to deliver more specific content and services based on who that user is. Websites are destinations that everyone can get to, and are generally designed for a broader audience.

That said, there is a lot of overlapping functionality between websites and portals today. Websites can use content targeting or other tools to create personalized experiences for users, and web portals can have public-facing pages that don’t require users to log in.

Portals can have anonymous public pages, as well as personalized access.

Platform vs. Page

One difference between portals and websites is whether the team that manages the site intends to create pages or platforms. In most cases, company portals and websites will be owned by different teams and thus have different expectations for how they should work.

The Marketing team may own the public website and prefer software built for blogging, measuring user engagement and enabling a strong visual design of web pages. Their expectations will be built around these core priorities. They need a solution that can build pages quickly that are either connected or independent, with complete control over where they fit into the overall structure of the site.

However, most organizations have to manage more than a public website. The Support team may own the customer self service portal and need a solution that integrates their other applications. They need a solution that is focused on building a platform, complete with multiple types of users and systems that are all connected.

Should You Build a Portal or a Website?

Like every technology solution, the decision to build either a website or portal comes down to your unique situation and needs. With the amount of overlapping functionality between portal platforms and more traditional WCM website platforms, most projects can be built with either option (given enough planning and elbow grease). Here are a few guidelines for when to use each.

Use a portal if: 

• you need to create specific audience experiences. 
• you need advanced control over what users see. 
• you have multiple systems that need to be integrated into one visual design. 
• you need advanced user management and permissioning features. 

Use a website if: 

• you're creating a public website focused on delivering and managing content. 
• you need to have a site that operates separately from internal site/systems. 
• you need to draw traffic from a broad audience of anonymous users. 

Still Not Sure?

It’s helpful to think of the portal versus website question in terms of an online journal versus a blog:

• An online journal likely has multiple contributors that need to access the site on the back end. Writers need to submit drafts, photographers need to upload their photos, designers need to make updates to the UI as needed and editors need the ability to manage the rest of these roles. A portal solution would be able to meet the needs of this complex system with granular role permissions, integration of different tools for each kind of user, built-in workflows and control over the presentation layer.
• A blog likely has one main contributor, whose primary concern is being able to manage his library of content efficiently. Other roles may need to be added (like a guest blogger), but they have simple requirements. Integration with social media and marketing tools is important, but they don’t need to be brought into the main UI in a visually consistent way. The top concern is building a strong customer experience on the front-end with easy access to sorting through and editing content on the back-end. A website solution built on WCM functionality would excel at this use case, by providing simple tools where needed and allowing the site owner to focus most of his energy on enhancing the front end.

Focus on What Your Team Is Prepared to Maintain

When you’re deciding between a portal and a website, you need to consider the project’s needs, the needs of the team managing it and your current technology investments. Portals can function as websites, and websites can function as portals, so the technology you invest in should go beyond features to what you will be able to sustain long-term for your organization.