Write the reporting question first
Before adding a property, decide whose question the report must answer. A business owner may want the whole website, while a content team may need only its language directory. Write that question next to a small inventory of representative URLs. Include the homepage, an article, a service page and any separate hostname that matters to the task.
For each address, record whether it belongs in the intended report. This simple included/excluded column is your acceptance test. It helps distinguish an incorrectly chosen reporting boundary from a genuine lack of search activity, without making changes to the website just to investigate an empty dashboard.
Match the property to that boundary
Google's Domain property covers subdomains and protocols within its domain scope. A URL-prefix property covers addresses beginning with its specified prefix, including the protocol and any path. Domain verification normally uses DNS; URL-prefix properties offer several verification methods. Consult the official setup instructions for the method available to your site.
Choose a broad property when the reporting question requires that broad scope. Choose a narrower prefix when a specific section is the intended unit of work. These choices describe how you organize evidence; creating a property is not a website optimization or a promise of more visibility.
Keep ownership and setup responsibilities explicit
Record the account responsible for maintaining access and the person who can complete the required verification. If another owner already manages the property, coordinate with that owner instead of creating a parallel setup merely because you cannot see it. Do not ask a client to send passwords in a document or a message.
Before editing DNS or a website verification file, give the responsible administrator the exact official instructions for the selected property. Keep a record of the intended change and its verification result. This guide concerns choosing the reporting scope; deciding which agency role to grant is a separate access-management task.
Example: a company site with an English resource section
Illustrative scenario: an owner reviews company-wide search performance while an editor manages an English resource section. Their inventory includes https://example.com/en/resources/guide/, https://example.com/ar/resources/guide/ and https://support.example.com/help/. They label the first as part of the editor's work and the others as outside that particular assignment.
The owner can maintain a broad view while the editor uses a deliberately narrower reporting boundary for the resource section. Save the exact chosen property alongside each export. Do not add the narrow report to the broad report as if they represented separate audiences: the scope inventory shows that they overlap. This is a planning example, not measured traffic data.
Validate the selection before interpreting the numbers
Open the chosen property and compare its displayed identity with the inventory. Check representative included and excluded addresses against the documented scope. If the intended section is missing, correct the selection before diagnosing content, rankings or indexing. Keep the date range and report filters in the same handover record.
When two people share different totals, compare their property identifiers first, then their filters and dates. Preserve the original exports while investigating the difference. End the setup task with a brief statement of what the property covers, who maintains access and where its reports will be used; leave performance conclusions to a separate analysis.