Website Metrics to Track After Launch: The First 90 Days

Website metrics tell you whether a newly launched site shows up in Google, loads fast, keeps visitors and brings in business. In this guide I share how I monitor the first 90 days after launch: indexing, Core Web Vitals, conversions, engagement and errors. I do not compare tools here. Instead, I explain what I check, when I check it and what I do next.

What are website metrics, and why track them right after launch?

Website metrics are measurements that turn a site's visibility, technical health, user behaviour and business results into numbers. You should track them from launch day, because indexing gaps, broken forms and slow pages in the first weeks quietly cost traffic and leads for months if nobody notices.

I have launched sites since 2012. In practice, the pattern rarely changes. Most problems do not appear on launch day. Instead, they show up in the first three weeks. A redirect goes missing, a form stops sending email, or the mobile menu fails on one phone model. If nobody looks, the damage grows in silence.

So I never treat launch as a finish line. Launch is the day measurement starts. If you watch the right numbers during the first 90 days, you close technical debt early. You also learn, with data, whether the new site actually works for the business.

Why do I split the first 90 days into three phases?

Not every metric becomes meaningful at the same speed. Error data speaks within hours. Search visibility, on the other hand, needs weeks. Therefore I divide the first 90 days into three phases, and each phase answers a different question.

These phases are a starting framework from my field experience, not a guarantee. On a large online shop the second phase lasts longer. On a five page company site it gets shorter. Still, the order stays the same: first function, then visibility, then business results.

At the end of each phase I hold a short review. I ask three questions only. What improved? What broke? What do we focus on next? That habit turns monitoring into a concrete task list rather than a pile of reports.

Which tracking setups should you verify on launch day?

If tracking is wrong, the next 90 days of data are worthless. So on launch day I do not look at reports. I look at the measurement itself. Put simply, my goal is this: every important action should record once, under the right name.

Here is my launch day checklist:

1. Verify the Search Console property and submit the XML sitemap.
2. Confirm in the GA4 realtime report that the data stream points to the live domain.
3. Test events such as form submits, phone clicks and WhatsApp clicks.
4. Mark the important events as key events in GA4.
5. Check that the staging noindex tag and the robots.txt block are gone.
6. Test that old URLs return 301 redirects to the new ones.

If you do not have a sitemap yet, the XML sitemap generator builds one quickly. Also tag your campaign links with the UTM builder from day one. Otherwise first month traffic lands in the "direct" bucket, and you never learn where it came from.

How do you monitor indexing after a website launch?

Indexing means your pages have entered Google's database. After all, a page outside the index never appears in search, however good it is. That is why, from week two, the report I open most often is the Page indexing report in Search Console.

Google's recrawl documentation states that crawling can take anywhere from a few days to a few weeks. So a handful of indexed pages in week one is no reason to panic. However, if your core service pages are still missing in week four, something is wrong.

I keep three numbers side by side:

• Pages submitted in the sitemap.
• Pages indexed.
• Pages not indexed, with the reason for each group.

The first two numbers should move closer over time. If the gap grows, you dig into the reasons. I cover general use of the tool in my Google Search Console guide. Here I focus only on the post-launch reading.

How do you read the "not indexed" reasons?

Google's Page indexing report help page groups excluded URLs by reason. However, not every reason signals a problem. For example, old redirecting URLs should stay out of the index. What matters is where your important pages sit.

These are the reasons I meet most often after launch:

• "Crawled, currently not indexed": Google saw the page but did not find it valuable yet. Strengthen the content and internal links.
• "Discovered, currently not indexed": Google knows the URL but has not crawled it. This is normal on new sites; patience and internal links help.
• "Excluded by noindex tag": often a leftover from staging. Check it at once.
• "Page with redirect": expected for old URLs.
• "Not found (404)": a sign of broken internal links or missing redirects.

If you moved from an old site, read this list next to my website migration SEO checklist. URLs lost in a migration usually surface in exactly this report.

What do impressions, clicks and average position say in the early weeks?

I have seen many clients look at clicks in week two and feel disappointed. On a new site, however, the first meaningful signal is impressions, not clicks. In other words, impressions show which queries Google already tests you for.

In this phase I check three things. First, do the queries match the topics you target? Next, which page ranks for which query? Finally, which way does average position move week by week? A single day tells you nothing, but a four week trend tells you a lot.

Do not read average position alone. If you collect impressions at position 60 for many loose queries, the average drops. That is not bad news. So I filter for my important queries and track them separately.

For a realistic timeline, see how long SEO takes. There I explain why the first months need patience.

Which crawl signals matter on a brand new site?

The Crawl stats report sits under Settings in Search Console. It shows how many requests Googlebot sends and how your server responds. Still, most people never open it. Yet on a new site, it is the earliest place to see how much attention Google gives you.

I watch three things there. First, average response time; if it climbs, your server slows Googlebot down. Second, the response code mix; 404 and 5xx shares should stay small. Third, file types; if most requests go to images and scripts, your HTML pages may wait in line.

Crawl volume on new sites is usually bumpy. So I never treat a single low day as a problem. That said, if response time keeps rising for weeks, I review hosting, because a slow server hurts visitors and Googlebot at the same time.

How do you track sitemap and internal link health?

Your sitemap tells Google which URLs matter. The Sitemaps report shows whether Google read the file and how many URLs it found. In week one after launch I want to see the status "Success".

A common problem: the sitemap still lists redirecting or noindexed URLs. That sends mixed signals. Therefore I check that every sitemap URL returns 200 and allows indexing.

For internal links I open the Links report in Search Console. Your key service pages should rank among the most linked internal pages. If they do not, adjust the menu and in-content links. I explain the method in my internal linking strategy guide.

How should you monitor Core Web Vitals after launch?

Core Web Vitals are the three metrics Google uses to measure page experience. According to the Web Vitals documentation on web.dev, good thresholds are LCP at 2.5 seconds or less, INP at 200 milliseconds or less and CLS at 0.1 or less. Google assesses them at the 75th percentile of page loads.

I watch these closely after launch because they change once the site goes live. Marketing adds a chat widget, a pixel and a cookie banner. As a result, an INP that looked green on staging can turn amber within weeks. I cover the ranking side in how site speed affects SEO.

Why do lab data and field data disagree?

Lab data comes from one test device on a fixed network. Field data, in contrast, comes from real users on real phones. That is why Lighthouse can give you 95 while the Core Web Vitals report in Search Console says "needs improvement".

On a new site, field data often does not exist in the first weeks. The Chrome UX Report needs enough visits before it shows values, and it collects data over a rolling 28 day window. So in month one you rely on lab tests. From month two, field data starts to drive decisions.

To read lab tests properly, follow the steps in my Google Lighthouse performance test guide. My routine is simple. After every major change, I run a mobile test on the homepage, one service page and one blog post. Then I log the results in a dated sheet.

Now, when a metric drops, you know which change caused it. Without that sheet, every slowdown becomes a guessing game.

What should you check in conversion data during month one?

Conversions are the reason the site exists: forms, calls, quote requests, purchases. In month one I care less about the conversion rate and more about whether conversions record at all. A low rate is a marketing problem. A conversion that never records is a measurement problem.

In practice, my check is simple. I compare form submits in GA4 with forms that actually arrive in the inbox. If the numbers differ, the tag either fires twice or some forms never arrive. I also compare both numbers with the CRM.

If you have not defined what counts as a conversion, read how to set website conversion goals first. Without a clear goal, the metric means nothing.

Early numbers stay small, so rates swing hard. Example calculation: 6 forms from 400 visits equals 1.5 percent. One extra form lifts that to 1.75 percent. I never decide on samples this small. Still, I never accept zero conversions as normal. I test tracking first, then the flow.

Why is engagement rate a better signal than bounce rate?

Bounce rate in GA4 does not mean what it meant in Universal Analytics. Google's engagement rate help page defines an engaged session as one that lasts longer than 10 seconds, has a key event or has at least two page views. Bounce rate is the share of sessions that were not engaged, so it is simply the inverse of engagement rate.

Above all, this definition matters. In the old system, a visitor who read one page and then called you counted as a bounce. Now that visitor counts as engaged, because the session passed 10 seconds. Therefore you should not compare old site reports with new site numbers directly.

In this group of website metrics I use engagement rate as the main indicator. I use bounce rate only to spot problems on specific pages. For practical fixes, see how to reduce bounce rate on a business website.

How do you interpret engagement page by page?

A sitewide engagement rate says little on its own. The real insight sits in the page and source breakdown. So in GA4 I open the landing page report with the channel dimension added.

While reading it, I ask these questions:

• Is paid traffic clearly less engaged than organic traffic?
• Is mobile engagement far below desktop?
• Why does one service page behave differently from the rest?
• Do blog readers move on to service pages?

If mobile lags far behind desktop, I test the mobile experience first. In most cases the cause is a hidden button or a popup that covers the screen. If paid traffic shows weak engagement, I suspect a mismatch between targeting and page message.

For example, if someone searches for "price" and leaves without seeing a price, the problem may lie in the promise, not the page. Mismatches like this are the fastest wins in the first 90 days.

How does the channel mix change in the first 90 days?

On a new site, most traffic usually comes from direct, social and paid channels. Meanwhile, organic search grows its share slowly. The pace depends on your industry, competition and publishing rhythm.

In GA4 I open the default channel group report and note channel shares at the end of every month. If organic share does not move at all over three months, I suspect a content or technical issue. On the other hand, a very high "direct" share usually points to untagged campaign links.

I always read shares next to absolute numbers. When ad spend rises, organic share can fall while organic visits still grow. In other words, the ratio alone can mislead you.

Why should you track mobile and desktop separately?

In many industries most visitors arrive on mobile. However, design teams often approve a site on a desktop screen. As a result, averages look fine while mobile users struggle.

That is why I always split engagement rate, conversion rate and Core Web Vitals by device. If mobile conversion sits far below desktop, something blocks users: the form, button size or speed. The Core Web Vitals report in Search Console also separates mobile and desktop by default.

I do not trust emulators alone. I browse the site on a mid range Android phone over mobile data. My full routine is in the mobile friendly test guide.

How do you catch 404s, 5xx errors and redirect problems?

Error metrics are problems visitors see but never report. Nobody emails you to say a page returned 404. Instead, they simply go to a competitor. That is why I check errors daily during the first two weeks.

I use three sources. First, the "Not found (404)" and "Server error (5xx)" groups in Search Console. Second, server access logs, which also show errors Google has not seen. Third, GA4 page views filtered by the title of your 404 page.

Also, I test redirects separately. A redirect chain, where one URL jumps two or three times, slows the page and makes crawling harder. You can check single URLs with the redirect checker.

After a fix, I press "Validate fix" in Search Console. Google then rechecks the group and reports back. Teams that skip this step keep seeing solved errors in the report for weeks.

How do you monitor uptime and outages?

Uptime is the share of time your site stays reachable. Google Analytics cannot show an outage, because the tag cannot fire while the site is down. So I set up a separate uptime monitor that checks the homepage and one conversion page every few minutes.

I also choose the alert channel early. After all, an email alert at night is easy to miss. For critical sites I prefer phone notifications. I add outage logs to the monthly report too, so you have exact dates and durations when you talk to your host.

Short outages alone do not crash rankings. However, repeated 5xx errors can make Googlebot slow its crawl rate. So I read outage data next to indexing data.

How do you spot broken forms and checkout errors?

The most expensive errors happen at the conversion step. If a form does not send, or checkout freezes in one browser, the site loses money while every other metric looks fine. Moreover, Search Console will not show these errors.

That is why I run a mystery shopper test every week for 90 days. I fill in and submit the form from a real phone on mobile data. On online shops, I go through add to cart and checkout. Then I confirm that the notification reached the right person.

I also watch the gap between form starts and form submits in GA4. Many starts and few submits usually means too many fields or confusing validation messages. My lead form design guide covers the fixes.

What does on-site search data tell you?

If your site has a search box, the words visitors type are your most honest feedback. Specifically, people search for what they cannot find in the menu. GA4 enhanced measurement records these queries automatically once you set the right query parameter.

During the first 90 days I review this list monthly. If one term repeats often, the content either does not exist or hides from the menu. For instance, frequent "price" searches on a service site suggest you should move pricing information higher. Searches with zero results go straight into the content idea list.

What should a weekly checklist look like?

The secret of steady monitoring is simple: check the same questions in the same order every week. Browsing reports at random, by contrast, wastes time. My weekly list takes no more than 20 minutes.

1. Search Console: indexed page count and any new error groups.
2. Search Console: impressions and position trend for key queries.
3. Core Web Vitals report: any URL group in "poor" or "needs improvement".
4. GA4: key event count and consistency with the CRM.
5. GA4: engagement rate by channel.
6. Uptime tool or server logs: outages and 5xx errors.
7. Mystery shopper test: form and checkout flow.

Next to each item I write "normal" or "review". After three months, the site's health history fits on one page. To build the habit of reading reports well, start with how to read a digital marketing report.

Which website metrics should trigger an alarm?

Not every dip is an alarm. Some situations, however, cannot wait. If you write them down in advance, you follow a procedure instead of panicking.

My alarm list looks like this:

• A clear weekly drop in indexed pages.
• A core service page dropping out of the index.
• A sudden rise in 5xx errors, or an outage longer than one hour.
• Key events falling to zero for a full day.
• A URL group in the Core Web Vitals report turning "poor".

Among these website metrics, the one teams miss most is conversions falling to zero. Usually a plugin update broke the tag. The team notices in the month end report, and a whole month of data is gone. That is why I set custom GA4 alerts for key events.

How should you report website metrics, and to whom?

The same numbers do not suit every reader. Developers want error and speed data. Management, meanwhile, wants conversions and cost. If one report tries to serve everyone, nobody reads it.

I use two layers. The technical layer covers indexing, errors and Core Web Vitals, and the team sees it weekly. The management layer covers leads, conversion rate and channel mix. I share it monthly on a single page.

Next to every number I add a short note: what changed, why it changed and what we will do. That turns a list of figures into a decision document.

Which decisions do website metrics support after 90 days?

By day 90 the technical health question should be closed. Instead, the open question is growth. At this point your website metrics show where to invest.

For pages with impressions but few clicks, rewrite titles and descriptions; my guide on writing meta titles and descriptions helps here. Next, for pages with traffic but no conversions, plan message and CTA changes. Finally, for topics with no impressions at all, build a content plan.

This is also the moment to pick long term indicators. Daily monitoring metrics and board level KPIs are not the same thing. I explain the difference in what digital marketing KPIs are. In short, the first 90 days lay the foundation, and the next phase builds growth on top of it.

What mistakes do I see most often after launch?

The first mistake is postponing tracking until after launch. After all, first week data never comes back. The second mistake is watching everything at the same frequency. The team gets tired and soon stops opening reports.

Another mistake is forcing different tools to match exactly. Search Console clicks and GA4 sessions count different things, so small gaps are normal. Teams also compare the old site with the new one without knowing that definitions changed.

Finally, ownership often stays unclear. The agency thinks the client is watching. Meanwhile, the client thinks the agency is. In the end nobody watches. So I write a name next to every metric group. In my own projects I cover this under SEO consulting. Whatever route you choose, name the owner from day one.

One final note: monitoring does not need to be perfect. An imperfect routine you follow every week beats a flawless dashboard nobody opens. Start small, check the same list weekly and expand when you need to.