Managing Agency Access During a Site Move

Problem Statement

A migration usually involves at least one party who is not on your payroll: an SEO agency running the redirect QA, a development partner deploying the new stack, or a contractor handling the DNS cutover. Each needs Search Console access, each needs it on two properties for the duration, and each has a contract that ends on a date nobody has written into the runbook. Granting owner rights to everyone is fast and leaves you with a property you cannot audit; granting too little means the person who has to file a Change of Address at 6 a.m. cannot. This page sits under Ownership Transfer Protocols.

Access scope across the migration timeline Three phases — pre-launch, cutover window, and post-migration — each showing which parties hold which level of access on the legacy and new properties. Access Widens, Then Narrows Again Pre-launch agency: full user legacy property only read crawl + coverage Cutover window agency: owner, both time-boxed to 14 days the only wide window Post-migration agency: full user new property only owner rights returned The elevated window has a start date and an end date written into the runbook, not an open grant.
Owner rights exist for the cutover window only; before and after it, a full user role does everything an agency actually needs.

When to Use This Approach

  • An external partner is running redirect QA or filing the Change of Address on your behalf.
  • More than one supplier touches the property and you need an audit trail of who changed what.
  • The engagement ends on a known date and access must lapse with it rather than linger for years.
  • Legal or procurement requires you to demonstrate least-privilege access to a production analytics surface.

Why External Access Drifts

Nobody sets out to give a supplier permanent owner rights to a production analytics surface. It happens because access is granted under time pressure, in the shape that unblocks the immediate task, and there is no event that forces a review afterwards. A contract ends and the invoices stop; the Search Console grant does not stop with them, because nothing in the billing system knows it exists.

Migrations accelerate the drift in three specific ways. First, they create genuine need for elevated access — somebody has to file the Change of Address, and only an owner can. Second, they double the surface, because for a period there are two properties rather than one and grants are made twice, usually at different times by different people. Third, they run to a deadline, which is exactly the condition under which “just make them an owner, we’ll tidy it up after” is said and never revisited.

The countermeasure is not stricter rules; it is making the grant self-limiting. A grant with a written end date, recorded in the same runbook as the TTL restoration and the monitoring stand-down, gets removed because removing it is a checklist item somebody is already working through. A grant with no end date depends on somebody remembering, months later, that it exists.

# Make the audit trivial: one command, run monthly, that lists every non-employee grant
curl -s -H "Authorization: Bearer $GSC_TOKEN" \
  "https://www.googleapis.com/webmasters/v3/sites" \
  | jq -r '.siteEntry[] | select(.permissionLevel != "siteRestrictedUser") | .siteUrl'

Step-by-Step Instructions

1. Decide the Role Before the Request Arrives

Write the role into the statement of work, not into an ad-hoc Slack thread on cutover morning. In practice three roles cover everything: restricted user for reporting-only stakeholders, full user for the agency doing the work, and owner only for the person who will file the Change of Address.

# Snapshot current access before you change anything — this is your audit baseline
curl -s -H "Authorization: Bearer $GSC_TOKEN" \
  "https://www.googleapis.com/webmasters/v3/sites" | jq -r '.siteEntry[] | [.siteUrl, .permissionLevel] | @tsv'

2. Grant on Both Properties, Deliberately

During a domain change the agency needs the legacy property to watch old URLs drop out and the new one to watch replacements appear. Grant both at once and record both — a half-granted supplier will ask for the second one at the worst possible moment.

3. Time-box Owner Rights to the Cutover Window

Owner rights are needed for exactly two actions: adding users and filing the Change of Address. Elevate on the day, diarise the revocation, and keep the elevation visible in the go-live runbook described in Writing a Migration Go-Live Runbook.

# Verify the elevated account can actually file the Change of Address
curl -s -H "Authorization: Bearer $AGENCY_TOKEN" \
  "https://www.googleapis.com/webmasters/v3/sites/sc-domain%3Aexample.com" | jq -r '.permissionLevel'
# expect: siteOwner (siteFullUser cannot file a Change of Address)

4. Keep Verification Tokens Out of Agency Hands

An agency that verifies with its own DNS TXT record holds a claim you cannot revoke from the interface — you must delete their record. Prefer delegating ownership from a token you control, so revocation is a single click rather than a DNS change negotiated over email.

Revocation difficulty by how access was granted A matrix comparing delegated ownership, agency-held DNS token, full user and restricted user against how access is revoked and how long revocation takes. How Hard Is It to Take Access Back? HOW ACCESS WAS GRANTED REVOKED BY TIME TO REVOKE Delegated ownership one click in Settings immediate Agency-held DNS token deleting their TXT record needs DNS change Full user one click in Settings immediate Restricted user one click in Settings immediate Only one row in this table takes access away from you as well as giving it.
Every grant you can revoke from the interface is reversible in seconds; a token held by someone else is not.

5. Offboard on a Date, Not on a Feeling

Put the revocation in the same calendar as the TTL restoration and the monitoring stand-down. A migration ends with a checklist, and access removal belongs on it alongside the steps in Restoring DNS TTL After a Successful Cutover.

Worked Example

A publisher engaged an agency for a twelve-week domain change. The original arrangement — the agency verifying both properties with their own tokens — had been carried over from a project three years earlier, and nobody could remember which of the four TXT records at the apex belonged to whom.

The remediation ran in this order:

  1. The in-house team verified both properties with tokens under their control, so the properties were no longer dependent on agency records.
  2. The agency was re-granted access as delegated owners rather than verified owners, revocable from the interface.
  3. The four unattributed TXT records were removed one per day, with dig run after each to confirm both properties were still verified — the safe order established in Verifying DNS Propagation with dig Across Resolvers.
  4. On the contract end date the delegated ownership was removed in one click, and access dropped to zero with no DNS negotiation.

The whole cleanup took under a week and turned an unbounded external claim into a revocable grant.

Verification

# 1. Which TXT records exist, and can you account for every one?
dig +short TXT example.com | grep google-site-verification

# 2. Confirm the intended access list matches reality on both properties
for prop in "sc-domain%3Aexample.com" "sc-domain%3Alegacy.example"; do
  curl -s -H "Authorization: Bearer $GSC_TOKEN" \
    "https://www.googleapis.com/webmasters/v3/sites/$prop" | jq -r '"\(.siteUrl)\t\(.permissionLevel)"'
done

# 3. After offboarding: the agency token should no longer resolve the property
curl -s -o /dev/null -w '%{http_code}\n' -H "Authorization: Bearer $AGENCY_TOKEN" \
  "https://www.googleapis.com/webmasters/v3/sites/sc-domain%3Aexample.com"   # expect 403

An unaccounted-for verification record is the finding that matters most here. Every one of them is a live claim on the property by someone, and during a migration it is also a rule you must remember to keep working — the same class of dependency covered in Transferring GSC Ownership Without Losing History.

Offboarding sequence at the end of an engagement Five ordered offboarding steps: confirm internal ownership, downgrade the agency to full user, remove owner rights, delete agency tokens, then re-check that the property is still verified. Offboarding Order 1 Confirm you still own it 2 Downgrade owner to user 3 Remove user from both props 4 Delete tokens one at a time 5 Re-verify both properties Steps 1 and 5 bracket the sequence: prove you hold the property before and after. Deleting tokens before step 1 is how teams unverify a property they still need.
Bracketing the removal with an ownership check at both ends turns an irreversible step into a verified one.

FAQ

Can an agency file a Change of Address on my behalf? Yes, but only as an owner — a full user cannot see the form. That is the single strongest argument for a time-boxed elevation: the agency needs owner rights for one action on one day, not for the length of the contract.

Should the agency verify the property themselves? Prefer not. A token they control is a claim you can only remove by editing DNS or deleting a file, which turns a routine offboarding into a change request. Delegate ownership from a token you hold and revocation stays a single click.

How long should an agency keep access after go-live? Long enough to see the migration through its monitoring window — usually the same six-to-eight weeks you keep the legacy property under observation. Cutting access on the day of the cutover leaves nobody watching when the delayed problems surface, and those are the expensive ones.

Does removing a user affect the property’s data? No. Users are an access-control layer only; the report data belongs to the property. Removing every user does not delete anything, it just means nobody can currently read it.

What if the agency verified using an analytics property we are about to switch off? Re-home the claim before you switch anything off. Verification through analytics or a tag manager container dies silently when the container is retired or a consent banner blocks the script, and the failure shows up as an unverified property rather than as an error anyone was watching for.

Is a restricted user enough for a reporting-only stakeholder? Usually yes. Restricted users see the performance and coverage reports, which is what most stakeholders actually want, and they cannot submit sitemaps, request indexing, or change settings. Granting a full user role by default is the most common unnecessary escalation, and it is invisible until somebody uses a capability you did not intend them to have.

How do I hand over cleanly when the agency relationship ends badly? Do the ownership work first and the conversation second. Verify your own claim, confirm it independently, and only then remove access — the sequence in this page assumes cooperation but does not require it, provided you never depended on their token. If you did depend on it, you have a negotiation rather than an offboarding, which is precisely the situation to avoid creating.

Should each agency person have their own account, or should we share one? Individual accounts, always. A shared login cannot be audited, cannot be partially revoked when one person leaves the engagement, and produces a change history that attributes every action to the same anonymous identity. The small administrative cost of managing several grants buys an audit trail that is worth something during an incident.

Do we need to grant access to both properties for the whole engagement? Only while both properties are live and being watched — in practice from a few weeks before the cutover to the end of the monitoring window. Before that, the legacy property alone is sufficient; afterwards, the new one alone is. Matching the grant to the phase keeps the access list small enough that anomalies stand out.

Related

← Back to Ownership Transfer Protocols