Recover a Squarespace website by identifying whether you lost a page, a blog post, part of a page, account access or the entire active site. Native restoration options differ by content type. Check those options promptly before relying on a public archive, and do not assume that a site export preserves the complete design or every commerce record.
A recovered public page and a functioning original Squarespace system are different results. Keep account access, subscription status, content recovery and new reconstruction separate in the decision.
A missing domain is not proof that content was deleted
Use the owner’s authorized account to inspect the correct site. Record the built-in address, custom domain, last working date and visible account/site status. If you cannot access the account, use the provider’s official recovery process rather than assuming an archive rebuild is required.
Squarespace’s reactivation guidance distinguishes subscription reactivation from domain issues. If the built-in address works but the custom domain does not, investigate the domain separately. Do not promise that renewing one subscription automatically resolves every access or domain problem.
Pages and blog posts have a limited native restoration route
The current deleted-content documentation describes restoring pages and blog posts deleted within the last 30 days. It distinguishes the interfaces for versions 7.0 and 7.1. A restored page appears in Not linked; restored blog posts return as drafts.
Review the recovered item before changing navigation or publication. Check its URL, content, media and current accuracy. Native restoration does not automatically approve an old promotion or contact detail for today’s site.
The same document says most other collection items and individually deleted blocks/sections after closing the editor are not recoverable through that route. Do not extend the page/post retention rule to every content type or a whole deleted member site.
Decide what the missing content actually requires
- Restorable native item
- Use the documented owner-authorized route, then verify the restored state before republishing.
- Visible material with no native restoration
- Look for authorized files, exports, readable captures and owner-held content. Record reconstruction separately from native recovery.
- Private or operational data
- Require a genuine authorized source or current configuration. Public captures cannot substitute for private submissions, accounts or payment records.
- Content with no reliable source
- Keep the gap explicit. Newly commissioned replacement content is not recovered historical content.
This classification prevents a page screenshot from being offered as a solution for missing private records and prevents unavailable fragments from being completed with guessed copy.
Inspect the export’s actual scope
Squarespace’s current export guidance describes an XML export of selected content for WordPress, not a full-site backup. It lists excluded material such as store pages, product blocks, drafts, style settings and custom CSS. Only one blog page exports through that route.
Keep the original file unchanged and inventory which required pages and fields it contains. Compare its date and scope with other surviving material. A missing export item might reflect the tool’s limits rather than evidence that the item never existed.
Verify media files independently of XML references. An image URL in an export is not proof that a durable local copy exists. Confirm the files, associations and reuse rights before discontinuing a source that still serves them.
Use archives for public reconstruction with clear limits
Match captures to individual pages and dates. Recover readable text and usable images without claiming that the original editor settings, private systems or every responsive state survive.
Collect layout references separately from content references. A screenshot can help recreate spacing and visual relationships; an export may offer cleaner text. Where those sources disagree, record the conflict and ask the owner to approve the intended result.
Choose the destination CMS only after the recovered sources and editing requirements are understood. Do not promise a universal one-click transfer into Squarespace or another platform. Preserve existing URLs where feasible and document actual constraints before approving changes.
Review the recovered page as a visitor and an editor
Check the direct URL, title, readable content, media and navigation context. For blog posts, confirm the intended publication state and supported historical dates. For reconstructed layouts, compare representative desktop and mobile views with the available evidence.
Confirm the agreed editing task, not merely that the page can be opened in a dashboard. Keep form, commerce and membership operations within a separately approved verification scope. A visually accurate form cannot prove recovery of previous submissions or delivery settings.
The website recovery review can assess an archive-led reconstruction and its appropriate destination. Platform delivery needs an explicitly agreed scope rather than an assumed fixed Squarespace package. The restoration guide explains the public-source boundaries that apply to any CMS.
Squarespace recovery questions
Does the 30-day rule cover every deleted item?
No. It applies to the documented page and blog-post restoration route. Other item types have different limits, so check the specific content before making a recovery promise.
Is the XML export a complete copy of the design?
No. It carries selected content and excludes several page types, settings and style information. Inventory what actually survives before defining a rebuild.
