The first week of a new site: what to watch

In the first week you are checking for broken states, not for results. Four things can genuinely be wrong and can genuinely be fixed: the site is not reachable or not being crawled, code fails under real traffic in ways it never failed in staging, mail sent from the domain is not accepted, and the certificate is not set up to renew. Everything else that moves in seven days, above all positions and session counts, carries no information yet, and treating it as if it does is the most common way a healthy launch gets damaged.

The four checks worth running

Run each of these from outside your own network and outside your own resolver. The tab you had open during the build is the least reliable instrument you own.

1. Reachable and being crawled. Fetch the homepage and three deep URLs, confirm a 200 and the canonical each one returns. Then confirm the production robots.txt replaced the staging file, and check response headers for a leftover X-Robots-Tag: noindex, not just the page source. A staging directive surviving the cutover is invisible in a browser and stops indexing outright. Google publishes the exact precedence rules in its Search Central documentation.
2. Errors that only appear under load. Staging traffic is one person, one browser, warm cache, one location. Real traffic adds concurrency, cold caches, crawlers, query strings, old inbound URLs and form POSTs. Read the raw error log daily for seven days rather than a dashboard. Worker exhaustion in particular does not look like an error; it looks like a slow page, then a timeout.
3. Mail from the domain is accepted. Publishing authentication records is not the test. Send from the domain to accounts at two or three large providers and read the received headers for a pass on each mechanism. Test the site's transactional mail separately, because a contact form usually sends over a different path than your mail client does.
4. The certificate renews. The expiry date tells you nothing useful. What matters is whether the automated renewal is actually scheduled and whether the certificate covers every hostname you serve, including the apex, www, and any subdomain. Confirm that both the plain HTTP request and the non-canonical hostname land on the canonical one with a valid certificate. Coverage gaps are set out on the certificate page.

Why week-one numbers are not numbers

A new site has no history, so early reporting is measuring a queue, not a ranking. Positions reported before index coverage settles describe which pages have been seen, not how they are valued.

The arithmetic makes this concrete. Suppose a query returns nine impressions in week one: you appear once at position 8 and eight times at position 60. The reported average is roughly 54. One unusual impression next week moves that average by twenty positions without anything changing on your site. The traffic itself is you, your team, crawlers, and the people you told.

The damage comes from reacting. Rewriting titles, reshuffling internal links, blocking sections and resubmitting the sitemap every morning all restart the evaluation clock, and after three such changes you cannot attribute any later movement to any of them.

The rule: state signals versus rate signals

Act on a rate signal only when all three of these hold: the metric has at least a few hundred events behind it, the direction has persisted for four full weeks, and you can name a specific mechanism that would explain it. Two out of three is a hypothesis, so write it in the launch log with a date and revisit it next month. Keeping that dated log is what lets a later change be attributed at all, which is the same discipline the rest of launch playbooks assumes, and it is what turns a vague slowdown into something diagnostics can actually chase.