The questions that come up, answered plainly.

Because they are two halves of one picture. Analytics tells you what visitors did once they arrived; Search Console tells you what they searched for and how often your page appeared. You sign in once, grant read-only access to both, and we bind the property for each that belongs to your domain. You can untick Search Console on the consent screen and still connect; the dashboard will simply show search data as not connected until you add it.

No. Search Console offers two kinds of property, and we accept either:

• URL-prefix property — for example https://www.example.com/. This is the easy one. Google can usually verify it automatically through the Analytics tag already on your site, with no DNS changes. If a verified URL-prefix property exists for the address your site uses, we connect it immediately.
• Domain property — sc-domain:example.com. Cleaner, because it covers www and non-www, http and https, and every subdomain in one place. But creating one requires adding a DNS record, which many site owners cannot or would rather not do. It is optional. If you have both, we prefer the Domain property.

We will never block your setup because you lack a Domain property, and we will never ask you to touch DNS.

Three common reasons, in order of likelihood:

1. The property is for a different address than your site actually uses. A URL-prefix property for https://www.example.com/ holds no data if visitors land on https://example.com (or vice versa). Google indexes the address people end up at. Your dashboard checks this and says so in plain words; the fix is to add a URL-prefix property for the address it names, then click Re-match property.
2. The property is new. Search Console starts collecting when the property is created and finalises data about three days behind. A brand-new property is legitimately empty for a few days.
3. Your site genuinely has no search impressions yet. New or small sites often do not. The connection is working; there is nothing to show.

Search Console finalises data roughly three days after the fact. We report only the completed window, so you never see a fake dip on the most recent days. Analytics data is reported through today.

The one that is actually measuring your domain. We look for a property whose tag is installed on your homepage, or whose configured website URL is your domain. We never offer a menu of every property your connected account can see, so you cannot accidentally attach another site’s analytics to yours.

Not on your site. Google withdraws a saved authorization when the password on that Google account changes, when access is revoked from the account’s security page, or when the authorization goes unused for an extended period. Click Reconnect and it resumes; nothing on your site or in your reports is affected.

Read reports. Both permissions are read-only: analytics.readonly and webmasters.readonly. We cannot change settings, create or delete properties, or write anything into your Google account. You can revoke access at any time from your Google account’s security page or by clicking Disconnect in your dashboard; either stops the connection immediately.

The second copy is almost always the original verification tag, still sitting in a different place than where you pasted the new snippet — typically a “footer scripts” field in your CMS or theme while the new snippet lives in the header. Only the first copy runs, so nothing is broken, but remove the older one to keep the check clean. Verification does not depend on it.

Inside <head>, on every page, below your consent platform if you have one and above any Google tag. Most site builders have a “header code” or “code injection” field for this. There is one snippet. It follows the consent signal already on your page (Google Consent Mode v2, IAB TCF v2.2, Global Privacy Control, or a call to window.__obp.consent(true|false)); with no consent platform present it runs for every visitor.

Consent matters. The EU/EEA, the UK, and Switzerland require prior consent before a website measures its visitors, and a growing number of U.S. states and other countries impose their own notice and opt-out rules. Sites that do not comply may face legal consequences. We strongly recommend a consent platform on your site, whoever your visitors are. We do not supply a banner and we do not decide whether your site needs one; that decision, and the mechanism, are yours (Terms, Section 9).

We recommend CookieYes (hosted, free plan, no code), Klaro (open source, visual configurator), or an open-source library such as CookieConsent by Orest Bida. All three emit the Google Consent Mode v2 signal our snippet follows without any configuration. Keep whichever you choose above the snippet.

You can implement CookieConsent with a coding agent or a developer using the prompt below. It is written to work in any coding assistant, or as a brief for a person, whatever your site is built with. Your Setup page shows the same prompt with your site’s own snippet filled in.

Install and configure Orest Bida CookieConsent (the open-source vanilla-cookieconsent v3 library, MIT) on this website, self-hosted from the site's own origin rather than a CDN.

Before changing anything, work out how this site is built (static HTML, a framework, a CMS or site builder with a global header-code field, or Google Tag Manager) and where its <head> is edited for every page. If you cannot determine that, stop and ask. Obtain the library either as the npm package vanilla-cookieconsent or by downloading dist/cookieconsent.umd.js and dist/cookieconsent.css from the project's GitHub releases; serve both from this site.

Requirements:
1. Two categories: "Necessary" (read-only, always on) and "Analytics" (off until the visitor allows it). Add other categories only if the site already uses advertising or personalisation cookies.
2. Google Consent Mode v2. Add this inline script as the FIRST script in <head> on every page: window.dataLayer=window.dataLayer||[];function gtag(){dataLayer.push(arguments);} gtag('consent','default',{analytics_storage:'denied',ad_storage:'denied',ad_user_data:'denied',ad_personalization:'denied',functionality_storage:'denied',personalization_storage:'denied',security_storage:'granted',wait_for_update:500}); If Google Analytics is loaded through Google Tag Manager, set the same defaults with GTM's Consent Initialization trigger instead, and still make the update call in step 3.
3. In CookieConsent's onFirstConsent, onConsent, and onChange callbacks call gtag('consent','update',{analytics_storage: CookieConsent.acceptedCategory('analytics') ? 'granted' : 'denied'}).
4. Keep the site's existing Google Analytics (gtag.js) tag exactly as it is, but make sure it loads AFTER the default block so Consent Mode governs it. Outcomes By Page does not load or configure Google Analytics; do not add a second GA4 tag or a second dataLayer.
5. Place the Outcomes By Page analytics snippet after the CookieConsent script. It reads the Consent Mode state by itself, needs no configuration, and carries no Google property ID. The Outcomes By Page analytics snippet is a single <script async src="…/c/obp_….js"> tag from the site’s Outcomes By Page Setup page. If it is not in the codebase yet, leave a clearly marked placeholder comment where it belongs.
6. Add a "Cookie settings" link in the site footer that reopens the preferences modal (an element with data-cc="show-preferencesModal").
7. Banner content: plain, accurate wording that names Google Analytics and Outcomes By Page and what they measure; a link to the site's privacy or cookie notice; "Allow analytics" and "Decline" buttons of equal weight (guiOptions equalWeightButtons: true); no pre-ticked optional boxes; nothing runs before a choice is made.
8. Preserve the site's design, existing functionality, and accessibility. Match the modal's fonts and colours to the site. If the site sends a Content-Security-Policy, keep the library and its stylesheet same-origin and add no inline styles.

When you are done, report the files you changed and the final <head> order, which must be: default block, CookieConsent stylesheet and script, init script, Outcomes By Page snippet, Google tag.

Some header-code fields remove <script> tags that carry attributes they do not recognise. The snippet is a single tag with at most one data attribute, so this is rare; if the installation check cannot find it, paste it again and, if it happens twice, use a “custom HTML” or “code injection” feature rather than a generic header field.

No. It is the honest answer. A finding is only reported when a difference between two groups of pages is large enough, and measured on enough visits, that it cannot reasonably be chance. Roughly a hundred sessions or measured views per segment is the floor. Below that, we say so rather than guess. As traffic accumulates, findings appear on their own; you do not need to change anything.

Deliberately. Anything of the form “these pages do better than those” has to earn its place statistically and appears under Findings. The setup notices are about whether measurement is working at all: connections, outcomes named, pages tracked, decisions pending. A hand-written rule that stated a performance claim without testing it would be an opinion dressed up as a finding.

Search position is an average, so combining pages by taking the mean of their means would be wrong. We weight each page’s position by its impressions, which is why a group’s position can be closer to the page that Google shows most often.

Less than you might expect. It reads each page and describes what the page is and what a visitor can do on it, using your site’s own vocabulary and, where available, the words people actually searched for to reach that page. It proposes segments worth testing. It writes the plain-language explanation of a finding after the statistics have already decided the finding is real. It never decides whether a difference exists, never sees a number it did not compute, and nothing it writes is executed. Every step records the model and prompt version used.

Nothing you need to manage. Each weekly check reads your site as it is now: pages that moved continue under their new address with their history intact, pages that disappeared leave the current measurement but keep what was learned, and new pages are picked up and analysed as room allows on your plan. Once a month we also look at the tracked set as a whole and, where a page we chose has had no visitors while another page is clearly drawing them, we swap them and say so, with the numbers, under Changes in your report. Pages you chose or stopped yourself are never touched. A full relaunch means every page is read again once, which is the same work as your first month, and then things settle.