How to Use Brizy Page Builder: Setup, Workflow, and Site Management for Small Teams

If your team manages multiple websites and needs a visual builder that works without deep developer involvement, Brizy lets you design, edit, and publish pages through a drag-and-drop interface without writing code. By the end of this tutorial, you will have Brizy installed, configured, and ready to build or manage pages across your site portfolio.

What You Need Before You Start

Who This Tutorial Is For

This guide is written for small teams managing anywhere from five to fifty websites — agencies handling client portfolios, in-house digital teams running brand microsites, or SaaS companies maintaining landing pages alongside a main product site. If you are a solo hobbyist running a single personal blog, the workflow steps here will technically work but the emphasis on team access, multi-site reuse, and template consistency will not apply to your situation.

This tutorial also assumes you are evaluating or already committed to Brizy as your primary builder for some or all of those sites. It does not assume you are running every site on WordPress; Brizy's Cloud product offers its own hosted path that bypasses WordPress entirely, which is a meaningful option when you need to spin up a new site without provisioning fresh hosting.

Expected Outcome When This Tutorial Is Complete

After working through all five sections, you will have:

• Brizy installed and activated on at least one target site, with your license verified
• A working page built using Brizy's visual editor, including at least one reusable block or saved section
• Team access configured so collaborators can edit without requiring full admin credentials
• A repeatable deployment pattern you can apply across additional sites in your portfolio
• A clear picture of where Brizy's workflow fits well for your team and where it requires workarounds

That final point matters as much as the technical setup. Understanding the practical edges of any page builder — where it accelerates work and where it creates friction — is what separates a tool that sticks from one that gets abandoned after two projects.

Steps 1 to 3: Installing, Activating, and Orienting Yourself in Brizy

Getting a page builder running across multiple client or team-managed sites is never purely a technical exercise. The decisions you make in the first three steps — how you install, what you activate, and how you structure your first real editing session — shape how maintainable those sites become at scale. Here is exactly how to move through the opening phase of learning how to use Brizy page builder without backing yourself into a corner later.

Step 1: Install Brizy on Your WordPress Site

Brizy is available in two forms: a free version through the WordPress plugin repository, and Brizy Pro, which unlocks the full feature set your team will realistically need when managing five or more production sites. Start by logging into your WordPress dashboard and navigating to Plugins > Add New. Search for "Brizy" and install the core plugin first, even if you intend to run Pro. The free plugin acts as the base layer that the Pro licence then extends.

Explore Brizy Through Our Partner Link

Once installed and activated, a Brizy menu item appears in your left sidebar. At this stage nothing has changed about your site's front end — activation simply registers the builder and creates its internal data structures. Before touching any page, take sixty seconds to check that your theme does not output its own conflicting full-width template. Most modern themes include a blank or full-width template; select that for any page you intend to build in Brizy. Skipping this check is the most common source of unexpected header and footer duplication when teams rush the setup.

How to verify Step 1 is complete: The Brizy menu appears in wp-admin, no plugin conflict notices are showing, and a test page with a blank template loads without the theme's default page title or sidebar bleeding into the canvas area.

Step 2: Install and Connect Brizy Pro

If your team is managing multiple sites professionally, the free tier will hit its limits quickly. Knowing how to install Brizy Pro correctly matters because the licence connection method differs from a typical plugin ZIP upload.

After purchasing a Pro plan, you receive a licence key from your Brizy account dashboard. Return to wp-admin, go to Brizy > Settings, and enter that key in the activation field. Brizy then downloads and installs the Pro extension automatically — you do not upload a separate ZIP file. This licence-key model is particularly useful for agencies managing distributed sites, since a single account holds all your licences in one place rather than requiring per-site manual uploads.

One practical nuance: a single Pro licence covers a defined number of active site installations. If your team regularly spins up staging environments, count those as licence seats unless you deactivate them between uses. Deactivating a licence on a staging domain before cloning to production is a two-minute habit that prevents licence limit headaches at the worst possible moment.

After Pro activates, return to Brizy > Settings and confirm the licence status reads as active. You should also see the Global Blocks, White Label (if applicable to your plan), and Template Library options become available in the sidebar. Their visibility is the clearest signal that the Pro connection succeeded.

How to verify Step 2 is complete: Licence status shows active in Brizy Settings, and the Template Library entry appears in the Brizy sidebar with Pro templates loading inside it.

Step 3: Orient Yourself in the Brizy Editor Before Building Anything

The instinct to open a blank page and start dragging elements is understandable — and almost always the wrong move for teams who will need to maintain these sites long-term. Spending twenty minutes on orientation before laying a single block pays back that time many times over.

Open any existing page or create a throwaway test page, then click Edit with Brizy. The editor loads in a full-screen canvas. The interface is organised around three spatial areas you need to internalize immediately.

The left panel houses your element library — rows, columns, global blocks, saved layouts, and the template library. For teams learning how to set up Brizy for building and managing websites efficiently, the saved layouts section is where your most significant time savings come from. Layouts can be saved once and deployed across every site you manage.

The canvas itself is click-to-select. Hovering over any element reveals its bounding outline and a small contextual toolbar. Single-clicking selects the element; the right-side settings panel then updates to show that element's styling controls. A double-click enters text editing mode. This two-level interaction model — select then edit — is distinct from some other builders and trips up new users who expect inline text editing on the first click.

The top toolbar controls device preview switching, undo/redo, and publish state. Critically, Brizy uses an autosave draft model. Changes are saved to draft automatically as you work, but they do not go live until you explicitly click Publish or Update. For a team environment where one person builds and another reviews, this distinction prevents accidental live deploys.

Before leaving this orientation step, test the responsive preview controls. Switch between desktop, tablet, and mobile views using the device icons at the top. Any layout adjustments you make in mobile view apply only to that breakpoint and do not retroactively alter your desktop layout. Teams that miss this detail early often find themselves unwinding hours of styling work after realising a mobile change unexpectedly cascaded — or, more commonly, that mobile was never styled at all before launch.

How to verify Step 3 is complete: You can navigate all three interface zones without confusion, you have confirmed the autosave-versus-publish distinction, and you have successfully switched between at least two device breakpoints and observed that breakpoint-specific controls appear in the settings panel.

Steps 4 to 6: Building Pages, Managing Styles, and Publishing Across Sites

Once your initial structure is in place, the real productivity gains from learning how to use Brizy page builder come from working efficiently across multiple pages and sites. Steps 4 through 6 cover where small teams tend to either accelerate or stall: building out page content with reusable logic, keeping visual styles consistent without manual repetition, and pushing finished work live in a controlled way. Each of these stages rewards teams that set up habits early, and punishes teams that improvise at scale.

Step 4: Build Page Content Using Sections, Columns, and Global Blocks

Open the page or template you want to edit and click into the Brizy canvas. The editor loads inline — you are working directly on the visual output rather than toggling between a backend form and a preview. This matters practically: what you see during editing reflects what visitors will see, without needing a separate preview step for every change.

Start by adding a section. Sections are full-width horizontal containers that stack vertically down the page. Inside each section, you arrange columns. Columns define the horizontal layout within that section — one column for a full-width hero, two columns for a side-by-side feature block, three for a feature grid, and so on. Drag the column divider to adjust proportions, or set exact percentage widths if your layout calls for precision.

Inside columns, you drop elements from the left panel: text blocks, images, buttons, icons, spacers, video embeds, forms, and more. Each element has its own settings panel that appears on the right when selected. Text elements give you inline formatting controls — font family, size, weight, line height, letter spacing, and colour — without leaving the canvas. Image elements let you set alt text, link targets, and responsive display behaviour from the same panel.

For teams managing multiple sites, the element that changes workflow most is the Global Block. When you convert a section into a Global Block, that section becomes a shared asset. Edit it once, and the change propagates to every page across every site where that block is placed. A shared header, footer, announcement banner, or contact call-to-action no longer requires manual updates across dozens of pages. This is the mechanism that makes how to use Brizy genuinely different for teams running five or more sites versus a single personal project.

To create a Global Block, right-click any section and select the option to save it as global. Give it a recognisable name — something your whole team will understand, not just you. Once saved, that block appears in your Saved Blocks library and can be inserted onto any page in any project tied to your account.

Responsive editing is built into the canvas controls. A row of device icons at the top of the editor lets you switch between desktop, tablet, and mobile views. Changes made in desktop view cascade down by default, but you can override spacing, font sizes, padding, and element visibility at each breakpoint independently. For small teams that cannot afford separate mobile QA cycles on every publish, building responsiveness into the initial page build — rather than fixing it afterwards — saves considerable time per site.

One practical workflow consideration: if your team splits page-building duties between a designer and a content editor, Brizy's inline editing means both roles work in the same environment. There is no separate content management layer to learn. The content editor types directly into the page, adjusting text without touching layout. The designer controls column proportions, spacing, and styling without needing to export or hand off files. For teams in the five-to-fifty site range, removing that handoff step per page per site compounds into meaningful time savings over a quarter.

Step 5: Apply and Manage Global Styles for Visual Consistency

Consistency across a portfolio of sites is one of the hardest operational challenges for small teams. When each site gets built independently, fonts drift, button colours vary, and spacing feels slightly off from one project to the next. Learning how to set up Brizy for building and managing websites at any real scale means understanding its global style system before you publish your first page.

See How Brizy Fits Your Workflow

Access global styles from the main editor toolbar — typically through a settings or style icon at the top. Here you define the typography scale for the entire site: base font family, heading sizes from H1 through H6, body text size, and the line height and letter spacing defaults for each. Set these once and every text element on every page of that site inherits them automatically. You are not setting styles element by element.

The colour palette works on the same principle. Define a set of brand colours — primary, secondary, accent, background, text — and those colours become the available swatches throughout the editor. When you or a teammate picks a colour for a button, heading, or background, you are choosing from the defined palette rather than entering a hex value freehand. If a brand colour changes, updating it in global styles updates every element across the site that references that colour token.

For teams managing sites for multiple clients, this architecture has a direct operational implication. Each site carries its own independent global styles. Switching between client projects means the editor loads that client's typography and colour system automatically. There is no risk of accidentally applying one client's brand to another's site, provided you are working in the correct project. The discipline required is simply ensuring each site's global styles are set up accurately during initial configuration, rather than left at defaults.

Button styles deserve specific attention. Brizy lets you define default button appearance — border radius, padding, font weight, colour states for normal, hover, and active — at the global level. Teams that define button styles globally and resist the temptation to override them element by element end up with sites that look deliberate rather than improvised. If your team has a habit of customising buttons on individual pages, the visual result after fifty pages on five sites is inconsistency that requires audit and cleanup. Build the habit of using global button styles from the first page.

One tradeoff worth naming: Brizy's global style system operates per site

Troubleshooting Brizy: Common Failures, Fixes, and Validation Checks

When you are learning how to use Brizy page builder across a portfolio of sites, troubleshooting becomes a team skill rather than a solo scramble. The failures that trip up small teams managing multiple properties tend to fall into predictable categories: editor load problems, styling conflicts, broken global blocks, and publish inconsistencies. Working through each category methodically saves far more time than restarting the process from scratch every time something looks wrong.

The Editor Fails to Load or Opens Blank

A blank or spinning editor is one of the most disorienting problems when you are mid-build. The most common causes are JavaScript conflicts introduced by other active plugins, browser extension interference, or an outdated cache layer between the server and the browser. Start with the simplest fix: open the editor in a private or incognito browser window with no extensions active. If the editor loads cleanly there, the culprit is almost certainly a browser extension such as an ad blocker or script manager.

If the incognito test still fails, deactivate all plugins except Brizy, reload the editor, then reactivate plugins one at a time. This binary search approach is slower than guessing, but it reliably isolates conflicts without destructive changes to your live content. Pay particular attention to caching plugins, security scanners with JavaScript blocking rules, and optimization plugins that defer or concatenate scripts — these categories conflict with page builders more often than any others.

Server-side PHP memory limits below 256 MB can also prevent the editor from initializing. On a shared host or a small cloud instance, check your wp-config.php for the WP_MEMORY_LIMIT constant and raise it if it is set below that threshold. Your host's documentation will clarify whether you need to make the change in php.ini instead.

Styles Look Different on the Published Page Than in the Editor

A visual gap between the editor preview and the live front end is a theme conflict or a caching issue in roughly equal measure. When global styles defined in Brizy's Style Manager appear correct inside the editor but render incorrectly on the published page, start by purging every caching layer in sequence: the Brizy internal cache, your caching plugin cache, your server-level cache (Nginx FastCGI, Varnish, or similar), and your CDN edge cache if one is active. Only after all layers are cleared can you be certain what you are looking at is the actual output.

If the gap persists after a full cache purge, open your browser's developer tools, inspect the element that looks wrong, and trace which CSS rule is winning the specificity battle. Themes that enqueue their own stylesheet at a late priority sometimes override Brizy's generated classes. In most cases, adjusting the rule inside Brizy's custom CSS field or adding a small specificity bump resolves the conflict without touching the theme files.

Global Blocks or Saved Sections Are Not Updating Across Pages

Global blocks are one of Brizy's most useful features for teams maintaining consistent headers, footers, and call-to-action rows across many pages. When an edit to a global block does not propagate as expected, the most common explanation is that the block was saved as a normal saved block rather than a true global block. These two options look similar in the interface but behave very differently: saved blocks are independent copies, while global blocks maintain a single source that updates everywhere simultaneously.

If you are certain the block is global and edits still are not appearing, check whether the page receiving the change has a cached version that predates the update. A full cache purge at the page level, rather than site-wide, is often enough. Also verify that no one on the team saved an override to that specific page; local page-level customizations can mask global block changes in some configurations.

How to Install Brizy Pro and Validate the License Connection

Teams setting up Brizy for the first time on a new site sometimes find that Pro features are unavailable even after installing the plugin. The most common cause when learning how to install Brizy Pro is an incomplete license activation rather than a missing file. After uploading and activating the Pro plugin, navigate to the Brizy settings panel and confirm the license key field is populated and shows a connected status. If it shows an error, deactivate and reactivate the plugin once, then re-enter the key. License servers occasionally time out on the first connection attempt.

For teams managing five or more sites, confirm that your plan supports the number of active license connections you need before deploying. Adding a domain when you are at your plan's site limit will silently fail the activation in some configurations. Checking the license dashboard on brizy.io before deployment avoids this entirely.

Responsive Layout Breaks on Mobile or Tablet

Responsive failures are among the most visible bugs because they affect real visitors immediately after publish. When a layout that looks correct in the desktop editor collapses, overflows, or stacks incorrectly on mobile, the starting point is Brizy's built-in responsive preview toggle. Switch between breakpoints in the editor itself before reaching for a physical device, because the editor preview and the live site should match closely if no external CSS is interfering.

Columns set to fixed pixel widths rather than percentage-based or fluid widths are the most frequent source of overflow on small screens. Review any column or container where you manually typed a pixel value into the width field and convert those to percentage equivalents. Padding and margin values set in pixels rather than using responsive overrides at the tablet and mobile breakpoints compound the problem on smaller viewports.

Images Appear Blurry, Cropped Incorrectly, or Fail to Load

Image display problems often trace back to either the original file dimensions or a conflict with a lazy-load or image optimization plugin. Brizy generates

Did It Work? Go-Live Checks for Brizy-Built Sites

Before you push a Brizy-built page in front of real visitors—or hand it off to another team member—run through two distinct evaluations. The first is binary: either the page does what it should, or it does not. The second is contextual: whether the site is genuinely ready for the workload your team expects. Small teams managing multiple sites often skip the second step and pay for it later when a client flags a broken mobile menu or a global style block that drifts between sites.

Binary Objective Checks

Each item below has a clear pass or fail state. Do not move to the readiness assessment until every item on this list returns a pass.

• The published page URL resolves without a redirect loop or 404 error in a fresh browser session with no cached data.
• Every section and row renders at three viewport widths: desktop (1280 px or wider), tablet (768 px), and mobile (375 px). Verify inside Brizy's responsive preview and in an actual device or browser dev tools—both, not just one.
• All images load from the correct source. Missing image placeholders, broken src paths, or images loading from a staging domain instead of production are a definitive fail.
• Any global block or global style you configured propagates correctly across every page where it is used. Open at least two different pages and confirm the header and footer match.
• Forms, buttons, or links you placed with Brizy point to the correct destination and do not return a server error on submission or click.
• The page passes a basic browser console check with no JavaScript errors that are attributable to Brizy elements. Note third-party script errors separately; they are out of scope for this check but must be logged.
• If you installed Brizy Pro, the license is active on this domain and Pro-only elements—such as advanced popups or additional shape dividers—render as expected rather than falling back to a free-tier placeholder.

Ready to Go Live? Subjective Readiness Assessment

Passing the binary checks means the page works. It does not mean the page is ready for your specific situation. The readiness questions below are editorial judgments your team makes, not automated pass/fail states. Work through them deliberately.

Content Completeness

Are all placeholder texts and sample images replaced with final, approved content? On teams managing many sites simultaneously, it is common for one site to go live with a lorem ipsum paragraph still sitting in a testimonial block. Brizy's visual editor makes placeholder text look finished, which makes this mistake easier to miss than on a text-based editor.

Brand Consistency

If you are using Brizy's global styles to control typography and color, verify that every page using those styles reflects the current approved brand palette—not an earlier draft. If a client or stakeholder changed a brand color mid-build, confirm the global style was updated and not overridden at the block level in a way that creates inconsistency.

Performance Awareness

Brizy's visual editor makes it easy to add images, video backgrounds, and layered sections without immediately considering load weight. Before going live, run the page through a performance diagnostic tool such as Google PageSpeed Insights or GTmetrix. This is not a Brizy-specific failure—it applies to any visual builder—but it is worth confirming before publishing to a live domain.

Handoff and Access

If another team member, a client, or a contractor will edit this site after launch, confirm they have the correct Brizy access level. Review whether any protected or role-restricted content is visible to the wrong users. If you are using Brizy Cloud, confirm the workspace and collaboration settings are correct for ongoing management.

Backup State

Confirm you have a restorable backup of the site at its current go-live state. Whether that is a hosting-level snapshot, a WordPress backup plugin export, or a saved version within your deployment workflow, this backup should exist before you push to production—not after.

Troubleshooting and Implementation FAQs

Current plans and pricing: Use our partner link to view current plans, pricing, and any available offers. Final pricing and promotional terms are set by the provider and may vary by plan, billing cycle, usage, region, and eligibility.

Check Brizy Fit and Current Options