Bricks website recovery from archive evidence should start with a data-dependency check, not just a screenshot comparison. A saved page may show a property listing, a post grid or a service detail, but that visible result does not establish which WordPress records, custom fields and query settings produced it.
Separate three questions: what content survives, whether original Bricks templates are available, and what the rebuilt website must update automatically. The answers determine whether an original configuration can be restored or a new editable implementation needs to be built.
Check original templates and database sources independently
Look for authorized hosting backups, database backups, Bricks template exports and copies held by the previous developer. Retain untouched originals and record their dates. Do not assume that a template export is a complete database backup.
The Bricks Template Library documentation describes individual JSON template exports and ZIP exports containing multiple templates. It also identifies related styles and other design data that may need review during import. These are useful recovery sources, but they must be inspected in the context of the actual project and installed versions.
Review recovered files in an isolated working copy before changing a live website. Establish the Bricks version, active extensions and any custom-field plugin involved. An export that opens successfully may still depend on records or settings that are absent.
Distinguish visible content from a dynamic field binding
Consider a captured listing showing a location, price and image. The archive may preserve those displayed values. It does not, by that observation alone, prove their original field names, field types, record relationships or source identifiers.
Bricks documents dynamic data drawn from WordPress information and custom fields. That means rebuilding a dynamic listing involves both the visible layout and the data it reads. Pasting the captured location into a text element could reproduce one page while failing the requirement that the owner can update it centrally.
If no original data model survives, decide a new one deliberately. List the approved fields, who maintains them, which pages use them and how missing values should behave. Label that as a new reconstruction decision rather than recovered historical configuration.
Use a dependency register for each repeated section
The following is a blank project worksheet, not a tested customer recovery or a claim that every source will be available.
- Displayed content: Record the captured URL, date and visible value. Confirm the text and image match the selected source.
- Storage: Identify a recovered database field, original export evidence or approved new field. Verify that an owner edit updates its intended display.
- Record selection: Document recovered query settings or approved selection rules. Check included and excluded records.
- Template scope: Record original condition evidence or the approved page scope. Check both intended pages and an unrelated page.
- Missing dependencies: List absent assets, fields, extensions and external sources. Disclose each gap and obtain approval for a replacement.
Record uncertainty explicitly. A collection of three visible cards proves that those cards appeared in that capture. It does not prove there were only three records, that the order was permanent or that unpublished records never existed.
Rebuild query behaviour, not only the first captured result
The Bricks Query Loop documentation explains that content can be queried and rendered through a repeated design, with dynamic data taken from each result. During restoration, check the selection rule as well as the card’s appearance.
For an approved post listing, confirm the intended post type, category restrictions, order and number of items. For a directory, confirm which records are public and which fields are required. Avoid guessing private or missing values merely to fill empty cards.
Use clearly labelled temporary test records in staging when necessary. Test an included record, an excluded record, a missing optional field and a collection large enough to exercise pagination if pagination is in scope. Remove the temporary records before handover. These are recommended tests, not claims that this article demonstrates an executed Bricks rebuild.
Also verify the destination of each result. A grid that looks right but points every card to the same page has not restored useful navigation.
Check template conditions across real page contexts
Bricks template conditions determine where templates apply on the frontend, with include and exclude scopes. During reconstruction, document those intended scopes rather than assuming that a preview demonstrates correct assignment everywhere.
Review an actual single item, a relevant archive or listing, a normal page and any intentional exception. Compare their header, main content and footer with the approved design evidence. Confirm that a shared template does not accidentally replace a special page.
Preserve existing public URLs during the rebuild wherever they are part of the approved restoration scope. Changing the internal data model is not a reason to silently rename public pages.
Agree on an editable handover
The owner should be able to demonstrate the tasks the project promises: edit a value, replace an image, add an appropriate record and preview where it appears. Not every page needs every field to be dynamic. The useful standard is whether the agreed maintenance work can be done reliably.
Keep integration testing separate. A captured filter, form or checkout interface is not evidence that its original processing logic, private records or delivery settings are recoverable. Any required function must be configured with authorized current sources and tested for its actual result.
A good handover identifies the recovered original sources, recreated templates, newly designed data fields and unresolved dependencies. This makes a Bricks archive rebuild understandable without overstating what the archive supplied. The broader WordPress conversion guide covers the content and URL checks that still apply regardless of builder.
If an archive-led rebuild is required, agree the actual editing and integration scope before work starts. The WordPress restoration service explains the limited-customization HTML-based option; a native Bricks implementation needs its own confirmed project scope and should not be inferred from that package.
Bricks recovery questions
Will importing a template restore all of my old listings?
Do not assume that it will. Inspect the export and available database sources separately, then verify the records and field values that the template needs.
Can archived values become new custom fields?
They can inform an approved reconstruction where the source and usage rights support it. New field definitions should be documented as new decisions, not presented as the recovered original database.
Is a matching screenshot enough to approve recovery?
No. Check the intended page contexts, data updates, query results, link destinations and owner tasks as well as appearance.
