Website Stack: CMS, Hosting, Security & Payments

The best website stack is not the one with the longest feature list.

It is the one the business can operate safely after the person who launched it stops thinking about the launch.

Every stack creates recurring work somewhere. A hosted builder hides much of the server administration inside the subscription. A self-hosted CMS exposes more control but also more decisions. A custom application can solve unusual problems while creating a larger maintenance burden than a small business may need.

Choose for the next few years of operation—not for the excitement of the first weekend.

Choose a Hosted Builder or an Open CMS by Operating Model

The first architectural decision is usually whether the business wants a hosted platform to manage most infrastructure or wants greater control over the application and hosting environment.

A hosted platform is often the stronger choice when nobody in the business wants to administer software or hosting.

WordPress becomes more attractive when the business needs:

• custom editorial workflows;
• large content libraries;
• specific plugins or integrations;
• control over hosting and caching;
• custom post types or structured content;
• more direct control over code and database access; or
• a migration path that does not depend entirely on one proprietary website builder.

Do not choose WordPress merely because it can do more. Unused flexibility still creates maintenance decisions.

SEO Is Not a Reason to Choose One Platform Automatically

Google’s current SEO guidance focuses on whether it can crawl and understand useful content, not on rewarding a particular CMS brand.

Modern CMS platforms and builders can generally produce crawlable pages, titles, links, sitemaps, and mobile layouts when configured correctly.

Choose the platform because it supports the business workflow. Then verify the resulting pages rather than assuming the platform label guarantees SEO performance.

Keep Domain, DNS and Ownership Under Business Control

The domain is often more important than the website software.

If the domain is lost, hijacked, or allowed to expire, the website, business email, and other services using that domain can all be affected.

Use a registrar account that the business controls rather than leaving the domain permanently inside a freelancer’s personal account.

Record:

• registrar name;
• account owner;
• renewal date;
• billing method;
• DNS provider;
• nameservers;
• who can change DNS; and
• where recovery codes or emergency access information are stored securely.

Use Registrar Lock and Strong Authentication

ICANN explains that a domain can be placed in a registrar-lock status to protect against unauthorized changes or transfers.

Keep transfer protection enabled when you are not intentionally moving the domain.

Turn on multifactor authentication for the registrar and DNS provider when available. CISA recommends MFA across business systems and says organizations should aim for phishing-resistant methods such as FIDO/WebAuthn where practical.

Choose Hosting by Responsibility, Not Marketing Labels

Hosting labels such as “shared,” “cloud,” “managed,” “VPS,” and “dedicated” describe different parts of the architecture, but vendors do not always use the words identically.

Instead of buying the label, ask what the provider actually manages.

A low-cost unmanaged server can be excellent for a business with competent administration.

It can be a poor bargain for a business that has nobody responsible for security updates, database failures, web-server configuration, or incident recovery.

Automate HTTPS and Keep the Software Current

HTTPS protects data in transit between the browser and website.

Most hosted website platforms and many managed hosts automatically provision and renew certificates.

If you manage the server yourself, use automated certificate management rather than relying on calendar reminders.

Let’s Encrypt uses the ACME protocol for automated certificate issuance and renewal and recommends automated clients such as Certbot for many self-managed environments.

Automation is becoming even more important as Let’s Encrypt moves toward shorter default certificate lifetimes. A manual renewal process becomes increasingly fragile when certificates are designed to rotate more frequently.

Keep WordPress, Themes and Plugins Updated

WordPress’s official security guidance says the most important WordPress security practice is keeping WordPress itself and installed plugins and themes up to date.

For a WordPress site:

• use maintained plugins and themes;
• remove software you no longer use;
• review updates regularly;
• use automatic updates where the risk and testing process make sense;
• keep a recovery path in case an update breaks compatibility;
• restrict administrator access; and
• avoid downloading themes or plugins from untrusted sources.

Updates are not only a WordPress issue. Hosted builders reduce application-maintenance work because the vendor controls the platform, but you still remain responsible for user accounts, third-party integrations, custom scripts, business data, and configuration choices.

Back Up for the Failure You Are Trying to Survive

A backup stored on the same server as the live website may not help when the server fails, an attacker deletes files, or the account itself is compromised.

A practical backup plan answers:

• What is backed up?
• How often?
• Where is the backup stored?
• How long are copies retained?
• Can an attacker with website-admin access delete the backups too?
• How long would restoration take?
• Who knows how to restore?

Back up the parts required to recreate the site, which can include:

• database;
• uploaded files;
• themes or custom code;
• configuration;
• DNS records where appropriate;
• integration settings or documentation; and
• deployment or infrastructure configuration for more advanced stacks.

Match Frequency to How Much Data You Can Lose

There is no universal rule that every small website needs one backup per day.

A brochure site changed once a month has a different recovery requirement from an e-commerce site receiving orders every few minutes.

Decide how much data loss the business could tolerate, then choose a backup frequency that fits that requirement.

Whatever schedule you choose, periodically restore a copy into a safe test environment. A green “backup completed” email does not prove the backup is usable.

Use Least Privilege, MFA and Monitoring

Website security is easier when fewer accounts can make destructive changes.

Give each person a separate account and the minimum permissions needed for the job.

For example:

• authors should not automatically become administrators;
• contractors should not retain permanent administrator access after a project ends;
• payment staff do not necessarily need hosting access;
• hosting support credentials should not be shared through ordinary email; and
• old accounts should be removed promptly.

CISA recommends MFA for business systems and specifically prioritizes privileged and administrative access.

WordPress’s current brute-force guidance also recommends strong unique passwords, two-factor authentication for administrator accounts, and rate limiting or edge protections where appropriate.

CDN and WAF: Useful, but Not Magic

A content delivery network can cache content closer to visitors and reduce load on the origin server.

A web application firewall can block or challenge some known attack patterns before traffic reaches the application.

These tools can be useful when:

• visitors are geographically distributed;
• the origin server needs protection from traffic spikes;
• the site regularly attracts automated malicious traffic;
• the business wants edge rate limiting or bot controls; or
• the host does not already provide equivalent functions.

They do not replace patching, secure accounts, backups, or safe application design.

Also check whether the host or builder already includes CDN, DDoS mitigation, or WAF capabilities before adding another layer that complicates debugging.

Design E-Commerce Around the Payment Boundary

If the website accepts cards, decide which system is actually responsible for collecting payment-card data.

For a small business, the safest architecture is often to avoid having the merchant’s own application collect card numbers directly.

Common patterns include:

• Hosted checkout: the customer is redirected to a payment provider’s hosted page;
• Embedded iframe: the payment provider delivers the payment fields inside the merchant’s webpage;
• merchant-controlled payment page: the merchant site supplies some or all elements involved in collecting card data.

These architectures can have very different PCI DSS implications.

SAQ A Does Not Mean “No PCI Work”

PCI SSC says SAQ A eligibility for e-commerce requires the payment-page elements to originate only from PCI DSS-compliant third-party service providers and requires all other SAQ A eligibility conditions to be met.

For an embedded payment page or iframe, current SAQ A eligibility also requires the merchant to confirm that its site is not susceptible to script attacks that could affect the e-commerce system.

That specific script-attack eligibility criterion does not apply in the same way when the merchant redirects customers away from its site to the third-party processor, but other SAQ A requirements still apply.

There is another current requirement that older website guides frequently miss.

PCI SSC clarified in June 2026 that SAQ A e-commerce merchants are subject to applicable external vulnerability scanning by a PCI-approved scanning vendor (ASV), including merchants whose websites redirect payment to a third-party service provider or use an embedded third-party iframe.

Avoid custom card forms unless the business has a real reason and the technical capability to operate the larger compliance and security scope.

Plan for Performance and Migration Before You Need Them

Performance problems often come from accumulated decisions rather than the original platform.

Common causes include:

• oversized images;
• too many third-party scripts;
• heavy page-builder components;
• poor caching;
• slow database queries;
• unoptimized fonts;
• advertising or analytics scripts; and
• hosting that no longer matches traffic.

Google’s current Core Web Vitals use:

• LCP for loading performance, with a recommended good threshold of 2.5 seconds or less;
• INP for responsiveness, with a recommended good threshold below 200 milliseconds; and
• CLS for visual stability, with a recommended good threshold below 0.1.

Those metrics are useful operating signals, not a reason to rebuild a functioning website purely to chase a perfect performance score.

Know What You Can Export

Before committing to a platform, find out what happens if you leave.

Can you export:

• pages and posts;
• images and files;
• customer records;
• orders;
• product data;
• redirects;
• SEO fields;
• forms or submissions;
• member accounts; and
• custom structured data?

Some visual layouts, apps, automations, or platform-specific functions may not migrate cleanly even if the raw content can be exported.

Keep ownership of the domain independent from the platform whenever practical, document DNS records, and maintain a list of critical integrations. That makes a future migration less dependent on institutional memory.