Choosing between Aura and LWR affects far more than page speed. The template sets the component model your team can use, how much prebuilt site behavior you get, how pages are rendered, how public content is indexed, and how much rebuilding may be required later. For a new Experience Cloud project in 2026, this decision should happen before page design or component estimates because the framework choice shapes the rest of the build.
The short answer is that most new custom sites should start with LWR when the required features and components are supported. Aura still has a valid place when a site depends on Aura components, mature prebuilt portal features, or an existing implementation whose migration cost is hard to justify. The useful question is which framework fits the site’s functional dependencies, delivery model, public performance needs, and maintenance path.
TL;DR
• For a new custom build, Experience Cloud Aura vs LWR usually points toward LWR when the team can build with Lightning Web Components and the needed site features are available.
• Aura remains practical for existing communities with Aura components or for use cases that rely on mature prebuilt Experience Builder components and templates.
• LWR uses Lightning Web Components only. Aura-based sites can use both Aura components and Lightning Web Components.
• LWR gives you a lighter runtime, publish-time static assets, CDN delivery, and server-side rendering options that matter most for public and high-traffic experiences.
• An Aura-to-LWR move is a planned rebuild and migration. It requires component replacement, CSS review, URL planning, permission checks, analytics work, and regression testing.
What Experience Cloud Aura vs LWR Means in 2026
Experience Cloud Aura vs LWR determines the site’s framework and template architecture inside Experience Builder. Salesforce currently supports Experience Cloud sites built on LWR, Aura, and Visualforce frameworks. The LWR path centers on Build Your Own (LWR) and other LWR-based experiences, while Aura underpins templates such as Customer Service, Partner Central, Help Center, Customer Account Portal, and Build Your Own (Aura). Salesforce’s own framework planning guidance tells teams to consider business goals, technical skills, and long-term cost before selecting a framework, which is the right way to frame the decision.
The biggest technical split is the component model. A Build Your Own LWR template runs only Lightning Web Components, while Aura-based templates can host both Aura components and Lightning Web Components. Salesforce documents that distinction in its Experience Builder template guidance, and it has direct consequences for reuse. An org with years of custom Aura components can’t assume those components will move into an LWR site unchanged.
That difference also changes how teams divide work. Salesforce Experience Cloud projects built on Aura can often start with more ready-made portal patterns. LWR gives developers more control over the front end, but custom component work becomes a larger part of delivery when standard components don’t cover the requirement. In 2026, the gap is smaller than it was in the early LWR years, yet the dependency review still matters before choosing a template.
Architecture And Runtime Differences
Aura and LWR deliver pages through different front-end architectures. Aura is Salesforce’s older Lightning component framework. It can render Aura components and LWCs in the same site, which makes it useful for organizations that have a mixed component estate. The Aura template family also carries years of portal-oriented components and page patterns that many existing communities already use.
Lightning Web Runtime takes a lighter approach built around web standards and Lightning Web Components. In an LWR site, the user interface and framework assets are prepared as static resources when the site is published, while Salesforce record data remains dynamic. Salesforce’s Trailhead guide to LWR explains that static content is compiled during the site build and stored on Salesforce’s CDN, which reduces the amount of framework work the browser must do for every visit.
This is why an LWR template can feel very different even when the page design looks similar. In Salesforce Experience Cloud, the runtime choice becomes visible through how quickly that published shell reaches the browser. The runtime does less work to assemble the same shell on every request. A page can still pull live CRM data, execute supported business logic, and respond to the signed-in user’s permissions. Static delivery applies to the front-end framework and published assets, not to a frozen copy of Salesforce records.
For architects comparing Experience Cloud Aura vs LWR, this is the first major dividing line. Aura offers broader backward compatibility with older Lightning work. LWR removes Aura from the component path and asks teams to standardize on LWC. That trade can reduce front-end overhead and make future component work more consistent, but only after older dependencies have been accounted for.
Performance And Rendering Behavior
Performance is the strongest technical reason to favor LWR for a new public-facing build. The Build Your Own LWR template was created for faster site delivery, and Salesforce lists publish-time freezing and HTTP caching among its performance features. The official Build Your Own LWR documentation also ties the template to the LWC programming model and browser-native web standards.
The practical gain depends on what you build in Salesforce Experience Cloud. Heavy images, slow Apex, oversized JavaScript, large third-party scripts, or inefficient data calls can still make an LWR site slow. Moving to Lightning Web Runtime doesn’t excuse basic front-end discipline. It gives the site a leaner starting point, so teams have less framework overhead to fight while they work on the parts they control.
Lightning Web Runtime can also use server-side rendering for supported scenarios. With SSR, the browser can receive rendered component markup before all client-side JavaScript has finished executing. Salesforce’s server-side rendering overview notes that this can improve time to content and allow rendered output to be cached in a CDN. That matters for public pages where first render and crawl behavior are important.
For more selective rendering, LWR supports islands-style hydration patterns in Experience Cloud. Salesforce documents how hydration capabilities for Experience Cloud can determine which components are server-rendered, hydrated for browser interaction, or left client-rendered. This gives developers more control over how much JavaScript a page needs at initial load.
Aura can still deliver acceptable performance when the site is well built and its use case is mostly authenticated portal work. The point in Experience Cloud Aura vs LWR is that LWR gives performance-sensitive projects more modern rendering choices at the framework level. If public acquisition, content discovery, or high visit volume is central to the site, that advantage deserves more weight.
Component Model And Compatibility
Component compatibility is where many framework decisions are won or lost. An Aura-based site can host Aura components and Lightning Web Components, which lets a team preserve older investments while adding newer LWCs over time. A LWR site doesn’t run Aura components. Any required Aura component must be replaced with an LWC, a standard LWR component, or a different supported pattern.
This makes inventory work essential. Before committing to Experience Cloud Aura vs LWR, list the custom components used on every critical page, then separate them into Aura, LWC, managed package, standard Experience Builder, and embedded third-party features. For each item, confirm whether the same function exists in the target framework. A single unsupported login, navigation, commerce, or case-management dependency can change the delivery estimate more than dozens of simple content components.
Custom LWCs for Experience Builder also need the right metadata targets. Salesforce’s component configuration reference explains how lightningCommunity__Page, lightningCommunity__Page_Layout, lightningCommunity__Theme_Layout, and lightningCommunity__Default control where a component appears and which properties authors can edit. A component that works in Lightning App Builder doesn’t automatically become a well-designed Experience Builder component.
LWR also gives developers page-layout features that are specific to LWR sites. For example, Salesforce documents the LWR page layout target, which lets a custom LWC define named slots that Experience Builder treats as page regions. This is useful when the site needs a controlled layout system instead of one-off page composition.
The safest 2026 approach is to treat LWC as the default for new custom component work even when the current site remains on Aura. That keeps new code usable across more Experience Cloud scenarios and reduces the amount of Aura-specific work that may need replacement later.
Experience Builder And Design Control
Both frameworks use Experience Builder, but the building experience isn’t identical. Aura templates often bring more predefined site behavior. That can reduce custom development for familiar portal use cases, especially when standard components already cover knowledge, case, navigation, or account needs. Build Your Own Aura still provides the core pages expected for an Experience Builder site, and Salesforce documents its standard behavior in the Build Your Own Aura template reference.
LWR is more developer-centered when the site moves beyond standard components. That can be a benefit for design systems because developers can define reusable LWCs, exposed properties, responsive behavior, and page regions instead of relying on site-wide CSS overrides. It also puts more responsibility on the team to create author-friendly components rather than hard-coded pages.
Theme work illustrates the difference. LWR supports custom theme layout components built as LWCs. Salesforce’s theme layout target documentation describes how a theme component exposes the main content region through slots and becomes selectable in the Theme area of Experience Builder. That makes site chrome such as headers, navigation wrappers, and shared layout behavior part of the component system.
CSS migration needs special care. Aura sites may contain selectors aimed at standard Aura markup. Those selectors won’t reliably map to LWR markup. A clean LWR build should move styling into component CSS, design tokens or supported styling hooks, static resources, and intentional head markup rather than carrying old selectors forward without review.
For Salesforce Experience Cloud teams with strong admins but limited front-end development capacity, Aura can still reduce initial build effort in some portal scenarios. Teams with a mature LWC practice usually gain more from the structure and design control of LWR.
SEO And Public Site Behavior
SEO matters most when Experience Cloud pages are public and expected to attract search traffic. LWR’s lighter front end and server-side rendering options give it a better technical base for fast first paint and crawlable page output, but framework choice alone doesn’t make a site rank. Page titles, headings, useful content, internal navigation, canonical handling, access settings, and stable URLs still decide whether search engines can understand the site.
Salesforce provides built-in SEO controls for Experience Builder sites. Its SEO best-practices guidance recommends using generated sitemaps rather than maintaining a custom sitemap and describes canonical links, robots rules, and guest-user data exposure. These controls apply to public site planning regardless of whether the runtime is Aura or Lightning Web Runtime.
URL behavior is a migration issue as well. Aura sites commonly use the /s/ path in their default site URLs, while LWR doesn’t require it. If an existing Aura site has indexed pages, changing to an LWR template without a redirect map can create broken links and lost search signals. Salesforce specifically recommends mirroring page base URLs where possible and planning redirects during migration.
Experience Cloud Aura vs LWR therefore has a clearer answer for net-new public marketing, help, or content experiences. LWR is usually the stronger starting point when the required content and components are supported. For a private partner portal that search engines never see, SEO should carry little weight in the framework decision.
Security And Data Access
Security should be assessed at the site and component level, not inferred from the template name. Aura and LWR Experience Cloud sites use platform controls such as Content Security Policy and Salesforce security layers for Lightning components. Guest-user access, object permissions, sharing rules, Apex access, record visibility, and third-party script policy still need explicit review.
Salesforce’s Experience Cloud security guidance explains how CSP, Lightning Web Security, and Lightning Locker affect custom code and third-party components across Aura and LWR sites. The exact security layer can depend on org and site settings, so teams should test the configuration they will actually deploy rather than rely on framework assumptions.
LWR also changes how developers think about data access. The front end may be lighter, but secure Salesforce data access still depends on supported APIs, component code, Apex where needed, and the user’s permissions. Public pages deserve extra scrutiny because a fast public component that exposes too much data is still a security failure.
For existing Aura communities, migration creates another access-control task. A new LWR site gets its own guest user, so guest-user profile permissions and sharing rules must be reviewed and recreated where required. Authenticated-user access may carry over through existing profiles, permission sets, and sharing, but new custom objects or new components can introduce additional access needs.
This is one reason a migration estimate shouldn’t be based on page count alone. Security regression testing has to cover anonymous users, each external user type, key record-sharing paths, uploads, embedded services, and any feature that calls Apex or external systems.
What Changed For Aura And LWR In 2026
The 2026 release cycle shows why Salesforce Experience Cloud teams shouldn’t base the decision on old LWR limitations lists. Salesforce keeps adding standard components and developer features to LWR, while shared Experience Cloud features continue to reach both Aura and LWR sites. Spring ’26, for example, added more standard component options for LWR and made custom property types and editors generally available for Experience Cloud component development. The Spring ’26 Experience Cloud release notes also list improvements to LWR development workflows and site behavior.
Summer ’26 continued the pattern of shared site capabilities rather than cutting Aura off. Salesforce added AI-assisted self-service features for Aura and LWR sites, broader file features, and Experience Builder changes in the Summer ’26 release notes. This matters because Aura remains supported for existing sites even though much of Salesforce’s newer front-end direction centers on LWR and LWC.
The practical lesson is to verify current feature support instead of repeating a comparison written 2 or 3 years ago. A missing LWR component from an older blog may exist now. A beta feature may have changed status. A workaround may no longer be needed. The correct 2026 decision should come from a current component inventory and the latest Salesforce documentation.
Salesforce Experience Cloud teams should also distinguish framework direction from forced migration. An Aura site doesn’t become invalid simply because LWR receives newer front-end features. Existing Aura sites can remain sensible when they meet performance needs and depend on functionality that would be expensive to rebuild.
When An Aura Template Still Makes Sense
Aura is still reasonable when the value of compatibility exceeds the benefit of rebuilding. The clearest case is an established portal with custom Aura components that are stable, tested, and tied to important business flows. Rewriting those components only to change frameworks can introduce risk without changing what users can do.
Aura also fits projects that depend heavily on mature prebuilt Experience Builder features available through templates such as Customer Service or Partner Central. Salesforce’s site framework design guidance notes that Aura templates provide a larger library of ready-made components and can suit teams with fewer developer resources. That remains a practical consideration for portals where business function matters more than public page performance.
Choose Aura deliberately when one or more of these conditions is true:
• A required managed package or custom feature depends on Aura components and has no supported LWC replacement.
• The existing site already meets user experience and performance targets, and migration has little business payoff.
• The delivery team relies on standard portal components that would require custom LWC work in LWR.
• A near-term project deadline leaves no safe window for component replacement, redirect work, and full regression testing.
• A staged modernization plan is already replacing Aura components with LWCs before a later framework move.
The important distinction is between choosing Aura because a dependency requires it and choosing Aura because it is familiar. Familiarity alone is a weak reason for a new build in 2026. A dependency with clear migration cost is a strong reason.
When An LWR Template Is The Better Starting Point
A new custom site should usually favor an LWR template when its required functions are supported and the team can work in LWC. That choice aligns the site with Salesforce’s current web component model and removes the need to create new Aura-specific front-end code. It also gives the project a cleaner base for performance work, public search visibility, and reusable LWC design patterns.
Lightning Web Runtime is especially suitable for public support experiences, branded portals with custom UI, high-traffic authenticated experiences, and sites where front-end teams want component-level control. The case becomes stronger when page speed affects conversion, support deflection, or user completion rates. It is also a good fit when the organization already builds most Salesforce UI in Lightning Web Components.
For Experience Cloud Aura vs LWR decisions, LWR should carry extra weight when these conditions apply:
• The build is new and has no Aura component debt.
• Required standard components have confirmed LWR support or acceptable LWC replacements.
• Public page performance or SEO has material business value.
• The team has LWC skills and can create Experience Builder-ready components.
• The architecture is expected to live for several years and should avoid adding new Aura dependencies.
Lightning Web Runtime isn’t a shortcut around requirements discovery. It can reduce framework overhead, but it can also increase custom development when the project assumes Aura-era components will be present. The right LWR decision comes from verified feature coverage. A preference for newer technology is too weak to justify the framework on its own.
Migrating From Aura To LWR
Migration is where Experience Cloud Aura vs LWR becomes an implementation program rather than a comparison table. Salesforce advises teams to plan the move carefully because custom components, page layouts, CSS, analytics, URLs, guest access, CMS use, and redirects can all change. Its Aura-to-LWR migration considerations provide a useful baseline for the discovery checklist.
Start with a site inventory rather than rebuilding pages immediately. Record every page type, URL, component, audience rule, login flow, navigation item, head script, stylesheet, CMS source, analytics tag, guest permission, sharing rule, and embedded service. Mark which items have direct LWR equivalents and which require redesign. This exposes the true migration scope before development starts.
Replace Aura Components Before Page Rebuilds
Custom Aura components are hard blockers because an LWR site can’t run them. Replace or retire them first. When the current Aura site can host an equivalent LWC, deploying the LWC there before the site move can reduce migration risk because the component can be tested with real users and data before the runtime changes.
Rebuild Layout And Styling Intentionally
Don’t copy Aura CSS selectors into a new site and hope the markup matches. Recreate the site’s visual system using LWC component CSS, supported styling hooks, static resources, and LWR page or theme layouts. This is also the right time to remove CSS rules that existed only to override old template markup.
Preserve URLs Where Possible
Keep equivalent page base URLs when the content purpose stays the same. Build a redirect map for the /s/ differences and any changed record, article, or custom page paths. Test redirects before moving the custom domain. Search crawlers, browser bookmarks, email links, and external documentation may all depend on the old URLs.
Recheck Access And Operational Integrations
Recreate required guest-user access for the new site’s guest user. Retest authenticated sharing paths. Reconfigure analytics and head scripts where necessary. Verify CMS content, sitemaps, robots behavior, login flows, email actions, file operations, and any Visualforce bridge that the Aura site currently uses.
A successful migration ends with side-by-side functional testing before traffic moves. That includes desktop and mobile layouts, accessibility checks, logged-out behavior, each major user role, error paths, analytics events, redirects, and performance measurements on representative pages.
Decision Framework And Delivery Effort
The Experience Cloud Aura vs LWR decision should be made from evidence collected during discovery. Avoid scoring a framework on generic labels such as modern or legacy. Score the actual site against component compatibility, authoring needs, rendering goals, SEO exposure, developer capacity, migration work, and long-term maintenance.
| Decision Area | Aura | LWR |
| Custom Component Support | Aura components and LWCs can coexist | LWCs only |
| Prebuilt Portal Coverage | Broader in several mature Aura templates | Growing, but verify each required component |
| Front-End Runtime | Aura framework with Lightning components | LWC-focused Lightning Web Runtime |
| Public Performance Base | Can perform well with careful implementation | Lighter runtime with stronger modern rendering options |
| SSR Options | Client-side oriented framework path | Supported for applicable LWR components and pages |
| Existing Aura Reuse | Direct fit | Requires replacement of Aura components |
| Developer Need | Can be lower for template-led portal builds | Often higher for custom experiences |
| Migration From Existing Aura Site | No framework migration required | New build and migration planning are usually required |
Delivery effort follows the same pattern. A small new site with a capable LWC team may be quicker on LWR because there is little old code to accommodate. An established partner portal with many Aura components can be far more expensive to rebuild, even if the final LWR site has a cleaner front end. No credible estimate can be based only on framework name or page count.
For Salesforce Experience Cloud planning, use a short proof of concept when one or 2 uncertain dependencies could decide the architecture. Build the hardest component, test the required data access, and verify Builder authoring before committing the whole site. This costs less than discovering late that a critical package, embedded feature, or authoring requirement behaves differently in the chosen framework.
The final Experience Cloud Aura vs LWR decision should answer 4 questions: Can the target framework support every critical user journey? Can the team maintain the component model? Does the runtime meet public performance and search needs? Is the migration cost justified by measurable business or technical value? When those answers are documented, the template decision becomes much less subjective.
Conclusion
Experience Cloud Aura vs LWR in 2026 is best treated as a dependency and architecture choice. For most new custom builds, LWR is the stronger starting point because it uses Lightning Web Components, gives public sites a lighter delivery model, and receives many of Salesforce’s newer front-end capabilities. That advantage is meaningful only when the required site functions are confirmed on LWR and the team has the skills to build what isn’t provided out of the box.
Aura remains a sound choice for existing sites with valuable Aura components, mature portal behavior, or migration costs that exceed the expected benefit. It can also be practical for template-led portal work where ready-made Experience Builder features reduce custom development. The mistake is treating an existing Aura site as obsolete without examining what it does and what a rebuild would cost.
For new work, the Experience Cloud Aura vs LWR choice should start with LWR unless a verified dependency points elsewhere. For existing Aura sites, modernize component by component, measure the current site’s real problems, and migrate when the business case is stronger than the disruption. That approach keeps the framework choice tied to user needs and maintainable code instead of platform fashion.
FAQs
What Is The Main Difference Between Aura And LWR In Experience Cloud?
Aura-based Experience Cloud sites can use both Aura components and Lightning Web Components. LWR sites use Lightning Web Components only and run on the lighter Lightning Web Runtime architecture.
Is LWR Replacing Aura In Salesforce Experience Cloud?
Salesforce continues to support Aura sites and still ships some features that apply to both Aura and LWR. Existing Aura sites can remain in place when they meet requirements, while newer front-end development increasingly centers on LWR and LWC.
Which Is Better For A New Experience Cloud Site In 2026?
LWR is usually the better starting point for a new custom site when all required features are supported and the team can build in LWC. Aura can still be the better fit when a project depends on Aura-only components or mature template functions that would otherwise need custom work.
Can Aura Components Run In An LWR Site?
No. An LWR site can’t run Aura components. Required Aura components must be replaced with Lightning Web Components, standard LWR components, or another supported implementation.
Can Lightning Web Components Run In An Aura Site?
Yes. Aura-based Experience Cloud sites can use Lightning Web Components as well as Aura components. This makes it possible to replace older custom Aura components gradually before a future LWR move.
Does LWR Always Make An Experience Cloud Site Faster?
LWR provides a lighter runtime and stronger rendering options, but site speed still depends on the implementation. Large scripts, inefficient data calls, heavy media, and slow server-side logic can still create poor performance.
Is LWR Better For SEO Than Aura?
LWR has a stronger technical base for public performance and can use server-side rendering for supported components. SEO still depends on indexable content, clean URLs, metadata, internal linking, access settings, and useful pages.
Do LWR Sites Support Server-Side Rendering?
Yes, supported LWR scenarios can use server-side rendering and hydration patterns. Components must meet the relevant SSR requirements, so teams should test the actual component tree rather than assume every custom LWC can render on the server without changes.
Is The Build Your Own LWR Template Low Code?
Experience Builder provides visual page composition. Custom LWR sites often need more developer work than mature Aura templates, so teams should expect LWC development when standard components don’t cover the requirement.
When Should An Existing Aura Site Stay On Aura?
Staying on Aura can make sense when the site meets current needs and relies on stable Aura components or prebuilt portal features that would be costly to replace. Migration should solve a real problem such as performance limits, design constraints, or mounting maintenance work.
Is Moving From Aura To LWR A Simple Template Change?
No. An Aura-to-LWR move normally involves creating an LWR site and planning component replacement, layout work, CSS changes, URLs, permissions, analytics, and testing. It should be treated as a migration project.
What Happens To Aura CSS During An LWR Migration?
CSS that targets Aura template markup usually needs review because LWR markup and styling patterns differ. Rebuild styling around component CSS, supported styling hooks, static resources, and intentional LWR layouts rather than carrying selectors over blindly.
Do I Need To Rewrite Every LWC When Moving To LWR?
No. Many well-built LWCs can be reused, but they still need to be checked for Experience Builder targets, unsupported APIs, security behavior, styling assumptions, and SSR requirements if server rendering is planned.
How Should I Estimate Aura-To-LWR Migration Cost?
Estimate from the inventory of components, pages, URLs, integrations, CSS, permissions, analytics, CMS use, and testing needs. Page count alone misses the work created by custom Aura components and operational dependencies.
What Should Decide Experience Cloud Aura vs LWR For My Project?
Base the decision on critical feature support, component compatibility, team skills, performance needs, public SEO requirements, migration effort, and expected maintenance. A short proof of concept is useful when one uncertain dependency could change the framework choice.
