Decide whether removal is necessary#
Use removal when a domain no longer belongs in the workspace or you need to replace a website configuration completely. It is not a refresh control. To collect updated website content, choose Crawl again; to correct a manual fact, edit its Knowledge entry.
An active owner or admin can remove a website. Confirm the selected workspace and domain first, especially when several similarly named websites exist. There is no restore button for the removed website's Knowledge or credentials.
Confirm the exact domain#
- Open Websites and select the website.
- Open its Settings tab.
- Read the Remove website explanation.
- Type the displayed canonical domain in the confirmation field.
- Select Remove website.
The confirmation must match the configured domain. The control remains disabled until the typed value matches. If a network error occurs, refresh the website list before repeating the action so you can see whether the first removal already succeeded.
What removal disables#
The website is archived and disappears from the active website list. Its widget installation is disabled, and its installation token, server context credential and private tests are revoked. Website-specific Knowledge sources and documents are removed from active use.
The WordPress and Shopify connection records for that website are removed. Pending source jobs cannot continue as if the site were still active. Shared workspace Knowledge has no website-specific ownership and remains available for the other websites in the workspace.
What remains#
The site identity is retained where needed for existing conversations and the usage or billing ledger. Conversations remain subject to their stored retention expiry; removal does not refund consumed conversations or erase usage records. A conversation might remain visible under All websites even though its domain is no longer in the active website selector.
Removal does not change the workspace subscription. If you also want to cancel or change billing, use Billing and the applicable payment-management flow separately. Copies of requests already emailed to your team remain in that mailbox.
Remove the website-side installation too#
Delete a manual snippet from the published website template. On Shopify, remove the Reesponder theme snippet; if the website used an existing Shopify app connection, also disable its embed or uninstall that app as appropriate. Reesponder removal is not permission to modify your store's theme or other apps automatically.
If you later add the same domain again, Reesponder creates a fresh website identity and new installation credentials. Reinstall using the new code or connection. Old snippets and private links cannot be reused to restore the archived website. Review the new crawl and test again before treating the reconnect as complete.
Worked example: replacing the only Core website#
A Core workspace already has its one active website, and the business plans to replace it with another public hostname. It first reviews the new public content and the migration objective with the responsible maintainer. The one-site plan does not provide a second active slot simply because the new domain is intended as a replacement.
Removing the old active website and adding the replacement are distinct operations. The replacement receives a fresh installation identity and needs new Knowledge and acceptance checks. Previously consumed conversation units are not returned by removing the old site, and its retained conversations keep their own expiry. If the business needs an overlapping migration period, review the supported plan or ask support before destroying the working configuration to create space.
Confirm retirement without losing its context#
Check the active website list after the removal transaction and verify that intended remaining sites still have their own configuration. Then visit important retired routes after frontend cleanup and cache refresh. Record the old domain, retirement date and responsible maintainer so an earlier retained conversation is not confused with a newly added identity.
Keep cancellation, workspace closure and personal-data requests separate from this website lifecycle. Use Billing if the business also intends to change its subscription, and the published privacy process for a broader request. A checked archive operation must not be described as erasing every external mail copy, refunding usage or transferring the old site's data to its replacement.
Inventory the frontend and external dependencies#
Before confirming removal, find every installation path used by the domain. A manual script may live in a shared template, a theme edit or an older page-builder insertion. WordPress can use the connected plugin. Shopify can have a theme snippet and, where actually installed, an app embed. Record which path is active and whether an obsolete second path remains. Account-side removal and frontend cleanup are complementary operations.
Review shared information before retirement. If a shared entry mentions the closing location, retired domain or an old contact address, editing that text is a separate business decision. Removing one site does not automatically rewrite shared Knowledge for the remaining stores. The same applies to the destination mailbox or an external provider endpoint: identify who continues to own those records and whether the business intends to close or repurpose them.
Decide whether the goal is a theme migration, retirement of one website or closure of the whole workspace. A normal theme migration usually needs the working integration carried into the new layout, not destruction and recreation of the website. If the problem is simply that a launcher is missing, follow diagnostics first. Website removal is a deliberately different lifecycle operation, not a universal troubleshooting reset. Ask the business owner to agree on the objective before you remove content or connections that another colleague still expects to use.
Example: replacing a regional storefront#
Suppose a business retires an old regional storefront and launches a replacement domain. Before removal, it records which delivery and returns facts were site-specific and which company information was intentionally shared. It prepares the replacement site's approved content without treating the archived website's credentials as transferable. A new website identity needs its own current integration and readiness checks.
The team removes the old frontend integration from the published theme and uses the old site's Settings confirmation. It then verifies both outcomes: the old active website is absent from the portal list and important old public routes no longer include the obsolete loader. A cached page can still contain old script markup even though account-side revocation prevents service use. This is why frontend HTML and active account state both belong in the retirement check.
The replacement is tested independently. A public policy question should use the replacement's approved sources, a private lookup should check the authorized store connection, and a handoff should reach the intended monitored destination where enabled. Existing old transcripts remain historical content subject to their stored retention; previously used capacity does not become available again. The retirement note records the two domains and the observed checks, not a claim that deleting the old portal row migrated all data to the new website.
Handle a partial result without making it worse#
If the portal reports success but the active list fails to refresh, refresh the page before repeating lifecycle operations. A failed visual refresh is different from a failed removal transaction. If the server refuses confirmation, compare the entered hostname with the site's actual canonical domain and check the acting account's management authority. Avoid creating another website with a similar name to make the error disappear.
If you removed the wrong site, do not promise a one-click undo. Re-adding the hostname creates a fresh identity and does not restore its deleted website-specific Knowledge or old credentials. Use approved source material to rebuild and repeat acceptance. The external website may still have its original script, but that retired credential is not a working rollback. Replace the frontend integration only with the current code or platform-managed connection for the new identity.
For a wider account closure or personal-data request, identify the record and appropriate process separately. Already delivered email, external operational records and purpose-limited billing evidence are outside the simple website removal action. The business should manage its own downstream copies. Keep support evidence bounded: domain, approximate time, requested objective and observed notice. Usable installation or trusted-context tokens are not needed to explain which retirement step failed.
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.