Website vs web application vs web portal: which are you building?
A website is mainly content people read. A web application is software people use to complete tasks. A web portal is a web application for a known group, such as clients, patients or suppliers, who sign in to see their own records. Naming the project correctly decides the stack, the security work and the budget.
Website vs web application vs web portal: what changes in the build?
Quick answer
Website vs web application comes down to what users do: they read a website, they complete tasks in a web application, and they sign in to a web portal to see their own records. Each step adds accounts, stored data, security testing and running costs. Agnotic Technologies scopes which one you need before the build starts.
| Criterion | Website | Web app or portal |
|---|---|---|
| Purpose | Inform visitors and turn them into enquiries | App: let users complete tasks. Portal: give a known group self-service access to their own data |
| Who signs in | Usually nobody; editors sign in to the CMS | App: every user, often with roles. Portal: invited or verified customers or partners, each limited to their own records |
| Data stored | Pages, media and form submissions | App: accounts and the records users create. Portal: accounts plus data synced from back-office systems |
| Typical stack | A CMS or static site generator behind a CDN | A front-end framework, an API backend, a database and an identity provider; portals add integration jobs |
| Rendering and search | Static or server-rendered pages so every page can be indexed | Signed-in screens need no indexing; public landing pages stay server-rendered |
| Security baseline | Patch the CMS, protect forms, limit admin access | Access control tested per role and per record, strong authentication, OWASP ASVS requirements |
| Accessibility | WCAG 2.2 for pages and forms | WCAG 2.2 for every task flow, including sign-in |
| Testing | Content, links, forms, page speed and accessibility | All of that, plus automated functional, API, permission and load tests |
| Hosting and support | A CDN or simple hosting, with CMS updates | Application servers or containers, database backups, monitoring and someone on call |
| Cost drivers | Number of templates, content migration and form or CRM integrations | Roles, workflows, integrations, data migration, security testing and ongoing hosting |
What they are
What is Website
A website publishes pages: services, articles, product information and contact forms. Editors usually manage the content in a CMS, and pages are served as static or server-rendered HTML so search engines can index them. Visitors rarely sign in, and stored data is limited to form submissions and analytics.
What is Web app or portal
A web application is software that runs in the browser: users sign in, create and change records, and a backend enforces the business rules and stores the data. A web portal is a web application for a known group, such as clients, patients, partners or suppliers, in which each person sees only their own records and documents.
Key differences
What makes a web application different from a website?
Ask what the user leaves with. A website visitor leaves with information. A web application user leaves having changed something: a booking made, an order placed, a request approved. Once a site stores records that users create, it needs accounts, a database with backups and business rules enforced on the server. That is the point where a website project becomes a software project, with the testing and support that go with it.
Is a web portal just a web application?
Yes, a particular kind. A portal serves a known group, such as clients, patients or suppliers, and joins their data from systems you already run. The hard parts are rarely the screens. They are identity, meaning inviting and verifying users and handling resets; record-level access, so each client sees only their own invoices; and the integrations that keep portal data in step with back-office systems. For what goes inside one, see our client portal and patient portal pages.
How do rendering choices affect search visibility?
Content pages should be static or server-rendered, so their text is in the HTML that crawlers receive. Signed-in screens of an application or portal do not need to be indexed and can run as a single-page application. Most products combine the two: server-rendered marketing pages on a CMS, and a client-rendered application behind sign-in on its own route or subdomain, each deployed on its own schedule.
Which security and accessibility standards apply?
The OWASP Top 10:2025 lists Broken Access Control first, and it becomes the main risk the moment users see their own data. The OWASP ASVS gives a basis for testing web application security controls and a list of requirements for secure development. NIST SP 800-63B, written for federal systems, says verifiers shall offer at least one phishing-resistant authentication option at AAL2, a useful benchmark for portals holding sensitive records. WCAG 2.2 applies to all three; its criterion 3.3.8 Accessible Authentication (Minimum), level AA, says no step of sign-in may require a cognitive function test, such as remembering a password, unless an alternative or aid is offered.
What drives the cost of each?
For a website: the number of page templates, the volume of content to migrate and the integrations behind forms. For a web application: the number of roles, workflows and business rules, the integrations and any data migration. For a portal: user onboarding and identity, back-office integrations and record-level permissions. All three carry running costs after launch, such as hosting, monitoring and security updates, which grow with each step from website to portal.
When to use each
When to use Website
- Visitors come to read, compare and get in touch.
- Search visibility is a main goal of the project.
- Editors need to publish pages without a developer.
- The only data you collect is enquiries or newsletter sign-ups.
When to use Web application or web portal
- App: users complete tasks such as booking, ordering, quoting or managing work.
- App: the core of the product is data users create and change.
- Portal: existing customers or partners need self-service access to their own account.
- Portal: the records come from back-office systems such as a CRM, ERP or billing system.
Has your website become a web application? A checklist
1. People sign in to do something other than edit content.
2. The site stores records that users create or change, beyond contact forms.
3. Different users must see different data.
4. Business rules run on the server, such as pricing, eligibility, approvals or scheduling.
5. Data moves to or from a CRM, ERP or billing system automatically.
6. An outage or a bug stops customers from working, not just from reading.
If two or more are true, plan the work as a web application: keep the marketing site on its CMS so editors stay independent, and build the application beside it with authentication, a database with backups, automated tests and security testing. If none are true and the site only needs a refresh, a website redesign is the right project.