DEV Community: SGEN

How to Audit a Website Tool Stack: A Practical Guide for Agencies

Clark Pesa — Fri, 09 Oct 2026 04:11:36 +0000

A website may look like a single product to the client, but the team maintaining it knows there is usually more behind it.

There may be a website builder, CMS, hosting provider, domain registrar, forms service, analytics platform, backup system, security tool, and several integrations connecting everything.

Each tool may serve a legitimate purpose. The problem starts when nobody has a clear picture of what the stack contains, who owns each part, or why it is still needed.

For agencies managing multiple client websites, this can create unnecessary maintenance work, inconsistent setups, and complicated handoffs.

The solution is not to remove every tool. It is to understand the stack, document its responsibilities, and make deliberate decisions about what stays.

This guide walks through a practical website stack audit that agencies can repeat across their client portfolio.

1. Start With an Inventory, Not a Migration

Before replacing tools or consolidating services, document the current setup.

Choose one representative client website. Ideally, select a site with a reasonably typical set of requirements rather than the simplest or most complicated project.

List the systems involved in running and maintaining it.

Your inventory might include:

Area	What to record
Website builder and CMS	Where pages and content are created and managed
Hosting	Provider, account owner, renewal responsibility
Domain and DNS	Registrar, access owner, renewal date
Forms and lead capture	Form service, delivery destination, integrations
Analytics and SEO	Tools used to measure traffic and manage search visibility
Backups and recovery	Backup location, retention, restore procedure
Security	Relevant security controls, monitoring, ownership
Integrations	Connected services, dependencies, and failure points
Reporting	Where results are collected and who prepares reports

Not every website needs a separate tool for every area. Some functions may already be included in the website platform, hosting environment, or another service.

The purpose of the inventory is to identify what is actually in use, not to create a shopping list of additional software.

2. Record the Responsibility Behind Every Tool

A tool inventory becomes more useful when it explains the work attached to each system.

For every item, add these fields:

Purpose: What requirement does it meet?
Owner: Who is responsible for access, maintenance, and troubleshooting?
Attention frequency: Does it need regular checks, occasional updates, or very little intervention?
Renewal: Which account handles billing, and who receives renewal notices?
Dependencies: What other systems rely on it?
Consistency: Is it configured the same way across other client websites?
Recovery: If it fails, how does the team restore service or recover the relevant data?

This is where an agency may discover that the problem is not the number of tools. It is the lack of clear ownership or documentation.

For example, a service may be working perfectly while its billing account belongs to a former contractor. Another may have a backup status showing success, but nobody has tested whether a restore actually works.

These are operational risks that a list of product names will not reveal.

3. Look for Coordination Problems

Once the inventory is complete, look for patterns rather than evaluating every tool in isolation.

Unowned systems

If nobody owns a tool, its maintenance becomes reactive. Someone eventually has to investigate when a problem appears.

Assign a responsible person and document the tasks they own.

Duplicate functions

Two systems may be doing essentially the same job. That does not automatically mean one should be removed, because there may be a valid reason for keeping both.

Document why each exists and determine whether the overlap is necessary.

Inconsistent configurations

If every client website uses a different setup for the same basic requirement, the team must remember multiple processes and troubleshoot each one separately.

Identify which differences are genuinely required by the client and which have accumulated over time.

Unclear integrations

When one service depends on another, a change to either side may affect the workflow.

Document important connections and determine what needs to be checked when an update or configuration change occurs.

Untested recovery

A backup is only useful if the team understands how to restore the website or data when needed.

Document the restore process and test it in an appropriate environment before relying on it.

4. Decide What to Keep, Consolidate, Replace, or Retire

After identifying the issues, give each tool or capability a clear decision.

Keep

The capability is necessary, it meets the client's requirements, and someone is responsible for it.

A specialized booking or payment service may belong here if the website depends on its specific functionality.

Consolidate

An existing system can perform the same function without losing an essential capability.

For example, two overlapping backup arrangements might be unnecessary if one properly configured system meets the recovery requirements. Test the replacement arrangement before removing the other.

Replace

The requirement remains, but another tool would provide a better fit or reduce unnecessary coordination.

Name the proposed alternative and compare the relevant requirements before making the change.

Retire

The tool no longer serves a clear purpose. A campaign may have ended, an old integration may no longer be used, or a subscription may remain active after its original requirement disappeared.

Before removal, check for dependencies, retained data, contractual obligations, and access requirements.

The important distinction is that every decision should have a reason. Do not remove a useful specialist tool simply to achieve a smaller tool count.

5. Work Through a Fictional Example

Consider a fictional agency maintaining a website for a local landscaping business.

Its inventory identifies a hosting service, a booking widget, two backup systems, a forms tool connected to a separate email delivery service, a security plugin, and a popup tool from a completed seasonal campaign.

The agency might make these decisions:

Item	Finding	Decision
Hosting	Necessary, documented, and consistently configured	Keep
Booking widget	Supports an essential client workflow not covered elsewhere	Keep
Backup systems	Two overlapping systems with untested restoration	Consolidate after testing
Forms	Different from the agency's default setup and adds another integration	Evaluate a replacement
Security plugin	Necessary, but has no named owner	Assign ownership before deciding
Popup tool	Original campaign has ended	Retire after checking dependencies

Notice what the audit does not do. It does not remove every specialized tool, and it does not assume consolidation is always better.

Instead, it identifies specific actions: keep the necessary components, test recovery, remove justified duplication, standardize where appropriate, resolve ownership, and retire what is no longer needed.

The example is illustrative, not a customer case or a claim about measured savings.

6. Turn the Audit Into a Repeatable Process

An audit should not become a one-time spreadsheet that nobody opens again.

Use the findings to establish a basic operating model.

Define a default stack. Document the preferred tools for common requirements such as forms, analytics, and backups.

Document exceptions. When a client needs something different, record the reason and any additional responsibility it introduces.

Assign ownership. Each tool should have an identifiable owner for access, updates, renewals, and troubleshooting.

Standardize recurring maintenance. Create a consistent process for updates, checks, backups, and reporting, while allowing for differences in client requirements.

Test recovery. Establish an appropriate restoration procedure instead of assuming that a successful backup indicator proves everything is recoverable.

Review the inventory. Re-audit a representative website quarterly and whenever a client's requirements materially change.

The goal is not to make every client website identical. It is to make the agency's decisions and processes repeatable.

7. When Should You Consider an Integrated Platform?

After auditing the stack, an agency may find that several basic website functions are spread across different systems on multiple client sites.

That is a reasonable point to evaluate an integrated platform.

A consolidated platform may reduce the number of separate accounts, vendors, and processes the team coordinates. It may also make it easier to establish a consistent default setup across client websites.

However, integration is not automatically the right choice.

Evaluate the depth of the required capabilities, access controls, performance, data portability, integrations, support, security, and recovery options. If a specialist tool meets an essential requirement that the main platform cannot handle properly, keeping it may be the better decision.

For agencies considering this approach, SGEN combines website building, hosting, and content management in one platform, with 23 native modules across seven categories. Its full platform is included across plans, while pricing is differentiated by the number of live websites.

That offers one option for agencies looking to establish a common foundation for the website functions the platform supports. The right choice still depends on the results of the agency's own audit.

Conclusion: Make Every Tool Earn Its Place

A complicated website stack rarely appears all at once. It grows through individual decisions that solve immediate problems.

The practical challenge is knowing which decisions still make sense today.

Start with one client website. Inventory its tools, document their owners and dependencies, identify recurring coordination problems, and decide what to keep, consolidate, replace, or retire.

Then use those findings to build a repeatable process for the rest of the portfolio.

You may discover that the biggest improvement is not another tool or a complete rebuild. It is a clearer, more consistent way to operate the systems you already have.

Your turn: When auditing a client website, what do you usually discover first: duplicate tools, missing ownership, inconsistent setups, or undocumented integrations?

CMS Migration Without Breaking SEO: A Practical Checklist

Clark Pesa — Mon, 28 Sep 2026 08:36:52 +0000

Migrating a website to a new CMS is not just about moving pages and content.

A migration can affect your search visibility when URLs, redirects, metadata, and other SEO elements are not handled carefully.

The good news is that most migration problems are preventable when you plan the move before changing anything.

Here’s a practical checklist to help you protect your SEO during a CMS migration.

𝗕𝗲𝗳𝗼𝗿𝗲 𝗬𝗼𝘂 𝗦𝘁𝗮𝗿𝘁

𝗜𝗻𝘃𝗲𝗻𝘁𝗼𝗿𝘆 𝗘𝘃𝗲𝗿𝘆𝘁𝗵𝗶𝗻𝗴

Start by making a complete list of what exists on the current website.

Include:

• Pages
• Blog posts
• Images and other media
• Forms
• Important URLs
• Other content that matters to the business

Do not rely on just one source for your URL list.

Your sitemap, Google Search Console, analytics, and the current CMS can each show different parts of the website.

A page that looks unimportant can still be bringing in search traffic or backlinks.

𝗥𝗲𝗰𝗼𝗿𝗱 𝗬𝗼𝘂𝗿 𝗖𝘂𝗿𝗿𝗲𝗻𝘁 𝗦𝗘𝗢 𝗕𝗮𝘀𝗲𝗹𝗶𝗻𝗲

Before making changes, record what normal looks like.

This can include:

• Current rankings for important search terms
• Organic traffic
• Pages bringing in organic traffic
• Other important performance data

Take two to four weeks of baseline data before the migration when possible.

Also take a full backup of the existing website before work begins.

𝗗𝗲𝗰𝗶𝗱𝗲 𝗪𝗵𝗮𝘁 𝗦𝘁𝗮𝘆𝘀 𝗮𝗻𝗱 𝗪𝗵𝗮𝘁 𝗚𝗼𝗲𝘀

A migration is a good opportunity to review your existing content.

For every page, decide whether it should be:

𝗞𝗲𝗽𝘁

𝗜𝗺𝗽𝗿𝗼𝘃𝗲𝗱

𝗥𝗲𝘁𝗶𝗿𝗲𝗱

You do not have to carry every old page into the new CMS.

For anything you remove, decide what should happen to the old URL. A genuinely retired page should be handled deliberately rather than sending visitors somewhere irrelevant.

𝗗𝘂𝗿𝗶𝗻𝗴 𝘁𝗵𝗲 𝗠𝗶𝗴𝗿𝗮𝘁𝗶𝗼𝗻

𝗞𝗲𝗲𝗽 𝗜𝗺𝗽𝗼𝗿𝘁𝗮𝗻𝘁 𝗨𝗥𝗟𝘀 𝗪𝗵𝗲𝗿𝗲 𝗣𝗼𝘀𝘀𝗶𝗯𝗹𝗲

Your URLs are what search engines recognize, not just the page itself.

When possible, keep important URLs exactly the same after the migration.

For example:

/about-us

should remain:

/about-us

when there is no good reason to change it.

Keeping the same URLs helps maintain search continuity during the move.

𝗖𝗿𝗲𝗮𝘁𝗲 𝗮 𝗥𝗲𝗱𝗶𝗿𝗲𝗰𝘁 𝗠𝗮𝗽

When a URL has to change, create a simple old-to-new URL map.

For example:

Old URL → New URL

/old-page → /new-page

/services/web-design → /services/website-design

Set up the redirects before the site goes live.

A 301 redirect tells search engines that the old URL has permanently moved to a new address.

Also avoid redirecting removed content to the homepage just to make the old URL work. The destination should be genuinely relevant.

𝗥𝗲𝗺𝗲𝗺𝗯𝗲𝗿 𝗧𝗵𝗮𝘁 𝗖𝗼𝗻𝘁𝗲𝗻𝘁 𝗠𝗶𝗴𝗿𝗮𝘁𝗶𝗼𝗻 𝗜𝘀 𝗡𝗼𝘁 𝗦𝗘𝗢 𝗠𝗶𝗴𝗿𝗮𝘁𝗶𝗼𝗻

Moving your content from one CMS to another does not automatically preserve your search visibility.

Content transfer and redirect mapping are separate jobs.

Your pages and posts may move successfully while the SEO value associated with their old URLs is still at risk.

That is why migration tooling should be evaluated based on what it actually transfers, not just whether it can import content.

𝗥𝗲𝗯𝘂𝗶𝗹𝗱 𝘁𝗵𝗲 𝗗𝗲𝘀𝗶𝗴𝗻 𝗖𝗮𝗿𝗲𝗳𝘂𝗹𝗹𝘆

Moving platforms does not necessarily mean manually retyping all your content.

Pages and posts can often be exported and imported with field mapping.

What usually needs to be rebuilt is the design, because themes do not simply transfer between different platforms.

Build the new site on a private staging environment and keep it hidden from search engines while work is in progress.

𝗕𝗲𝗳𝗼𝗿𝗲 𝗬𝗼𝘂 𝗚𝗼 𝗟𝗶𝘃𝗲

𝗖𝗵𝗲𝗰𝗸 𝗘𝘃𝗲𝗿𝘆 𝗜𝗺𝗽𝗼𝗿𝘁𝗮𝗻𝘁 𝗣𝗮𝗴𝗲

Before changing DNS or pointing the domain to the new website, verify that:

• Pages are present
• Posts are present
• Content is correct
• Images are working
• Navigation works
• Forms work
• Metadata is set

A migration should not use launch day as the testing phase.

𝗧𝗲𝘀𝘁 𝗬𝗼𝘂𝗿 𝗥𝗲𝗱𝗶𝗿𝗲𝗰𝘁𝘀

Take a sample of old URLs and test them against the redirect map.

Make sure they reach the correct new destination.

This is especially important for high-value pages and common URL patterns.

The goal is to catch redirect problems before search engines encounter broken URLs on the live site.

𝗖𝗵𝗲𝗰𝗸 𝗬𝗼𝘂𝗿 𝗦𝗘𝗢 𝗠𝗲𝘁𝗮𝗱𝗮𝘁𝗮

Make sure important pages still have their SEO information in place.

Check things such as:

• Page titles
• Meta descriptions
• Canonical information
• Relevant schema
• Noindex rules where applicable

SEO metadata should be reviewed during the migration rather than treated as cleanup afterward.

𝗔𝗳𝘁𝗲𝗿 𝗟𝗮𝘂𝗻𝗰𝗵

𝗦𝘂𝗯𝗺𝗶𝘁 𝘁𝗵𝗲 𝗡𝗲𝘄 𝗦𝗶𝘁𝗲𝗺𝗮𝗽

Once the new website is live, submit the new sitemap in Google Search Console.

If the domain is also changing, additional migration steps may be required.

Keep the old site and its backup available until the new site is fully indexed.

𝗘𝘅𝗽𝗲𝗰𝘁 𝗦𝗼𝗺𝗲 𝗠𝗼𝘃𝗲𝗺𝗲𝗻𝘁 𝗶𝗻 𝗥𝗮𝗻𝗸𝗶𝗻𝗴𝘀

A temporary dip after a migration can happen.

Search engines need time to crawl the new URLs, process redirects, and update their index.

That does not automatically mean the migration failed.

What matters is whether the site recovers and whether there are specific issues causing a continued decline.

𝗞𝗲𝗲𝗽 𝗠𝗼𝗻𝗶𝘁𝗼𝗿𝗶𝗻𝗴 𝗔𝗳𝘁𝗲𝗿 𝗟𝗮𝘂𝗻𝗰𝗵

Do not stop checking the site immediately after launch.

Review the migration at:

𝗧𝗵𝗶𝗿𝘁𝘆 𝗱𝗮𝘆𝘀

𝗦𝗶𝘅𝘁𝘆 𝗱𝗮𝘆𝘀

𝗡𝗶𝗻𝗲𝘁𝘆 𝗱𝗮𝘆𝘀

Monitor important URLs, traffic, indexing, redirects, and overall site performance.

A short-term dip can be expected. A problem that remains after the initial transition deserves investigation.

𝗙𝗶𝗻𝗮𝗹 𝗖𝗠𝗦 𝗠𝗶𝗴𝗿𝗮𝘁𝗶𝗼𝗻 𝗖𝗵𝗲𝗰𝗸𝗹𝗶𝘀𝘁

☐ Inventoried important pages, posts, media, and forms

☐ Recorded your pre-migration SEO and traffic baseline

☐ Taken a full backup

☐ Decided what content to keep, improve, or retire

☐ Preserved important URLs where possible

☐ Created an old-URL to new-URL redirect map

☐ Set up redirects before launch

☐ Verified SEO metadata

☐ Tested the staging site

☐ Checked pages, content, images, navigation, and forms

☐ Tested important redirects

☐ Submitted the new sitemap

☐ Monitored the site after launch

𝗙𝗶𝗻𝗮𝗹 𝗧𝗵𝗼𝘂𝗴𝗵𝘁

A CMS migration should not start with:

𝗟𝗲𝘁’𝘀 𝗺𝗼𝘃𝗲 𝗲𝘃𝗲𝗿𝘆𝘁𝗵𝗶𝗻𝗴.

Start with:

𝗪𝗵𝗮𝘁 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗻𝗲𝗲𝗱𝘀 𝘁𝗼 𝗺𝗼𝘃𝗲, 𝘄𝗵𝗮𝘁 𝗻𝗲𝗲𝗱𝘀 𝘁𝗼 𝗯𝗲 𝗿𝗲𝗯𝘂𝗶𝗹𝘁, 𝗮𝗻𝗱 𝘄𝗵𝗮𝘁 𝗰𝗼𝘂𝗹𝗱 𝗯𝗿𝗲𝗮𝗸?

The more clearly you scope the migration before launch, the fewer surprises you have to deal with afterward.

Based directly on the existing SGEN migration guide and its seven-step migration process.

How Agencies Should Evaluate a Website Builder for 10+ Client Sites

Clark Pesa — Sun, 13 Sep 2026 23:44:56 +0000

The website builder that works for your first client might not be the right one for your tenth.

When you're starting a web design agency, choosing a website builder is usually about speed, design flexibility, and how quickly you can launch a website.

But once you're managing 10 or more client sites, the decision becomes different.

You’re no longer just building websites. You’re managing a growing portfolio of businesses, each with its own content, branding, deadlines, maintenance requests, and expectations.

A platform that feels convenient for one client can become expensive, difficult to manage, or frustrating for your team at scale.

So how should agencies evaluate a website builder when they have 10+ client sites to manage?

The answer is to stop evaluating website builders like a designer choosing a tool for one project.

Instead, evaluate them like an operator building a repeatable system for delivering and maintaining websites.

Here are the factors that matter most.

1. Start With the Real Cost of Managing 10+ Websites

One of the biggest mistakes agencies make is looking at the monthly price of a website builder and assuming that's the total cost.

It isn't always.

The advertised subscription might only cover the website itself. Your actual cost could also include:

Additional websites or site plans
Team member seats
Hosting
Premium plugins or extensions
Backup services
Security tools
Third-party integrations
Extra storage
Developer time
Client support

When you multiply these expenses across 10, 20, or 50 clients, the difference becomes significant.

Calculate your portfolio cost

Instead of asking:

How much does this website builder cost per month?

Ask:

How much will it cost our agency to operate 10 client websites for an entire year?

A simple calculation:

Total annual platform cost = Site subscriptions + Team costs + Add-ons + Hosting + Maintenance overhead

For example, imagine an agency manages 10 client websites.

If each website requires $20 per month in platform and hosting costs:

10 × $20 × 12 = $2,400 per year

That is before considering additional tools, staff time, or unexpected expenses.

The number is only an illustration, but the principle is important: evaluate the cost of the entire portfolio, not just one website.

What to ask the provider

Does the plan include multiple live websites?
Are there limits on the number of sites?
Are team seats charged separately?
Are hosting and SSL included?
Are there additional charges for storage or traffic?
Can we upgrade individual sites without upgrading everything?
Does the cost remain reasonable as our client portfolio grows?

A good platform should make your costs predictable enough to plan your margins.

2. Evaluate Multi-Site Management, Not Just the Website Editor

A beautiful editor is useful.

But if your agency manages 15 client sites, the editor is only one part of the workflow.

You also need to think about what happens before, during, and after the build.

Can your team easily identify which sites are active?

Can you tell which clients are waiting for content?

Can you manage updates without jumping between disconnected tools?

Can you onboard a new client without rebuilding your entire process?

These questions matter because agencies don't just create websites. They operate websites.

Look for a centralized workflow

Ideally, your platform should make it easy to:

View and organize client projects.
Separate each client's content and access.
Manage websites across different projects.
Reuse proven layouts and components.
Collaborate with your team.
Publish updates efficiently.
Maintain sites after launch.

Not every website builder offers the same level of centralized management.

Some are designed primarily for individual websites. Others are built with agencies and multiple projects in mind.

The right choice depends on how your agency works, but the question remains the same:

Can this platform support our entire client portfolio without creating unnecessary administrative work?

3. Check Whether the Platform Supports Repeatable Delivery

This is where agencies can gain a real advantage.

Imagine you build a website for a local service business.

The next month, you sign another client in a similar industry.

Both clients need:

A homepage
About page
Services page
Contact page
Testimonials
Blog or content section

If your team starts every project from scratch, you're repeating work that could have been standardized.

That doesn't mean every client website should look identical.

It means the underlying process should be repeatable.

What can be standardized?

Depending on the platform, your agency might be able to reuse:

Page structures
Design systems
Typography settings
Navigation patterns
Content models
Form layouts
Common components
SEO checklists
Publishing workflows

A reusable system lets your team spend less time rebuilding basic infrastructure and more time improving the things that make each client unique.

Ask these questions

Can we create reusable templates?
Can we reuse components across projects?
Can we establish a consistent content structure?
Can we maintain brand differences without rebuilding everything?
Can a new team member follow the same workflow?

The goal is not to make every website identical.

The goal is to make the process of building websites more efficient.

4. Look Beyond Pages and Posts

Many agencies start with simple brochure websites.

A homepage, a few service pages, a contact form, and maybe a blog.

That works for many businesses.

But as clients grow, their content requirements often become more complicated.

A client might need:

A directory of locations
A list of team members
A portfolio of projects
A library of case studies
A catalog of products
A collection of events
A database of resources

At this point, forcing everything into ordinary pages and blog posts can become difficult.

The importance of structured content

A website builder should be evaluated based on how well it handles the type of content your clients actually need.

For example, a portfolio website might require a collection of projects.

Each project could have:

Project name
Client name
Industry
Description
Images
Services provided
Completion date

If every project is built as a manually formatted page, maintaining consistency can become harder.

A platform that supports structured or custom content can make it easier to manage information in a consistent way.

This is particularly important for agencies serving clients with growing content libraries.

Ask the provider

Can we create custom content types?
Can we add fields beyond standard pages and posts?
Can structured content be reused across templates?
Can clients manage content without editing the entire layout?
Can the platform support larger content collections?

The more varied your client projects become, the more important this flexibility is.

5. Evaluate Client Handoffs Before You Sign Up

A website isn't finished just because it has been launched.

At some point, your client will probably need to update something.

They may want to:

Change a business description
Add a new service
Upload a blog post
Update a team member
Change contact information
Add a new image

If every small change requires a developer, your agency can end up spending valuable time on routine content updates.

That can create unnecessary support costs for both you and your client.

What does a good handoff look like?

A good handoff should give the client enough control to manage their website without accidentally breaking important parts of the design.

The exact setup depends on the platform and the client's needs.

But you should consider:

Client access

Can the client log in and manage their content?

Permissions

Can you control what the client is allowed to change?

Ease of use

Can a non-technical client understand the editing experience?

Training

Can your team explain the workflow without creating a long technical manual?

Ownership

What happens if the client decides to leave your agency?

A website builder may be powerful, but if the client cannot comfortably use it, the handoff process becomes a problem.

6. Check Hosting, Security, and Performance

Managing 10+ websites means managing 10+ potential sources of technical problems.

A slow website can frustrate visitors.

A broken integration can affect lead generation.

A security issue can damage client trust.

A hosting problem can create an urgent support request.

That's why agencies should evaluate the technical infrastructure behind the website builder.

Important areas to review

Hosting

Is hosting included? Where are the websites hosted? Are there traffic or storage limitations?

Security

Does the platform provide SSL, security updates, access controls, and other relevant protections?

Performance

How does the platform handle page loading, image optimization, caching, and content delivery?

Backups

Are backups available? How does recovery work if something goes wrong?

Reliability

What support is available when a client website experiences an issue?

Don't rely on marketing claims alone

The fastest way to evaluate a platform is to test it.

Build a sample site.

Add images.

Create content.

Publish it.

Test it on mobile.

Check how the editing experience feels.

If possible, test a realistic client workflow instead of only looking at a polished demo.

The goal is to understand how the platform behaves in real agency operations.

7. Compare SEO Capabilities With Your Clients' Needs

SEO is important for many agency websites.

But SEO requirements vary depending on the client.

A local service business may need strong local search visibility.

An e-commerce business may need product pages and structured information.

A content-heavy website may need a flexible publishing system.

A professional services company may need landing pages and clear site architecture.

Your website builder should support the SEO work your agency actually delivers.

Things to evaluate

Page titles and meta descriptions
URL structure
Image optimization
Mobile performance
XML sitemaps
Robots.txt controls
Canonical URLs
Redirect management
Structured data options
Analytics and search integrations

Not every client needs every feature.

But if your agency works with different types of businesses, you should understand the platform's limitations before committing to it.

A builder that works well for a simple brochure site may not be the right fit for a complex content-driven project.

8. Make Sure Your Team Can Work Together

When you have one client, one person might handle everything.

At 10+ sites, your agency may have:

Designers
Developers
Content writers
SEO specialists
Project managers
Account managers

This makes collaboration more important.

You need to know who can access what, who is responsible for changes, and how the team handles approvals.

Questions to ask

Can multiple team members access projects?
Are permissions available?
Can clients have separate access?
Can the team review changes before publishing?
Can you separate client content from internal work?
Is there a clear process for approvals?

A good workflow reduces confusion.

It also helps prevent the classic agency problem:

Who changed this, and why is the website broken?

The platform should support your team's responsibilities instead of making everyone share the same login.

9. Evaluate the Platform's Flexibility as Your Agency Grows

Your agency may start with 10 websites.

Then 20.

Then 50.

The website builder you choose should be evaluated against your expected growth.

This doesn't mean you need the most expensive enterprise platform on day one.

It means you should understand what happens when your needs change.

Consider your growth path

At 10 websites

You may be focused on cost, organization, and repeatable delivery.

At 25 websites

You may need better client management, permissions, and standardized workflows.

At 50+ websites

You may need more advanced governance, support, monitoring, and cost controls.

The platform should not force you to completely rebuild your agency's workflow every time you add more clients.

Ask these questions

What happens when we add 10 more websites?
Can we upgrade without migrating everything?
Can we manage different client requirements?
Will our team need additional tools?
Are there limits that become expensive at scale?

Choose a platform based on where your agency is going, not just where it is today.

10. Run a Real Agency Test Before Making a Decision

A free trial or product demo is useful.

But it should not be the only thing you use to evaluate a website builder.

The best way to compare platforms is to run the same realistic scenario on each one.

A simple test

Choose a typical client project.

For example:

A local business that needs a five-page website, a contact form, a blog, and a content editor.

Then test the following workflow:

Step 1: Build the website

How long does it take to create the basic structure?

Step 2: Add content

Can you create the pages and content types you need?

Step 3: Apply branding

Can you customize the design without excessive work?

Step 4: Invite a team member

Can someone else review or edit the project?

Step 5: Test the client experience

Can a non-technical user update content?

Step 6: Publish

Is the launch process straightforward?

Step 7: Repeat

Can you use the same process for a second client?

This final step is important.

A platform might be easy to use once but difficult to use repeatedly.

For an agency, repeatability is part of the product.

A Practical Website Builder Evaluation Checklist

Before committing to a platform, use this checklist.

Category	Questions to Ask
Cost	What will 10+ sites cost annually?
Multi-site management	Can we manage multiple client sites efficiently?
Templates	Can we reuse layouts and components?
Content management	Can we support different client content requirements?
Client access	Can clients manage their own content?
Permissions	Can we control access by role?
Hosting	Is hosting included?
Security	What protections are provided?
Performance	Does the platform support fast, reliable websites?
SEO	Can we manage the SEO requirements of our clients?
Collaboration	Can our team work together efficiently?
Scalability	What happens when we reach 25 or 50 sites?
Support	Can we get help when something goes wrong?
Handoff	Can we transfer or maintain client ownership appropriately?

You can score each category from 1 to 5.

But don't just choose the platform with the highest score.

Pay attention to the categories that matter most to your agency.

A design-focused agency may prioritize creative flexibility.

A high-volume agency may prioritize cost and repeatability.

An agency working with complex content may prioritize CMS flexibility.

The right platform depends on your business model.

What About SGEN?

For agencies evaluating website builders, it's worth looking at platforms that combine website building, hosting, and content management in one system.

SGEN is one example of this approach.

SGEN positions itself as an alternative to traditional WordPress-based workflows, bringing website building, hosting, and content management together.

For agencies, the appeal of an all-in-one platform is the opportunity to reduce the number of separate tools involved in delivering and maintaining client websites.

Instead of managing a website builder, hosting provider, and multiple add-ons separately, an agency can evaluate whether a unified platform fits its workflow.

SGEN also focuses on structured content and native functionality, which can be relevant for agencies building websites with more than basic pages and blog posts.

However, the important question isn't whether a platform sounds good.

It's whether it works for your agency.

Before choosing SGEN or any other website builder, test the platform against your actual requirements.

Can it support your client sites?

Can your team use it efficiently?

Can your clients manage their content?

Does the pricing make sense at your portfolio size?

Those are the questions that should drive your decision.

Final Thoughts

Choosing a website builder for 10+ client sites is not simply a design decision.

It's an operational decision.

The wrong platform can create unnecessary costs, repetitive work, difficult handoffs, and technical headaches.

The right platform can help your agency build a more consistent process, serve more clients, and spend less time managing avoidable complexity.

When evaluating a website builder, look beyond the editor.

Evaluate:

The real cost of your entire portfolio.
Multi-site management.
Repeatable delivery.
Content flexibility.
Client handoffs.
Hosting and security.
SEO capabilities.
Team collaboration.
Long-term scalability.

Most importantly, test the platform with a real agency workflow.

Because the best website builder for your first client is not necessarily the best website builder for your tenth.

Choose the platform that helps your agency operate better, not just build faster.

How Agencies Should Evaluate a Website Builder

Clark Pesa — Wed, 02 Sep 2026 02:55:49 +0000

Most website builder evaluations happen at the worst possible moment: while you are building the first site on it.

At that moment, the platform is on its best behavior. Empty canvas, excited client, and every builder on the market feels fine when you are running one of anything.

You ship. The client is happy. You conclude the tool is good.

Then eight months pass.

You have eleven client sites. Three are on a plan tier you no longer remember choosing. One has a plugin that has not been updated since spring. A client emailed asking to change a phone number and you had to log in as them because there was no safe way to give them access to only that.

Your Tuesday now has a standing two-hour block called "site stuff."

Nothing broke.

You built an operation on a tool you evaluated as a design product.

So the question worth answering before you commit a client roster is not:

Can I build a good site on this?

Almost certainly you can.

The better question is:

What does my week look like when there are twenty of them?

1. Multi-site management: what does the second site cost you in attention?

The first thing to test is not a feature. It is a shape.

At ten client sites, where do you see them?

One place that lists all of them, or ten islands with their own logins, dashboards, and update states you have to check individually?

The follow-up questions matter more than they sound:

Can you see the state of every site without opening every site?
Does adding a client add an entire workflow, or simply add another site to manage?
Can a team member access three client sites without accessing all twenty?
What is the administrative overhead per client per month, and does it stay flat or climb?

Some platforms answer this with a portfolio or multi-site dashboard.

Others assume one site per account and expect you to add a third-party management layer.

Both can work.

They are not the same amount of work, and the difference compounds with every client you sign.

2. Repeatable delivery: how much of the last project survives into the next one?

Agencies do not become more efficient simply by building faster.

They become more efficient when proven work can be reused instead of recreated.

So look at what the platform lets you carry forward.

Staging

Can you build and revise somewhere that is not the client's live site?

Is staging a real environment, or a copy you have to keep synchronized manually?

Reusable structure

When you get a service-page layout right, can it become the starting point for the next client?

Or does every project begin from a blank canvas plus your memory of what worked last time?

Components and templates

Can proven patterns be reused?

Or is every instance another independent copy that can eventually drift?

Setup work

How much of a new project is actual design and development?

And how much is reconfiguring the same settings you configured for the previous client?

The useful measure here is not simply speed.

It is variance.

A repeatable process means the tenth site can follow a proven workflow instead of becoming another custom operational problem.

3. Client access and handoff: launch is the middle of the workflow, not the end

The site goes live.

Then the client wants to update their hours.

Swap a photo.

Add a staff member.

Publish a new page.

Now you have a permanent access decision.

Before choosing a platform, ask:

What is the least access that still lets a client do what they need?
Can you prevent them from reaching layout, settings, integrations, or billing?
If something goes wrong, is there a record of who changed what?
How do you support the client afterward?
Do you need their password?
When ownership transfers, what actually moves?

Password sharing is a useful warning sign.

If your support workflow requires storing or repeatedly requesting client credentials, that operational burden gets repeated for every client you onboard.

4. Maintenance: the architecture decides how much you inherit

Every live client site can generate recurring work.

Core updates.

Security patching.

Backups.

Extension compatibility.

Troubleshooting.

Support requests.

Whether that work becomes profitable depends partly on your agency model. If maintenance is included without being priced properly, it becomes overhead. If maintenance is intentionally sold as a service, it can become revenue.

The underlying platform architecture matters here.

With an assembled stack, a core platform can be extended with third-party tools and plugins.

That can provide enormous flexibility.

But every additional dependency can also introduce its own updates, compatibility requirements, pricing, and maintenance.

With a more native platform, more functionality is maintained within one system.

That can mean fewer separate systems to assemble and maintain, but potentially less flexibility when you need functionality outside the platform.

Neither approach is automatically correct.

The important thing is knowing which operating model you are choosing.

5. Price the tenth client site, not the first

This is one of the most useful ways to think about agency software:

Price the tenth client site, not the first.

Entry pricing is usually evaluated by someone running one website.

A growing agency will not stay there.

Model the platform at the size you expect your client roster to become, not only the size it is today.

Pricing models can differ structurally.

Some platforms charge per site.

Some charge per account.

Some charge based on the number of live sites.

Others combine site plans, workspaces, seats, and additional services.

So build your model with every line that scales:

Platform charges
Per-site costs
Team seats
Feature tiers
Hosting
Paid extensions or plugins
Renewal pricing
Maintenance time

That final line is easy to overlook.

Your team's time is part of the platform cost.

A platform with a lower subscription price can still be more expensive operationally if every client site creates additional recurring work.

The number you actually want is:

What is the fully loaded cost of one more live client site?

Then model that across the roster you are planning to build.

6. Native platform or assembled stack?

Underneath many of these decisions is an architectural trade-off.

An assembled stack

An assembled stack starts with a core and adds additional parts.

The ceiling can be extremely high.

If a client needs unusual functionality, there may already be a tool or plugin for it. If there isn't, a development team may be able to build it.

The trade-off is that your agency owns more of the integration and maintenance.

A native platform

A native platform ships more functionality as part of one system.

There are fewer separate pieces to assemble and potentially fewer independent systems to maintain.

The trade-off is that when you need something outside the platform's capabilities, your options may be narrower.

The right choice depends on how your agency works.

Ask yourself:

Do our clients regularly require highly specialized functionality?
Are most projects variations of a repeatable website model?
Is ongoing maintenance a service we intentionally sell?
Or is maintenance overhead we are trying to reduce?

That last question can completely change which platform makes sense.

7. Where SGEN fits

SGEN is an example of the native-platform side of this decision.

It is a website builder and CMS positioned for growing web design agencies that prefer a more native, out-of-the-box setup.

Some of the capabilities relevant to agency operations include:

Site Manager for managing multiple client sites from one dashboard
Stage and Live environments for working between staging and production
Clone-forward workflows for using a proven build as the starting point for another site
Sandbox for building staging sites before taking them live
Built-in user roles and login-as-client for client access and support workflows
Foundation Pack covering infrastructure including hosting, SSL, CDN, WAF, and security patching
23 native modules available across the platform rather than unlocked through feature-based plan tiers

SGEN prices plans based on the number of live sites rather than unlocking different product capabilities at different tiers.

That is one pricing model among several, not automatically the correct one for every agency.

Run it against your own roster.

There are trade-offs too.

SGEN is a newer platform without the long independent review history of established website builders. Client billing and invoicing are not currently listed as native capabilities in its published documentation, and migrating a WordPress website involves rebuilding rather than a one-click design import.

That matters.

Choosing an agency platform should be about fit, not pretending every platform solves every problem.

For agencies that want to reduce the number of separate systems behind each client site, SGEN represents one approach worth evaluating.

For agencies whose work depends heavily on a large third-party ecosystem or whose business model intentionally revolves around technical maintenance, another architecture may make more sense.

8. The agency website builder checklist

Before committing your client roster to a platform, answer these ten questions.

1. How will we manage 10+ client sites?

One dashboard or ten separate workflows?

2. What does another live client site actually cost?

Include the platform, seats, hosting, extensions, and your team's time.

3. What can we reuse from one project to the next?

Structures, components, staging environments, templates, or only memory?

4. What access can we safely give clients?

And what can they accidentally change?

5. What maintenance does the platform create?

Per site, per month, and who absorbs it?

6. Which capabilities require additional tools or plugins?

Count them. Then price and maintain them.

7. How does client handoff work?

Think about the account, billing, content, permissions, and ongoing support.

8. What happens when the team grows?

Consider per-seat costs and permission controls.

9. What happens if the client wants to leave?

What can be exported? What needs rebuilding? What gets left behind?

10. Does this platform fit how our agency actually makes money?

Design margin?

Development?

Recurring services?

Maintenance retainers?

The answer matters more than any feature comparison table.

The takeaway

The right website builder for an agency is not necessarily the one that makes the first site easiest.

What matters is whether its operating model still makes sense at ten sites, twenty sites, with a growing team, clients who need access, and a maintenance load that someone has to carry.

Evaluate the platform as part of your agency operation, not just as a design tool.

SGEN published a deeper comparison of seven agency website builders across pricing, ease of use, features, and project management.

👉 Read the full agency website builder comparison on SGEN

You can also explore SGEN for agencies.

What did your agency underestimate when choosing its website platform?

For many teams, maintenance only becomes visible once the client roster starts growing.

The Hidden Cost of a Plugin-Heavy Website Stack

Clark Pesa — Fri, 28 Aug 2026 03:15:08 +0000

A website rarely starts with 20 plugins.

It usually starts with a simple requirement.

You need a contact form, so you install a form plugin.

You need better control over SEO, so you add another.

Then come redirects, analytics, backups, security, caching, popups, and a page builder.

Each tool solves a real problem. But over time, something else happens: the website becomes a stack of independently maintained software.

And that stack becomes part of what you have to manage.

The problem isn't simply the number of plugins

There isn't a magic number where a website suddenly has "too many" plugins.

A site with a larger collection of well-maintained plugins can work perfectly well, while a much smaller stack can cause problems if one component is poorly maintained or conflicts with another.

The more useful question is:

Do you know what every part of your stack is doing and why it's still there?

Plugin stacks tend to accumulate over time.

A developer installs one tool. An agency takes over and adds its preferred tools. A temporary marketing campaign requires another plugin. Months later, the campaign is gone but the plugin remains.

Eventually, nobody is completely sure which tools are essential, which overlap, and which can safely be removed.

Every dependency has an operational cost

The price of a plugin is only one part of its cost.

Each third-party dependency can introduce another:

Release cycle to follow
Update to test
Vendor to depend on
Potential compatibility issue
Configuration to maintain
Subscription or license to renew

For one website, that overhead might be manageable.

For an agency maintaining dozens of client sites, however, the same maintenance work gets repeated across an entire portfolio.

That's where architecture starts becoming a business decision rather than just a technical one.

Start by auditing the stack

Before replacing anything, understand what you already have.

A simple plugin audit can start with four questions:

What does this plugin actually do?
Does another tool already provide the same functionality?
Is the plugin still actively maintained and necessary?
Could the platform handle this capability natively instead?

Grouping plugins by capability rather than by name can make overlaps easier to spot.

You may discover that multiple tools are handling parts of the same job.

Native functionality changes the equation

There is another approach to website architecture: moving common functionality into the platform itself.

Instead of installing separate products for common requirements, a platform can provide capabilities such as forms, SEO controls, redirects, analytics, backups, security, and content management natively.

That doesn't mean specialized tools are obsolete.

There are plenty of situations where a dedicated product is the better choice. Complex ecommerce requirements, advanced conditional forms, or highly specialized business workflows may need functionality that an integrated platform doesn't provide.

The advantage of native functionality is not that it can replace every specialized tool.

It's that you don't have to assemble the basics from scratch.

This is one of the ideas behind SGEN

At SGEN, we've taken the integrated approach.

SGEN is a website builder and CMS where core website capabilities are built into the platform as native modules rather than assembled through a traditional plugin stack.

The goal isn't to argue that plugins are inherently bad. Plugins have made platforms like WordPress incredibly flexible.

The question we're interested in is different:

How much third-party dependency should a modern website actually require?

For teams managing multiple websites, reducing unnecessary dependencies can mean fewer separate systems to maintain and a more predictable workflow.

We've also put together a deeper guide on auditing plugin dependency, including how to identify overlapping functionality and decide what should stay, be replaced, or be handled natively.

Read the full WordPress plugin dependency audit on SGEN

The takeaway

A plugin-heavy stack isn't automatically a bad stack.

The real warning sign is a stack that has grown without anyone periodically asking why each dependency is still there.

Whether you stay with WordPress, move to an integrated platform, or build your own architecture, the same principle applies:

Every dependency should earn its place.

When was the last time you audited everything your website depends on?

Why We’re Building SGEN Differently: A CMS Without the Plugin Stack

Clark Pesa — Tue, 25 Aug 2026 23:52:51 +0000

Hi DEV Community 👋

We’re SGEN, and this is our first post here.

SGEN is a flat-rate CMS built around a simple idea: website teams should spend less time managing the stack and more time building and growing their sites.

The problem we wanted to address

Modern websites often depend on a growing collection of separate tools.

A CMS handles content. Plugins add functionality. Another service handles forms. Another handles analytics. Hosting lives somewhere else. Security needs its own setup. SEO introduces another set of tools.

Each addition can solve a problem, but it can also create another dependency to maintain.

For agencies managing multiple websites, that complexity can multiply quickly.

A different approach

SGEN brings essential website capabilities into the platform through 23 native modules.

Instead of building around a large collection of third-party plugins, the goal is to provide the tools teams regularly need within one CMS.

SGEN also includes hosting, security, SEO, and server-side rendering as part of the platform.

And our pricing follows the same philosophy:

Pay for sites, not features.

The 23 native modules are included across our plans. As your needs grow, you're primarily scaling the number of live sites rather than unlocking individual features one tier at a time.

Why we're joining DEV

We don't want this organization to simply become another place to post product announcements.

We'll be sharing what we're learning about:

CMS architecture
Website performance
SEO and technical SEO
Managing multi-site workflows
Native modules vs. plugin-heavy stacks
Building and maintaining websites at scale

We'll also share some of the decisions, tradeoffs, and problems we're encountering as SGEN continues to evolve.

We're looking forward to learning from the DEV community as well.

What creates the most friction in the CMS or website stack you use today?

We'd love to hear about it.