Scanning a client-owned site, without a shared login.

The problem: the old site belongs to someone else

A MigrateKit comparison reads both sites and stores their pages, copy, images and metadata. That is why every scan starts with proof of control: without it, anyone could point the scanner at a competitor's site and pull a full copy of it out of the report.

For an agency this creates a dead end. The agency runs the project, needs the comparison and owns the report, but the old site - and often the new one until launch - is in the client's name. The agency cannot verify a host it does not control, and it should not be able to scan it on trust.

The workaround agencies used to reach for was worse than the problem: asking the client for a login, or for an exported browser session, or for access to their Google account. That hands over far more than the scan needs, cannot be revoked cleanly, and turns a client relationship into a password in a notes app.

How client authorization works

Both sides are signed in to MigrateKit with Google, and the client proves the site is theirs. The agency never sees a credential.

On the agency side

1. Sign in at api.migratekit.io and open Client site authorization from the dashboard.
2. Enter the address of the old site that belongs to your client. This creates a one-time link.
3. Copy the link and send it to the client by email or chat. It is shown once and expires in fourteen days.
4. When the client grants access, the dashboard lists the authorization with its expiry. Run the comparison as usual.

On the client side

1. Open the link. It asks you to sign in with Google, so the authorization is recorded against an account you control.
2. See who is asking and which site they want to scan.
3. Confirm you control the site with the same check every MigrateKit scan uses: a meta tag, a small file, or a DNS record. One is enough.
4. Press the button that grants access. Nothing is shared before that click, and the authorization can be revoked later.

What the client is granting

The authorization is deliberately narrow. It is:

• Read-only. Scans read pages, copy, images and metadata. Nothing on the site is written, published or edited.
• One host. A grant for www.client-site.com does not cover client-site.com, a staging subdomain, or any other site the client owns.
• One agency. It is recorded against the agency's MigrateKit account and cannot be used by a different account.
• Time-limited. It ends after thirty days on its own, and either side can revoke it earlier.
• Visible. The client sees the agency's Google-authenticated name and email address before granting, and can revoke from the same page.

What the agency never gets

• The client's Google password, session or account access.
• Hosting, CMS or DNS credentials.
• The ability to change, publish or delete anything on the site.
• Access to the client's other hosts or future sites.
• A permanent authorization for a one-off project.

The security model, in plain terms

The rules exist so that the normal ownership gate is never weakened for everyone else. Concretely:

• Proof of control is still required. A delegation can only be granted by a signed-in account that has verified the host. The check is repeated on the final grant, so a stale page cannot be replayed.
• The link is stored hashed. MigrateKit keeps only a SHA-256 hash of the one-time token, so a leaked data file cannot be turned back into a working link.
• Links are single use. Granting access consumes the request. A second attempt with the same link is refused.
• Delegations are host-exact and user-scoped. The gate accepts one only for the exact host and the exact agency account named in the grant.
• State-changing requests are same-origin checked. Creating a request, granting and revoking all reject cross-origin POSTs.
• Either party can revoke. Revocation takes effect immediately, and the agency's next scan of that host is gated again.

When to use it, and when not to

Use it when the site you need to scan belongs to your client and they cannot or should not use your MigrateKit account. Do not use it as a way around verification for sites you actually control: sign in with your own account and confirm the site yourself, which is faster.

If a client cannot complete the verification step, there is no workaround and no exception. The point of the gate is that the site's owner has to agree. The ownership guide covers which of the three methods is easiest on each platform.

Where this fits in a move

Client authorization happens before the comparison, alongside the normal ownership step. The rest of the process is unchanged: confirm both sites, run the comparison, read the scorecard. If you have not started yet, the free scan needs none of this - one address, about 20 seconds, no account.