This article documents the WordPress site maintenance work performed on the BlueSky website, including HubSpot plugin deactivation, cache management, plugin updates, and standing concerns about ongoing site maintenance ownership. These issues surfaced during a routine client ops review and reflect patterns common across client WordPress sites.
When a client stops using HubSpot, the WordPress HubSpot plugin must be explicitly deactivated — it does not self-disable when the associated account lapses or is abandoned.
Symptoms of a lingering HubSpot plugin:
- A HubSpot chatbot widget continues to appear on the site frontend
- Form submissions may still attempt to route to the old HubSpot account
- The plugin consumes resources and may generate errors silently
Resolution steps:
1. Log into WordPress admin → Plugins
2. Locate the HubSpot plugin and click Deactivate (or Delete if the integration is permanently discontinued)
3. Flush the site cache immediately after deactivation — the chatbot widget may persist in cached pages until the cache is cleared
4. Verify removal by loading the site in an incognito/private browser window to bypass local browser cache
In the BlueSky case, the chatbot disappeared immediately after cache flush, confirmed via incognito window. See [1].
Any plugin deactivation or significant configuration change should be followed by a full cache flush. Cached pages will continue to serve old assets (including injected scripts from deactivated plugins) until the cache is cleared.
When a site transitions away from HubSpot, confirm that Gravity Forms submissions are no longer routing to the old HubSpot account and are instead going to the correct email recipients.
Verification checklist:
- Open each active form in Gravity Forms → Settings → Notifications
- Confirm the "To" address matches the current, intended recipient
- Confirm any BCC addresses are correct (useful for account managers to monitor submissions)
- Send a test submission and verify receipt
On BlueSky, the "SPEND data" form was confirmed routing to the correct address (
DC at...). Melissa was receiving BCCs of submissions, confirming the fix was in place. The homepage general form routes toJim.Cross. Some buttons on the site were found to link to nowhere or to deprecated form anchors — these require a full site review.
WordPress sites that are not actively maintained accumulate outdated plugins, themes, and core versions. This creates security risk and can cause compatibility issues.
Best practice:
- Run all available plugin, theme, and core updates during any maintenance visit
- Note which updates were applied and flag any that require manual review (e.g., major version jumps)
- Assign a specific person or role responsible for routine update cycles
During the BlueSky maintenance session, Mark ran all available updates. The site had been unmaintained for an extended period. Lead Forensics integration status was also flagged as unknown and should be confirmed with the client.
A recurring issue across client sites is the absence of a designated owner for routine WordPress maintenance. Without clear ownership:
Recommendation: Assign one person (internal or client-side) as the responsible party for each WordPress site. Their responsibilities should include:
- Monthly plugin/core updates
- Quarterly form routing verification
- Periodic link and CTA audits
- Backup verification
Mark noted during the BlueSky session: "It's almost like it should be one person's job to take care of the sites we've got — to go in and make sure that everything's configured and working properly and that there's no errors and no problems and everything's backed up and everything's updated."