Analytics tells you what visitors do. Search Console tells you what search engines see. Both need to prove you control the domain first, and that verification step is where hosting comes into it.
Verify at the domain, not the URL
Search Console offers two kinds of property.
A URL prefix property covers one exact address, so https://example.com and https://www.example.com are separate properties with separate data.
A domain property covers every subdomain and both protocols at once. It requires DNS verification, and it is the one to choose.
The reason is practical: a site reachable at more than one address splits its reporting across properties, and you end up comparing two halves of the same site. Addon domains and duplicate content covers why those extra addresses exist in the first place.
DNS verification, in cPanel
You are given a TXT record to add. In cPanel's Zone Editor, add a TXT record at the domain root with the supplied value.
Three things that catch people.
The name is the root, entered as @ or the domain itself depending on the interface: not a subdomain.
You can have several TXT records at the same name. Adding a verification record does not replace your SPF record, and it must not be merged into it. Understanding TXT records explains the one-SPF-record rule that does apply.
It takes time. Verification fails if you check before the record has propagated. Confirm it yourself first:
dig TXT example.com +short
Leave the record in place afterwards. Removing it once verified un-verifies the property, usually months later when nobody connects the two.
The other verification methods
For a URL prefix property, you can also upload a file to the site root or add a meta tag to the homepage.
Both work and both are fragile: a file deleted during a redesign, or a meta tag lost when the theme changes, silently ends verification. DNS survives both.
Use the file or tag method when you cannot edit DNS, and set a reminder that it exists.
Submit a sitemap
Once verified, submit your sitemap URL. It is how search engines find pages that are not well linked internally, and the report tells you which submitted URLs were not indexed, which is more useful than the submission itself.
Check the sitemap is current and returns the right status. A sitemap listing pages that 404, or one generated once and never regenerated, is worse than none because you are asserting something untrue.
Analytics: one tag, once
The most common analytics fault is the tracking code appearing twice: once in the theme and once from a plugin. Every visit is then counted twice, the bounce rate collapses to something implausible, and every number is wrong in a way that looks like success.
Pick one place to install it and check the page source for the tracking ID appearing more than once.
Then exclude your own visits, or a small site's figures are mostly you. And check the site's timezone matches what you expect, or a day's data is shifted; the same trap that makes shop reports look wrong. For that, see reading WooCommerce analytics.
Consent, before the tag fires
In several jurisdictions, analytics cookies require consent before they are set, not a banner announcing that they already have been.
A consent tool that blocks the tag until the visitor agrees is the arrangement that complies. One that shows a notice while tracking regardless is decoration.
This reduces your data, and that is the trade. Reporting on the visitors who consented is the honest position instead of a technical problem to route around.
What Search Console tells you that nothing else does
Three reports that repay reading monthly.
Coverage, which pages are indexed and why others are not. "Excluded by noindex" on pages you want indexed is the launch mistake that hides a whole site. The launch checklist goes into checking for it.
Queries, what people searched before seeing you, including the searches where you appear and are not clicked.
Crawl errors: server errors and not-found pages as the crawler experienced them, which surfaces the redirects you missed after a move.
Verify the ownership arrangement too
Both accounts should be owned by you or your company, not by a developer or an agency using their own login.
Add others as users rather than handing over the account. When the relationship ends you remove a user; the alternative is asking someone to hand back access to your own data. There is more on the same principle for hosting and domains in working with a developer.
After any migration or address change
Both tools need attention, and neither tells you they were affected.
Re-check verification, confirm the sitemap still resolves, and make sure the analytics tag survived the move. And if the site address changed, use Search Console's change-of-address tool alongside your redirects. The redirects do the work, and the notification makes it faster. Redirecting a domain or page walks through the redirects themselves.
Before the tag fires at all, there is a consent question to settle. What a Website Needs for Privacy and Cookie Compliance deals with what actually needs it.
One file decides what search engines are allowed to fetch, and using it to hide a page does the opposite of what people expect. How to Write a robots.txt and Control Crawling picks it up from there.
Verification records accumulate for years, and some are re-checked while others are not. How to Use TXT Records for Domain Verification explains telling them apart.