How to add a user in Google Search Console
Read the conclusion first
Grant access for a named task, then test it from the recipient's account. For a handover, preserve a verified business owner and review property roles, ownership verification methods and third-party app access separately. Removing an email from one screen may not close every route back in.
Applicable conditions
Suitable for outsourcing cooperation, team handover, and third-party tool authorization. Only managers with the appropriate permissions can add or remove users.
Before you open the report
The property owner, each person’s actual task, and the verification methods still granting ownership.
Use one concrete URL or report first. Keep account credentials and private visitor data out of shared notes.
Steps and verification
Write down who needs to do what
Create an access record with the account email, exact property, task, decision owner and review date. Reporting, submitting a sitemap and managing other users do not require the same capabilities. Use Google's current permissions table to choose a suitable role; do not make every supplier an owner for convenience.
Ownership also creates responsibility for continuity. Keep a verified owner controlled by the business, and document where that owner's DNS record, file or tag is maintained. Before someone leaves, establish the replacement owner's working access instead of discovering afterward that nobody can manage the property.
Grant and test access as two separate checks
An authorized owner opens Settings → Users and permissions, adds the recipient's Google account and selects the required role. The recipient then signs in independently and opens the exact property and report needed for the task. Record both the configured role and the observed result.
If access fails, compare the signed-in email with the invitation, then check property coverage and role capabilities. Do not exchange passwords to work around the problem. A successful report view proves that particular operation; it does not establish permission to manage users or run every other tool.
Remove departed owners without deleting unrelated evidence
For an ordinary user or delegated owner, remove the applicable property access. For a verified owner, also inspect the verification methods and unused ownership tokens associated with that person. A surviving token can allow ownership to be verified again.
Identify each person's token before changing the website or DNS. The same verification evidence may support other Google services, so check its dependencies and preserve current business verification. Keep a before/after access record and the responsible administrator. An unknown owner also warrants investigation of site and account security, rather than merely hiding that entry.
Close the third-party connection and complete the handover
Property permissions determine what a Google account can access; the account's third-party authorization determines what an application may request on its behalf. Review both during offboarding. Revoke a retired tool's authorization through the relevant Google account, and use that tool's own account/data removal process where necessary.
Finish by testing the replacement owner's native access, confirming the intended former access is removed, and recording the status of retained tools. AISEO Site's present read-only connection does not make it a verified owner. Never include passwords or OAuth tokens in the handover document.
Common mistake: Assuming ownership verification fails after deleting a user
Some verification records may still exist and need to be confirmed through the native GSC ownership management process.
How to decide when you encounter different situations
Match your actual observation to a row before changing the page. If it does not match, collect the missing evidence first.
| What you see | Next step | How to confirm |
|---|---|---|
| View reports only | Grant the minimum permissions matching the task | The other party actually views successfully |
| Personnel departure | Revoke the user and related ownership verification | Review remaining valid verification records |
| Third-party tool no longer in use | Revoke in the tool and Google authorization management | Confirm it can no longer read, not relying on the delete button wording |
Remove access without confusing users and ownership tokens
Teaching scenario. Names, URLs and numbers illustrate the method; they are not customer or measured site results.
- What you observe
- Example: an agency contact leaves. Removing their listed user may not address a separate verification token they control.
- What it establishes
- Permission review must cover both the user list and ownership verification. A removed account and a remaining verification method need separate records.
- What to do next
- Have a retained owner inspect Settings and ownership details. Remove only the departing party’s access and relevant verification method; preserve the organization’s valid ownership. Revoke unused third-party authorizations separately.
What counts as a checked result
List remaining owners and verification methods. Ask a retained user to read a report; confirm the removed account no longer has the intended access. Never publish tokens as evidence.
If a required check fails, keep the error and return to the matching decision branch. A blank record means unverified, not passed.
Leave with a checked result, not another vague instruction
- Your deliverable
- A permission handover with receiver tests and retained organization-controlled ownership.
- Stop and resolve this first
- Do not remove a validation token until its owner and dependencies are identified.
Record missing evidence in the worksheet below. An unresolved test is useful information; a blank field is not a pass.
Checklist for this page
Fill in your own check results, then decide the next step. Blank means not yet verified, not normal. Content is saved only in the current local session and is not submitted to the server or AI.
Frequently asked questions
Does AISEO Site authorization equal giving the tool ownership?
No. The tool reads data you can access through the read-only scope you approve; it does not become a DNS verification owner.
Should every analyst be a verified owner?
Grant the least access that supports their task. Viewing data and managing ownership are different responsibilities; review access again when the engagement ends.
Official materials and usage boundaries
This page provides operational judgment and checking methods, and does not show customer success cases. Calculation examples and request samples are teaching materials, not actual website metrics. Google's reports, conditions, and interfaces may change; please refer to the current official documentation.
Read the corresponding Google official documentationContinue with the relevant tool
If the property is still missing in AISEO Site, follow the account-access checks in Help. Connecting an account does not grant it ownership.
See how it works →