Sharing GA4 and Search Console Access Safely

Tomohiro Iida · Published August 2, 2026 · Updated August 2, 2026

When an external web improvement agency asks for GA4 and Search Console access, the decision is not simply whether to grant it. The decision is which data, under which role, and for how long. Both products separate what each role can do, and both allow access to be reduced or removed later. Handing over administrator or owner rights without designing the scope means losing the chance to narrow it, and makes removal harder to confirm. GA4 keeps a change history and Search Console lets you review ownership, but the number of paths you have to check goes up.

This article covers permission design and the safety judgement. It does not cover GA4 analysis techniques or general Search Console usage. The permission names and procedures below were confirmed on Google Help pages on 2 August 2026; screens and steps can change, so check the source pages before acting.

What you cannot judge without shared data

Public HTML and search results already reveal a great deal. What becomes unavailable is the record of where real visitors stopped.

• Which queries produced impressions, and which produced no clicks
• Which pages appeared in search results and which did not
• Which pages are indexed and which are excluded
• Where visitors left the site
• What share of people who reached the enquiry form submitted it
• Whether the numbers changed before and after a change was released

Public information is enough to propose a direction. Deciding what to fix first requires the gap between impressions and clicks, and between form arrivals and completions. Without that gap, work may start on pages with little impact. Sharing data is a way to add evidence to the decision; it does not guarantee an outcome.

GA4 and Search Console answer different questions

The two products can be linked, but linking requires strong permissions. Google Analytics Help states that creating the link requires the Editor role on the Google Analytics 4 property and verified-owner status on the Search Console property. The Search Console permission table likewise lists linking a Google Analytics account as an owner-only action. The permissions needed for analysis alone differ from those needed to set up the link.

Choose the role by least privilege

Select the smallest role the work requires, rather than the role that is most convenient for the recipient. Both products provide view-oriented roles.

GA4 has five roles and two data restrictions

Two data restrictions, No Cost Metrics and No Revenue Metrics, can be applied alongside a role. Google Analytics Help states that restricted metric values are not shown in reports and that 0 is displayed instead.

The recipient cannot tell whether a value is genuinely zero or hidden by a restriction. When we apply data restrictions at Netsujo, we tell the recipient that a restriction is in place.

Inheritance also matters. Google Analytics Help states that roles at a parent level are inherited by default and that a member’s effective permission is the least restrictive role for that resource. Granting Editor at account level makes the user an Editor on every property in that account. To share a single property, grant the role at property level.

Search Console has owners, full users, and restricted users

External improvement agencies are normally granted one of owner, full user, or restricted user. The associate category depends on the type of association, such as the Chrome Web Store, and is not an option for sharing analytics data.

For analysis alone, a restricted user can still see Performance and the reports. Sitemap submission and URL Inspection requests require a full user. Because owner permission includes adding and removing other users, Netsujo does not grant owner access to external companies as a rule.

Search Console Help also states user limits: up to 100 non-owner users per property, delegated owners up to a combined total of 500 verified and delegated owners, and no per-property limit on verified owners.

Grant access per user, not by sharing an ID and password

Avoid shared accounts and grant access to each individual Google account instead. In both products users are identified by Google account. Google Analytics Help states that users are identified by email address and that the Google email address used to add the user, together with its password, becomes that user’s Analytics sign-in credentials. Search Console Help states that a user must have a valid Google account and that email groups cannot be added as users. GA4 also supports user groups for accounts that belong to an organization, and members of those groups are still added individually by email address.

Per-user grants also keep the record of configuration and ownership changes meaningful. The GA4 change history records the user who made each change and covers the last two years. Search Console provides an ownership history covering events such as owner additions and removals and successful or failed verification attempts. A shared account collapses all of these records into one identity.

Finally, per-user grants create a unit of revocation: when a person leaves the engagement, only that person is removed. With a shared account, removing one person means changing the password and redistributing it to everyone else. In our experience that pattern makes missed revocations more likely, so we do not use it.

Checks before granting, during use, and at the end

The period, ownership, and record-keeping items are Netsujo operating guidance, not Google requirements.

Alternatives when access cannot be granted

Search Console offers a per-report share link. Google states that sharing gives access only to the current issue details page and the validation history page for that issue, grants no access to other pages of the property, does not allow the recipient to take actions on the property or account, and can be disabled at any time to revoke the link.

• Agree the period and metrics first, then export and share the report.
• Review the numbers together in a screen-sharing session.
• Start with a restricted user or viewer role and raise it only for actions shown to be necessary.
• Diagnose what can be judged from public information first, then narrow down the points that genuinely require access.

These four are operating options rather than product specifications. The last one lets work start while the data shared externally stays minimal.

When SIGNAL needs access, and when it does not

The free SIGNAL diagnosis runs on public information only, so it does not require GA4 or Search Console access, and no payment method is registered. Public information alone covers HTTP status and redirects, initial HTML and the rendered DOM, title, description and canonical, robots.txt and sitemaps, heading and body structure, internal links, JSON-LD structured data, consistency of company information across pages, CTA and form paths, and gaps between how search and AI describe the company and the official information.

Access becomes necessary from the paid data-connected diagnosis onward: Search Console and GA4 data, GTM and GA4 event configuration, and, within the agreed contract scope, source repositories and the CMS.

When we do connect GA4 and Search Console, we connect them only where necessary, read-only and with least privilege, and the connection can be removed at any time. Where access is not provided, we do not assert conclusions by inference; we separate confirmed facts from confidence levels.

Even with the smallest role, the recipient can read the data within the shared scope. No configuration removes that risk. What you decide is where the line sits.

How to revoke access and confirm that it is gone

Revocation is not complete at the moment the delete button is pressed. Inheritance and re-verification paths also need checking.

Revoking GA4 access

Google Analytics Help describes opening Access Management under Admin for the account or property, selecting the checkbox for each user to remove, and clicking Remove. To remove only part of a permission, open the user and remove the permission, then save. Help also states that removing a user or user group requires the Administrator role at account level and can only be done at account level.

Confirm two things: that the user no longer appears in Access Management, and that no account-level role remains. Because effective permission is the least restrictive role, removing a property-level role while an account-level role remains leaves access in place. The removal itself appears in the change history, which requires the Editor role to view and covers the last two years.

Google Analytics Help states that Data Access History, which shows who queried data and when, is available only for Google Analytics 360 properties and for accounts with at least one 360 property. Standard properties cannot review past access through that feature.

Revoking Search Console access

Search Console Help describes opening the Users and permissions page in property settings, selecting the menu next to the user, and clicking Delete permission. The page is visible only to property owners, and the change takes effect immediately.

Deletion alone can leave a path back. Help states that removing an owner from a Search Console property stops that owner from accessing the property but does not delete or revoke the verification token, and that as long as the token remains on the property, the removed owner can re-verify ownership.

Remaining tokens are listed under Unused ownership tokens on the Users and permissions page. Help lists the token forms as an HTML file in the site root, an HTML tag on the home page, a DNS record, a Google Analytics account, a Google Tag Manager account, and a Google Sites or Blogger account.

This is where GA4 and Search Console interact. Help states that to fully disable the Google Analytics verification mechanism for a user, you must switch the Google Analytics account used by the site or revoke that user’s edit permission in it. Removing only the Search Console permission while GA4 edit access remains can leave a re-verification path open, so check both together.

Token deletion carries its own caution. Help notes that the same verification token can be reused to verify ownership across services such as Search Console, Merchant Center, and Google Workspace, so deleting a token may adversely affect other services that rely on it. Confirm which services use the token before deleting it.

Verify revocation using three views: the Users and permissions list, the unused ownership tokens list, and the ownership history, which records owner additions and removals, successful and failed verification attempts, and cases where a known verification token was removed.

Summary

Starting without granting access is also an option. Diagnosing what public information can settle first narrows the points that genuinely require a connection, which makes internal approval easier to obtain.

Sources and review date

Statements about Google specifications in this article were confirmed on the following pages on 2 August 2026 (Japanese versions). Screens and steps can change, so check the source page before acting.

• Search Console Help, “Managing owners, users, and permissions”: https://support.google.com/webmasters/answer/7687615
• Search Console Help, “Page indexing report”, section on sharing a report: https://support.google.com/webmasters/answer/7440203
• Analytics Help, “Access and data-restriction management”: https://support.google.com/analytics/answer/9305587
• Analytics Help, “Connect Search Console to Google Analytics”: https://support.google.com/analytics/answer/10737381
• Analytics Help, “Add, edit, and delete users and user groups”: https://support.google.com/analytics/answer/9305788
• Analytics Help, “View account/property change history”: https://support.google.com/analytics/answer/9305465
• Analytics Help, “View data access history for a Google Analytics account or property”: https://support.google.com/analytics/answer/15561150

See the Netsujo SIGNAL service

Free web sales foundation diagnosis (no access grant required)

How to diagnose low B2B website enquiries