A deleted Divi website can sometimes be rebuilt from Wayback Machine evidence, but the recovered page appearance and the original Divi editing setup are different things. Before rebuilding, identify which layouts survive, which pages share them, and whether any genuine Divi exports or WordPress backups remain. That determines whether the work is an import, a reconstruction, or a combination of both.
The important decision is not simply whether the new website will use Divi. It is whether its pages, reusable sections and template assignments will behave as the owner expects after the archived design has been recreated.
Separate a page layout from the website’s shared templates
A service page may contain its own introduction, benefits and enquiry section while sharing a header and footer with other pages. A blog post may use a different body template. Treating every captured page as an independent design can make those repeated areas harder to maintain.
Elegant Themes describes the Divi 5 Theme Builder as a way to assign header, body and footer layouts to groups of content. More specific assignments can override general ones. Those assignment rules matter during recovery: a correctly recreated header in the wrong scope can still produce an incorrect website.
Record the installed or intended Divi version before following any instructions. A current Divi 5 interface is not evidence that a deleted website used that version. Existing exports, integrations and editing requirements need a compatibility review on an isolated working copy.
Inventory original sources before recreating modules
Ask the owner or previous developer for Divi Library exports, individual layout exports, Theme Builder exports, hosting backups and authorized working copies. Name each item by its actual scope rather than calling everything a complete website backup.
The Divi portability documentation explains JSON exports for layouts and Library items. It also warns that importing an individual layout replaces the current page content. A file intended for one page should therefore not be imported into a valuable live page simply to see what happens.
Keep original files unchanged. Review copies in staging, with a rollback available. Check whether images, fonts, custom styles and extension-dependent sections actually work after import. Possessing an export is a useful starting point, not proof that the whole website or every dependency has survived.
When no usable export exists, archived pages become references for a new implementation. Recreate the visible content in appropriate editable modules, but do not describe that process as recovery of the original builder records.
Build a page-family and template-assignment register
Use this blank planning register to distinguish the parts of the website that should remain consistent from the exceptions. It is a worksheet for a restoration project, not a record of a completed customer recovery.
| Record | What to enter | What to verify |
|---|---|---|
| Page family | Service page, ordinary page, post or another actual content type | Which recovered URLs belong to this family |
| Shared frame | Header, footer and repeated sections supported by captures | Whether the same design appears across the selected pages |
| Exceptions | Pages with a visibly different frame or body | Whether the difference is intentional or an incomplete capture |
| Implementation scope | Reusable layout, shared template or individual page | Where a change should and should not appear |
| Owner task | A real recurring edit, such as changing service text | Whether the owner can complete it without damaging shared areas |
Review at least one representative URL from each actual family and each exception. Do not assume that a header working on the homepage is also correct on a post, category page or special landing page.
If the archive only shows a desktop layout, mark mobile behaviour as a new design decision requiring review. A recreated responsive layout can be useful without pretending that the missing historical mobile version was recovered exactly.
Preserve content and URLs while rebuilding the editing structure
Keep the historical page address, page purpose, useful copy and relevant internal destinations in the restoration inventory. The choice of a new Divi module should not silently change a service page’s URL or turn its content into an unrelated sales page.
Check editable text separately from decorative imagery. A headline embedded in a recovered picture does not become editable text merely because the picture is inserted into a builder. Where it is appropriate to recreate that headline as text, verify the wording against the source and obtain approval for any change.
Also separate appearance from business functions. A pictured contact form does not prove that mail delivery has been restored. A booking button needs a real current destination. Reconnect approved integrations and test their actual results separately from the visual rebuild.
What a documented Divi restoration demonstrates
Wayback Restore’s published plumbing and septic website restoration describes rebuilding recoverable service pages from partial archive evidence into WordPress with native Divi modules. The recorded work includes mapping service URLs and navigation, reviewing available copy and media, and checking key enquiry paths across desktop, tablet and mobile.
This is evidence of a particular archive-led reconstruction. It is not evidence that the original Divi exports or private database were recovered. Nor does it establish that every missing asset, integration or historical page can be recovered for another website. Its useful lesson is that source gaps, editable reconstruction and continuity checks can be handled as separate parts of the project.
Approve the rebuilt website through practical tests
Compare selected pages with their cited captures, then check the live working copy without administrator privileges. Review header and footer assignments, navigation destinations, image loading, text wrapping and small-screen controls. Test an exception page as carefully as a standard one.
Ask the owner to perform the editing tasks named in the register: change a paragraph, replace a picture, update a shared contact detail and preview the result. Confirm that a shared change affects its intended pages and does not overwrite an unrelated layout.
The handover should distinguish imported original material, recreated sections, approved replacements and unresolved dependencies. That distinction makes the result maintainable and keeps recovery claims honest. For the wider content and URL process, see the archive-to-WordPress conversion guide.
Questions about rebuilding a Divi website
Can a Wayback capture be imported as an original Divi layout?
Do not assume so. A public capture can help recreate the visible page. An original Divi layout export is a different source that must be found and checked independently.
Should every recovered page have its own header and footer?
Not necessarily. Identify genuine shared areas and exceptions first. The implementation should support the approved maintenance tasks rather than duplicating repeated sections unnecessarily.
Does using Divi restore the original forms and integrations?
No. Their settings, destinations and delivery results need their own evidence and testing. A matching form design is only the visual portion of that work.
