Create a site identity before importing evidence
A client name is not a reliable identifier for a website. One business can operate a shop, a support subdomain and an older domain, while two unrelated businesses may have similar names. Before importing an audit or search export, assign a stable client ID and a separate site ID. Keep display names editable without changing those identifiers.
Create a site register with client ID, site ID, public origin, reporting scope, exact Search Console property, responsible reviewer and evidence-folder location. Record redirects or former domains as explicit relationships. Do not silently replace the old identity when a client launches a new address: historical evidence must remain attributable to the site actually measured.
Describe the measurement boundary
Google distinguishes Domain properties, which include subdomains and protocols, from URL-prefix properties, which match a specified prefix. A property therefore does not necessarily equal the website section in a client assignment. Store the selected property and any page filter beside each export so another reviewer can reconstruct its coverage.
Treat the reporting scope as part of the record, not a note remembered by the account manager. For example, a shop-only assignment needs an explicit shop boundary even if the analyst has access to a broader property. Never combine broad-property totals and subsection totals as though they described separate, non-overlapping audiences.
Validate imports before attaching them to a task
Use an import checklist: match the client and site IDs, inspect the property identifier, confirm the date range and filters, then open a few representative page URLs. Compare their hosts and paths with the register. A familiar filename or client logo is not sufficient evidence that the file belongs to this reporting scope.
Keep uncertain imports in a review folder rather than linking them to active recommendations. Retain the original file and add a short manifest describing the mismatch and the person who will resolve it. When importing from a spreadsheet, require the reviewer to select a site explicitly; do not infer it from the last project opened.
Worked example: two files called monthly-report
Illustrative example: an agency serves Cedar Retail and Cedar Consulting. Both send a file named monthly-report.csv. The agency register assigns CR-01 to the retail shop and CC-01 to the consultancy. The first file contains shop.example.com product URLs; the second contains example.org service pages. These domains are placeholders, not customer results.
The reviewer discovers that a consultancy task references the retail export. They remove that evidence association, retain a correction note and review any recommendation derived from the wrong file. They do not merely rename the attachment: calculations and conclusions may also be affected. The corrected task points to the verified consultancy manifest and names its reporting period.
Close the loop when sharing or archiving
Before a report leaves the team, verify its recipient, site label, sample URLs and evidence links together. Check that shared folders do not expose another client’s records. A correctly labelled document can still contain a copied link to the wrong workspace. Review that link as the intended recipient where your sharing system supports it.
Archive completed periods under their original site identities and record who approved any later correction. This workflow improves traceability; it does not prove that a metric is accurate or that Google has indexed a page. When using SEO Growth Assistant for the next audit, confirm the selected website first and retain the evidence boundary with your review notes.