Hidden infrastructure subscriptions: what service website owners actually pay for

Start with the website’s real recurring stack

“Website cost” is rarely a single invoice. A small service business may pay one company for hosting, another for the domain, a third for DNS or a content delivery network (CDN), separate vendors for premium plugins, and another service for form or transactional-email delivery. An agency or former developer may also hold one of those accounts on the business’s behalf.

That fragmentation is what makes infrastructure spending feel hidden. Some charges are unnecessary. Others look duplicative but protect a different failure mode. A backup stored independently from the host, for example, may be deliberate resilience rather than waste.

The important distinction is between the billing vendor and the capability the website depends on. A charge with an unfamiliar merchant name is not safe to cancel until you know what capability it provides.

The subscription trap is usually duplication, drift or unclear ownership

A useful audit looks for four different problems rather than labelling every add-on as “waste”:

• Duplicate capability: two services do substantially the same job, such as host-level caching plus a separately purchased caching service.
• Plan drift: the service is still needed, but the plan is larger than the website now requires.
• Orphaned subscriptions: a licence, monitoring project, staging environment or add-on remains active after the feature or supplier that needed it has gone.
• Ownership drift: the business relies on a service, but the login, renewal email or billing relationship still belongs to an employee, freelancer or agency.

Ownership drift can be more expensive than the subscription itself. The UK National Cyber Security Centre (NCSC) advises organisations to keep public-domain management under organisational control because loss of a domain can affect the website, email and other services that depend on it. Its guidance also recommends protecting the account used to manage the domain. See the NCSC’s guidance on protecting a public domain name.

For a deeper check of registration, DNS and certificate ownership, use ScanMySEO’s domain, DNS and certificate ownership risk framework.

Do not confuse subscription cost with website performance

The old shortcut is tempting: if you are paying for many services, the site must be slower. That is not a safe conclusion.

A paid backup service can run entirely away from the visitor-facing page. A monitoring service may make no browser request at all. By contrast, a chat widget, A/B-testing platform or other third-party script can add network and JavaScript work to the page. The performance effect depends on how the service is implemented, not whether it appears as a recurring charge.

The same caution applies to SEO. Google says Core Web Vitals are used by its ranking systems, but also says good Core Web Vitals do not guarantee top rankings and that page experience should not be reduced to one or two metrics. Use performance evidence to decide whether a specific implementation needs changing; do not claim that cancelling a subscription will improve rankings. Google’s page experience guidance explains this distinction.

Image optimisation is a good example. Native browser lazy-loading can defer off-screen images, but it does not automatically replace every capability of a paid image service such as resizing, format conversion, storage or CDN delivery. It can also be harmful when applied to the page’s Largest Contentful Paint (LCP) image. web.dev recommends eager-loading images visible in the initial viewport and avoiding lazy-loading for LCP images. See browser-level image lazy-loading guidance.

A subscription audit that does not break the site

Use the sequence inventory → map → classify → test → change → verify. It takes slightly longer than cancelling unfamiliar charges, but it reduces the chance of discovering what a service did only after a domain, form, backup or certificate stops working.

Step 1: build the billing inventory

Start with evidence from both finance and the website stack. Check business cards and bank statements, PayPal or other payment accounts, invoice emails, registrar and hosting dashboards, CMS licence screens, agency invoices and any password manager or internal handover document.

For each charge, record:

• billing name and product name;
• amount, currency and billing interval;
• next renewal date;
• website or domain it relates to;
• account owner, administrator and recovery email;
• the capability it provides;
• whether the same capability exists elsewhere;
• what data or configuration it stores;
• what would stop working if it were removed;
• how it can be exported, restored or replaced.

Normalize mixed billing periods so the total is understandable. A simple monthly run-rate is:

monthly charges + (annual charges ÷ 12) + (multi-year charges ÷ number of months in the term)

This is an accounting aid, not a market-price benchmark. It exposes the true recurring stack using your invoices rather than guessed “typical website costs”.

Step 2: map every charge to a capability and an owner

Do not ask only “Do we use this?” Ask two more useful questions: What does it do? and Who can recover it?

A capability map makes overlaps visible. If the host advertises backups and you also pay for a backup service, document both before choosing one. If a CDN account also hosts authoritative DNS, cancelling the plan or deleting the zone can have a much larger effect than simply removing caching. If a plugin licence looks inactive, confirm whether it still supplies updates or a service used by the production site.

For WordPress sites in particular, the project’s documentation recommends keeping plugins and themes updated and notes that site owners should have a rollback path before automatic updates. That makes “licence no longer gives us a visible feature” an incomplete cancellation test. Check the vendor’s actual update and licence terms first. See the WordPress documentation on plugin and theme updates.

Step 3: classify the subscription before touching it

Step 4: check the dangerous cancellations first

Some recurring items deserve a higher evidence threshold before removal because failure can take the site, email or recovery path with them.

• Domain registration: do not treat the renewal as an optional website add-on. ICANN notes that continued use of the domain and associated services depends on renewing it before expiry. Review registrar ownership and renewal rather than trying to eliminate the charge. See ICANN’s domain-renewal guidance.
• DNS: identify the authoritative provider and export or document records before a migration. Website, email and verification records may all be present.
• HTTPS/TLS: the site needs HTTPS, but a separate paid certificate is not automatically necessary. Let’s Encrypt is a free, automated certificate authority, and many hosts bundle automated certificates. Confirm your host and certificate requirements before paying twice or cancelling the only renewal path. See Let’s Encrypt’s service description.
• Backups: “the host already has backups” is not enough evidence by itself. The NCSC advises organisations using cloud services to ensure essential data is backed up and recoverable, and cautions against relying solely on the provider’s own versioning or recovery mechanisms for critical data. Review NCSC backup guidance before removing an independent backup service.
• Forms and email delivery: identify every production form, notification and automated message that depends on the service. A site can appear visually healthy while leads silently stop arriving.
• CMS licences: check update rights, security maintenance and vendor-hosted functionality. The impact of expiry is product-specific.

Step 5: prove overlap instead of assuming it

Two products with similar labels are not necessarily equivalent. “Backup” could mean a host snapshot stored in the same provider account, an independent off-site copy, or a database export. “Security” could mean malware scanning, a web application firewall, login protection or update management. “Caching” could happen in WordPress, at the web server, or at a CDN.

For each suspected duplicate, compare the exact capability, storage location, retention, limits, support and recovery path. If the replacement cannot reproduce the function you rely on, the services are not true duplicates yet.

Step 6: change one dependency at a time

For production infrastructure, reversibility matters. Before cancelling a service:

1. export any data, configuration or DNS records you may need;
2. record the current setup and account owner;
3. configure the replacement first, if there is one;
4. test on staging where practical;
5. make one material change at a time so failures can be traced;
6. verify the website, forms, HTTPS, email notifications and monitoring that could be affected;
7. cancel the old service only after the replacement is working;
8. check the next statement to confirm billing actually stopped.

When duplicate spending is deliberate

A cost audit should remove unexplained duplication, not resilience.

Backups are the clearest example. The NCSC recommends keeping an independent copy of critical data rather than relying solely on a cloud provider’s built-in recovery mechanisms. That means “host backup + independent backup” can be a sensible design when the two copies fail independently and restore has been tested.

The same principle can apply to monitoring or DNS for organisations with stricter availability requirements, although the complexity may not be justified for a small brochure site. The decision should follow the business impact of failure, not a blanket rule that every duplicated line item is waste.

Worked example: a backup subscription that looks redundant

Imagine a service business discovers that its managed host includes daily backups while it also pays separately for an off-site backup tool.

A weak audit says: “The host already backs up the site, so cancel the second tool.” A stronger audit asks:

• Are the host backups stored in the same provider account as production?
• How long are they retained?
• Can the business restore them without opening a support ticket?
• Does the independent backup include both files and the database?
• Has either restore path actually been tested?
• Would cancelling the external service leave only one administrative account between the business and all recoverable copies?

If the independent service provides a tested, separately controlled recovery path, the apparent duplication may be justified. If it simply creates another copy in the same environment with no additional recovery value, consolidation may make sense. The saving comes from understanding the failure modes, not from counting products.

Where to look for genuine savings first

The lowest-risk savings are usually the charges with the clearest evidence that nothing depends on them. Examples include:

• licences for plugins or services that are no longer installed or connected;
• old staging environments or monitoring projects for retired sites;
• extra seats assigned to former staff or suppliers;
• plans that were upgraded for a temporary traffic or storage need that no longer exists;
• paid add-ons now included in the current hosting plan;
• two tools performing the same production function where one has already been tested as the replacement.

More sensitive items—domain, DNS, hosting, backups, security controls, form delivery and email—should be reviewed for ownership, dependency and recovery before price alone drives the decision.

Prevent the stack from becoming hidden again

A short recurring ownership review is more useful than a once-a-year panic over card statements. For each production website, keep a current register of the domain, DNS provider, host, backup locations, certificate renewal path, major CMS licences, form/email services, monitoring, account owners and next renewal dates.

Then review the register when a supplier changes, an employee leaves, a site is migrated, a major plugin is replaced or a new infrastructure service is added. The aim is simple: every recurring charge should have an owner, a purpose, a renewal decision and a known failure path.

That gives service website owners a defensible answer to the real cost question. You are not trying to make the subscription count as small as possible. You are making sure each recurring cost buys a capability the website still needs—or is removed safely when it does not.