Choose the smallest necessary change#
| Goal | Appropriate change |
|---|---|
| Change identity or theme | Save Appearance and reload. |
| Publish a new layout | Place the existing valid tag in that layout. |
| Pause the launcher | Remove or disable its frontend loader and purge cached HTML. |
| Invalidate manual code | Generate replacement code and update every copy. |
| End a platform connection | Use its supported disconnect or uninstall flow. |
| Remove the website | Confirm removal in website Settings. |
Choose the smallest change that meets the business goal. A missing theme script does not require deleting Knowledge, and a visual adjustment does not require token rotation. Website removal is broader than hiding the launcher.
Replace a manual snippet#
Prepare every layout, script-manager location and HTML cache that can serve the installation. Open Installation and use the replacement-code control only when ready to publish. Copy the complete newly generated tag, remove old copies and install it once per intended document.
Purge relevant page and CDN caches, then visit the registered public domain. Historical Widget detected can survive manual replacement, so confirm a fresh Last seen time and a representative answer. Check a second route and a phone. Restoring an older file must still use the current credential; revoked code is not a valid rollback.
Pause or disconnect WordPress#
Disable widget stops the plugin adding the script to new public renders while keeping its connection. Plugin deactivation also stops rendering and keeps settings for later reactivation. Purge cached HTML and check a fresh visitor page; an already open document can still contain a loaded widget.
Disconnect Reesponder revokes the remote plugin credential and clears local settings after a successful request. Disconnect before deleting the plugin. Uninstall attempts remote revocation, but network failure can prevent completion. This platform change does not itself remove the website record or its retained service history.
Theme and app changes on Shopify#
A manual tag belongs in the published theme's shared layout. Copy the existing current tag into a replacement theme before publishing and check any separate custom layouts. Remove the tag from those locations when intentionally stopping support. Theme delivery does not cover Shopify checkout or the new customer-account system.
If an existing app connection owns the widget, manage its embed or uninstall through Shopify as appropriate before switching to manual setup. Do not install a second tag beside it. Storefront support and private order access are separate integrations; audit their intended effects independently.
Remove the website from Reesponder#
Open the website's Settings, review Remove website and type its exact displayed hostname to confirm. Removal disables the website, revokes installation, context and private-test credentials and removes site-specific Knowledge. Shared workspace Knowledge remains.
Conversations follow their retention settings; recorded usage and billing remain. Adding the domain later creates a fresh website identity and installation rather than restoring old credentials. Also remove the obsolete loader or platform integration from your public site so it stops making unnecessary requests. Removal is not a refund or a universal deletion of external business records.
Worked example: a redesign that changes the shared layout#
Your developer publishes a new theme that replaces the footer containing the manual snippet. The website record and Knowledge still exist, but new pages no longer load the widget. The repair is to add the current existing snippet to the new shared layout and verify the public pages. A new token is not required merely because a template changed.
Now suppose the old installation code has been lost and you intentionally generate a replacement. The old credential becomes invalid. Update every active template and purge HTML caches before considering the replacement complete. Restoring yesterday’s theme with yesterday’s stale token is not a valid rollback. Preserve the new current snippet and use it in the restored template if you need to reverse the redesign.
Confirm both the intended change and its side effects#
After a replacement, verify the current snippet on the public domain, a fresh Last seen time, a representative customer question and a second important route. After a pause, visit in a clean browser context and confirm that cached HTML does not continue to add the widget. After a disconnect, check the connection state rather than judging only whether an old browser still displays the launcher.
After removing a website in Reesponder, confirm that it is absent from the active website list and that the public template or plugin has also stopped rendering its obsolete code. Keep recorded usage and billing in mind: removal is not a refund, usage reset or a universal deletion of independent business records. Avoid testing a revoked installation by repeatedly generating new websites; add the domain again only when you intend to create a fresh supported installation.
Move between installation methods deliberately#
Before switching from a manual snippet to the WordPress plugin, locate and remove the old manual tag from the active theme or script manager. Connect the plugin through its supported approval flow, enable it and clear page caches. The plugin owns its new credential. Leaving the old manual tag in place can make the first loader encountered by the browser the wrong one; the single-widget guard does not determine which credential you intended.
When moving away from a platform-owned installation, disconnect or uninstall through that platform’s supported flow before generating manual replacement code. An active WordPress or Shopify connection prevents normal manual issuance. Do not work around the ownership check by changing a site ID in HTML. Verify the new owner, the generated current tag and a fresh detection on the registered public host.
Document the final method in your handover notes: which layout or plugin inserts the code, who controls it and which cache needs purging. This avoids rediscovering hidden duplicate installations at the next redesign. Keep a public test route and a known safe question ready for the post-migration check.
What stopping the widget does not erase#
Removing a tag from HTML prevents future pages from loading it after caches and already open pages are accounted for. It does not request deletion of all prior conversations. Disconnecting a plugin revokes that integration credential but retains the website and its service history. Removing the website inside Reesponder is a broader service operation, yet recorded billing, usage and retained history follow their applicable rules.
If the purpose is a data-erasure request rather than a deployment change, identify the records involved and use the appropriate privacy process. Delivered handoff emails, business exports and records created in an external Action destination have their own ownership and retention boundaries. A frontend uninstall cannot guarantee erasure from those systems.
For an urgent support pause, use the smallest reversible change that stops the intended entry point and verify a fresh visitor page. For permanent service removal, coordinate the public code removal and website removal. Keep enough operational evidence to explain which action was taken without storing raw credentials in the ticket.
Need help with this?
Tell us which website, guide and step you are working on. Keep passwords and private customer details out of the message.