Skip to content
whovisited.

Search Console · Troubleshooting

Fix a Search Console property that does not match your website

Troubleshoot why a verified Search Console property is missing from WhoVisited by checking property type, protocol, hostname, and the site's allowed origins.

A verified property can still be the wrong property

You connect Google Search Console, return to your analytics settings, and see no property to select. That does not necessarily mean Google verification failed. A property can be verified in the Google account you used and still describe a different protocol, hostname, or subdomain from the website configured in your analytics tool.

Start by writing down two exact values: the Search Console property shown in Google's property selector and the website's allowed origin in your analytics settings. Compare the full values, including https versus http and www versus the bare domain. A matching brand name is not enough to establish that they refer to the same web property.

Know which Search Console property you added

Google offers Domain properties and URL-prefix properties. A Domain property is written as a domain without a protocol or path. It includes subdomains and protocols for that domain, and Google requires DNS verification. In the Search Console API, it is represented with the `sc-domain:` prefix, for example `sc-domain:example.com`.

A URL-prefix property includes a protocol and begins with the exact URL prefix you entered, such as `https://example.com/`. It does not automatically include another protocol or a different subdomain. If you have separate properties for `http://example.com/`, `https://example.com/`, and `https://www.example.com/`, each represents a different prefix in Google Search Console.

If you control DNS and want one property for a domain and its subdomains, Google's Domain property is often the simpler reporting choice. If you need a particular protocol, hostname, or URL path, a URL-prefix property can be more specific. Neither choice changes your website's canonical URL or redirects; those are separate site configuration decisions.

Check the Google account and property access

  1. Open Search Console with the same Google account you plan to connect, then choose the website from the property selector.
  2. Confirm that the property appears in the account and that the account has access beyond the unverified-user permission.
  3. Copy the property identifier exactly: a Domain property looks like `sc-domain:example.com`; a URL-prefix property includes `https://` or `http://` and usually ends with `/`.
  4. If another person owns the property, ask them to grant your Google account access in Search Console before connecting it.

WhoVisited requests a list of properties available to the Google account after the read-only Search Console connection. It excludes properties that Google reports as unverified for that user, then checks whether a property matches one of the website's configured origins. The connection cannot make a Google property verified or grant your account access to it.

Compare the property with your allowed origin

An allowed origin is an exact scheme and host, such as `https://example.com`. WhoVisited uses it to identify which Search Console properties can be selected for that website. A Domain property such as `sc-domain:example.com` matches an allowed origin on `example.com` or one of its subdomains, such as `shop.example.com`. A different root domain will not match.

For a URL-prefix property, check both the scheme and hostname. The current integration requires the scheme to match and accepts the same hostname; for HTTPS it also accepts the `www` form of a configured non-`www` hostname. It does not treat an arbitrary subdomain as equivalent, and a prefix for a deeper path such as `/store/` is not selectable for this integration.

For example, if the allowed origin is `https://example.com`, `https://example.com/` and `sc-domain:example.com` can match. `http://example.com/`, `https://shop.example.com/`, and `sc-domain:another-example.com` do not match that origin under the current rules. If your production site genuinely uses another origin, add that origin to the same website's allowlist first, then reconnect or refresh the available property list.

Reconnect, then save the property for the right website

  1. In WhoVisited, open Settings for the website whose origin you checked. Confirm its allowed origins reflect the real production site.
  2. Connect Search Console with the Google account that can access the matching property. If it was already connected before you fixed the origin, disconnect and reconnect so the property list is refreshed.
  3. Choose the matching property from the verified-property list and save it. The integration stores the choice for that website, not as a global selection for every website in the workspace.
  4. Open Growth for that website and check for search-result metrics after data is available. Search Console and website sessions are separate measurements, so their totals should not be expected to match.

The connection uses read-only Search Console access. WhoVisited stores an encrypted refresh token so it can update aggregate search data, and a workspace owner or admin chooses the property. The integration does not change verification, DNS, canonical tags, redirects, or Search Console settings.

If the property is still missing

  1. Verify that the selected Google account is the account that can see the property; being signed into another account in the same browser can cause confusion.
  2. Check whether the property is a Domain property or URL-prefix property, then compare its exact identifier with the website's allowed origin.
  3. If the website has both `www` and non-`www` origins, confirm which one is canonical and which origin is actually configured. Do not add unrelated domains just to make a property appear.
  4. Reconnect after an access or origin change so WhoVisited receives a fresh list from Google. If it remains absent, note the property identifier and configured origin when contacting support; never send an OAuth code or refresh token.

The integration intentionally filters out unrelated properties so search data is not attached to the wrong tracked website. A successful OAuth return only confirms that the account connection completed; it does not prove that a suitable property exists or that Search Console has already collected rows for the selected date range.

Use the property match as a setup check

A quick setup note can prevent a frustrating loop: record the canonical site origin, the Google property type and identifier, and the Google account that has access. If they line up, save the property and review search-result metrics beside the corresponding landing pages. Search impressions and clicks describe Google Search activity; WhoVisited sessions describe browser visits that its tracker successfully records.

For background on interpreting the two datasets together, read the WhoVisited guide to why Search Console clicks and website sessions differ. Compare them as complementary measurements with different collection rules, not as numbers that should reconcile one-for-one.

References and further reading

  1. Google Search Console Help: Add a website property
  2. Google Search Console API: Sites list
  3. WhoVisited: Why Search Console clicks and website sessions differ