Ask for actions, not a vague request for full access
An access request should name the work to be performed. Ask whether the agency will read performance reports, investigate individual URLs, submit a sitemap or administer other users. Put each action on its own row with the business reason and the person responsible. 'We need everything for SEO' is not a useful specification.
Add the exact property identifier, intended recipient account and review date. Have the company owner confirm the recipient through an established contact route. This record is a practical way to prevent an invitation for one client or website from being reused accidentally for another.
Compare the requested work with the current role table
Google distinguishes Owner, Full user and Restricted user roles. Owners can manage users; Full users can view data and perform some actions; Restricted users mainly have viewing access. The official permissions table lists feature-level differences, including sitemap submission. Consult that table for the actions in your request rather than relying on the role name alone.
Select the least access that supports the approved work. If an action is not covered by the chosen role, decide whether the company owner should perform that action or whether the agency's documented scope should change. Do not grant ownership simply to avoid discussing which operations the agency will actually perform.
Verify the invitation without sharing credentials
The owner should make the authorized change through Search Console's user-management screen. Check the selected property, recipient spelling and intended role before saving. The agency should use its own account; a shared company password makes it harder to distinguish who performed a change and to end access later.
Afterward, ask the recipient to confirm that the correct property and required reports are available. Test a harmless reading task first. Record the granted role, date and person who approved it. Avoid using a destructive or public-facing operation merely to prove that a button is enabled.
Example: report preparation versus operational work
Illustrative scenario: a consultant is hired to prepare a monthly performance review, while the company's webmaster remains responsible for site changes and submissions. The owner documents the required reports and evaluates a viewing role against Google's current table. A request to administer users is outside this assignment.
Later, the company asks the same consultant to handle sitemap submissions. That is a change in responsibilities, so the owner reviews the additional action before changing the role. The example illustrates a decision process; it does not imply that every agency needs the same permissions or that a broader role improves search performance.
Make the end of access part of the start
Agree who will review access when the assignment ends or the agency contact changes. Keep the access register with the project handover, separate from passwords or authentication tokens. Confirm that a company-controlled owner remains available so routine staff changes do not leave the business dependent on a departing supplier.
Google notes that removing a verified owner does not itself remove the verification tokens that could allow ownership to be regained. If ownership was involved, have the responsible administrator review the official removal guidance and dependencies before removing tokens. Close the handover only after the relevant access has been reviewed and the outcome recorded.