A good launch does not guarantee a healthy website

I have built 42 custom HubSpot themes. Nearly two-thirds of those websites developed SEO or performance issues over time. That is an uncomfortable thing to write when you built them.

This is an observation from my own projects, not an industry-wide failure rate. But it raises a question worth asking before any website is signed off: who will look after it once the launch work is finished?

When I revisit projects months later, I sometimes find much lower PageSpeed scores. I also see new copy that pushes harder to sell, but does less to answer the questions customers actually have.

A website can be delivered in good shape and still develop problems later. New pages go live, content changes and marketing tools get added. Each change may be reasonable on its own. The combined impact still needs to be checked.

Performance changes as the website changes

A custom theme defines the starting architecture, but it is not the only influence on the experience. Editors add images and sections. Campaigns introduce landing pages. Marketing teams add tracking, chat, embeds and other external tools.

Over time, a page may download more files, execute more JavaScript or shift its layout while loading. The original theme can remain unchanged while the real page becomes slower or less responsive.

That is why checks should use representative live pages with their actual content and consent-dependent tools enabled where appropriate, not only a clean demonstration template. Compare the homepage, key service pages, landing pages and a typical article. A shared module change can affect several templates at once.

Use real-visit metrics alongside lab tests

Google's good Core Web Vitals thresholds are Largest Contentful Paint (LCP) of 2.5 seconds or less, Interaction to Next Paint (INP) of 200 milliseconds or less and Cumulative Layout Shift (CLS) of 0.1 or less. They are assessed at the 75th percentile, with mobile and desktop considered separately.

These are real-user experience thresholds, not a target for the overall PageSpeed performance score. PageSpeed Insights can show both field data from real visits, when available, and a Lighthouse lab test. The lab test helps investigate a page under controlled conditions; field data shows what visitors experienced. A single lab run cannot establish real-user INP.

Record a baseline and compare results under similar conditions. If field data is unavailable, use lab results as diagnostic evidence and be explicit about the limitation. A lower score is a reason to investigate, not proof that search rankings or enquiries have fallen.

The reverse is also true: good Core Web Vitals do not guarantee rankings. Google describes page experience as one consideration among many, with relevant, helpful content still central (Google Search Central on page experience).

Reference: Google's Core Web Vitals guidance. For the theme-level causes, see why HubSpot theme performance matters.

What HubSpot manages, and what it does not

HubSpot's CMS includes managed hosting infrastructure, a CDN and SSL certificates, so teams do not maintain servers or renew certificates themselves (HubSpot web hosting).

That covers the platform, not what is built and published on it. The website team still owns:

  • Custom modules and templates, including how they load assets.
  • Content, images and embeds added after launch.
  • Third-party scripts such as tracking, chat and consent tools.
  • Lead capture journeys: forms, CRM properties, workflows and follow-up.

Managed hosting removes one category of work. It does not remove the need to check what changes on the pages themselves.

Review content for usefulness, not only sales messaging

Performance is only one part of website care. A fast page can still be less helpful than the version it replaced.

As copy is revised, practical explanations can disappear behind stronger claims and repeated calls to action. The page may sound more persuasive while giving customers less information to make a decision.

Content review should ask whether the page still answers the visitor's actual question. What does the service involve? Who is it suitable for? What are the limitations? What happens next? Where the answer depends on context, explain that context rather than replacing it with a broad promise.

  • Check that the main answer is easy to find and still accurate.
  • Keep useful detail about scope, process and trade-offs.
  • Remove unsupported claims and outdated information.
  • Check headings, internal links and the next step after an edit.
  • Review new images and embeds for loading impact and accessibility.

This does not mean avoiding commercial messaging. It means making the commercial next step follow a useful answer. More copy, more keywords or a more forceful headline do not automatically make a better page.

Agree three responsibilities before sign-off

I explain how to look after the website when handing projects over. But a few weeks later, people have other priorities. Without ongoing checks, those recommendations are easy to forget.

As a developer, I also have to recognise that explaining something at handover does not mean there is a process in place to maintain it. Documentation helps, but it does not assign time, authority or budget.

1. Someone owns ongoing performance checks

Name a person or team responsible for reviewing the website. Agree which pages to monitor, which signals matter and where changes are recorded. The owner does not need to implement every fix, but should know when to involve a developer.

2. New content is reviewed for usefulness

Make content quality part of the publishing process. Someone should check whether an update answers customer questions, preserves important detail and avoids unsupported claims. Technical checks should accompany changes to images, modules and embeds.

3. There is a clear process for investigating and fixing issues

Agree how an issue is reported, who investigates it and who approves the work. A performance alert is not useful if nobody can act on it. Equally, a content problem should not wait indefinitely because it does not require a redesign.

Make maintenance part of the plan and the budget

The cadence below is a starting point, not a universal requirement. A site that publishes weekly or runs frequent campaigns may need closer checks; a stable brochure site may need fewer.

Pages using a new or changed module, template or script: performance, layout and forms
When: After significant updates
Owner: Developer, with the website owner
Representative pages (homepage, key service pages, landing pages, a typical article): lab tests and field data where available
When: Monthly
Owner: Website owner
Search Console: Core Web Vitals, indexing and unexpected drops in impressions
When: Monthly
Owner: Website or SEO owner
Key forms: test submissions arrive in the CRM with the right properties, owner and follow-up
When: Monthly
Owner: Marketing operations
Content on priority pages: still accurate, useful and free of unsupported claims
When: Quarterly
Owner: Content owner
Third-party scripts and embeds: still needed, consent-aware and not duplicated
When: Quarterly
Owner: Marketing with a developer

When a check finds a meaningful regression, investigate it rather than reacting to every score fluctuation, prioritise by visitor and business impact, and keep a short record of what was changed. Monitoring without time and budget to fix issues leaves the same problems in place.

Meeting good Core Web Vitals thresholds at launch does not mean the website will still meet them six months later. The handover should be the beginning of that process, not the end of responsibility.

FROM HANDOVER TO ONGOING CARE

Agree how the website will be maintained.

01

BASELINE

Record representative pages, content priorities and performance at handover.

02

OWNERSHIP

Name the people responsible for monitoring, content review and fixes.

03

REVIEW

Check the impact of new content, modules and marketing tools.

04

IMPROVE

Investigate changes, prioritise fixes and verify the result.

The responsibility can sit with your internal team or an external partner. What matters is that it exists beyond the launch checklist.