Install Google Analytics on WordPress by choosing one documented tag insertion route, connecting the intended property and testing the resulting events against your consent design. Site Kit provides an official installation route. A useful handover should show which tag runs, which visitor choices it follows and what the selected business event actually records.
Begin with an inventory of the site rather than immediately adding another plugin. Write down any existing Analytics plugin, theme snippet, tag manager container or custom integration. Assign a person to decide which route will own measurement. Keep the current configuration available for comparison, and agree a recovery approach before changing an established website.
This guide focuses on installation and acceptance tests. For the wider choice of meaningful business events and reports, use the separate Analytics event-design guide. Here, the goal is a small, explainable installation whose behaviour another administrator can inspect.
What should you check before installing Site Kit?
Site Kit requires access to the WordPress REST API. Its installation documentation explains how to check this under Tools > Site Health. Resolve an unavailable API through the site’s responsible administrator before attempting setup repeatedly. Record the actual finding, including whether a security configuration or access restriction needs investigation.
Only WordPress administrators can set up Site Kit. This is a setup requirement, not a reason to distribute administrator accounts to everyone who wants reports. The same documentation describes dashboard sharing for a limited view. Decide separately who configures the connection and who simply needs to read the resulting metrics.
Site Kit recommends that client Google service entities belong to the client. Record the business owner’s account and the people granted access, without placing passwords in the handover. The practical question is whether the business retains control when its website administrator changes. Ask the owner to confirm access through their own account before considering the ownership task complete.
Google’s installation route also calls for a publicly accessible production website and describes separate guidance for staging. Rehearse the configuration review and event specification away from live customer data, then plan any production connection deliberately. Do not make a protected development site public merely to get through a setup screen.
How do you connect the intended Analytics property?
Site Kit can connect Analytics during initial setup or later through Connect More Services. Follow the current Site Kit setup flow, sign in using an authorised Google account and inspect the account or property being selected. A familiar business name alone is a weak identifier: retain the property and stream identifiers in your configuration record.
Google associates tag IDs beginning with G- generally with Analytics accounts. Its WordPress tag instructions distinguish that route from tags generally associated with Google Ads. This is useful when reviewing an old configuration: copy the exact identifier into your private installation inventory rather than assuming every Google tag on the site serves the same purpose.
Creating an Analytics property requires the Editor role. If an appropriate property already exists, first establish whether it should remain the owner of this website’s measurement. If a new property is needed, Google’s Analytics setup guide describes creating the property, choosing its reporting settings and adding a web stream. Keep the reporting time zone decision with the handover so later readers can interpret daily reports consistently.
Enhanced measurement automatically collects page views and other events. Review the selected stream’s enhanced-measurement choices before commissioning extra event code. Ask whether the required action is already represented and inspect the actual result. A label such as “download” is not enough to establish that it matches the business’s intended document or visitor action.
Use the installation inventory to identify competing insertion routes. The acceptance question is whether the intended action produces the expected evidence through the agreed route. If you find overlapping configurations, investigate them before removing anything; another team may depend on a container for a different purpose.
What does the consent test need to distinguish?
Basic consent mode blocks Google tags until the visitor interacts with the consent banner. In advanced consent mode, Google tags can send measurements without cookies while consent is denied. These are different documented behaviours in Google’s consent-mode overview, so a test cannot treat every network request before consent as the same defect.
Choose the intended design with the person responsible for your consent requirements. Write down what should load before a choice, after acceptance and after refusal. Then compare the actual tag behaviour with that design. The installation steps for Site Kit and the consent implementation are separate work items; selecting an Analytics property does not specify the site’s consent solution.
Google’s overview distinguishes obtaining a choice, communicating its state and making tags respect it. Test each part. A visible banner demonstrates the interface; it does not by itself establish what a connected tag receives. Likewise, a request reaching Google does not prove that the visitor granted permission for every storage or advertising purpose.
| Test state | Question to settle in advance | Evidence to retain |
|---|---|---|
| New visit, no choice | Which implementation and defaults should apply? | Starting consent state and observed tag activity |
| Analytics accepted | Does the measurement follow that selected choice? | Updated state and the intended event evidence |
| Analytics refused | Does the result match the documented chosen mode? | Storage and request observations with context |
| Choice changed | Does the update reach the relevant tags? | Before-and-after state for the same test journey |
| Another insertion route found | Who owns it and what does it send? | Configuration owner and decision on overlap |
Keep these observations in a restricted technical record. Use non-sensitive test actions, avoid collecting form contents in diagnostic evidence and remove personal details from shared screenshots. For advertising-specific event decisions, continue with Google Ads conversion tracking.
Original measurement handover card: a brochure download
Consider a hypothetical business website with a public brochure link. Its owner wants to distinguish opening the contact page from downloading that brochure. The following original worksheet tests that precise distinction without turning a click into a claimed enquiry or sale.
Define the action. Write the brochure link, expected event name and allowed contextual information. State what should happen when the visitor views the page without selecting the link. Agree that names, email addresses and free-text messages do not belong in this test payload. Give the test card an owner who can confirm the business meaning.
Record the connection. Add the property, stream, insertion route and responsible administrator. Note the enhanced-measurement settings inspected. Keep a reference to the approved consent design alongside this information so the event test and the privacy test describe the same configuration.
Run a controlled journey. Start with a fresh test session and record the visitor choice used. View the page, select the brochure once and inspect what is recorded. Repeat the page-only case separately. Google recommends the Realtime report to verify incoming data after collection begins. Its setup guidance makes that a useful initial reception check; the worksheet should still retain the event’s intended meaning and observed details.
Investigate differences. If the event is absent, check the selected property and installation route before renaming events. If it appears more often than expected, compare the recorded visitor actions with the insertion inventory. Record the cause you establish, the change made and a repeat of the same journey. Avoid changing several unrelated settings together.
Hand over a decision. Mark the connection, consent states and brochure event separately as demonstrated or unresolved. Retain enough context for another administrator to repeat the exercise. A populated dashboard should not close an unanswered question about the event or the visitor’s choice.
For the broader website work, see WordPress. To discuss a measurement brief, get started with the intended action, existing tag inventory and the test evidence still needed.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.