After Website Launch SEO: What to Watch and Fix in the First 30 Days

The site is live, the launch checklist is done, and now there is an uncomfortable quiet. Search results do not change overnight, reports are empty, and it is hard to tell whether silence is normal or a sign of a problem. Many teams react by changing things at random, which makes any later diagnosis harder.

This guide is for owners and developers in the first month after launch. It gives you a calm routine: what to check on day one, what to read each week, what a healthy early picture looks like, and which findings deserve a fix. It assumes you have already worked through the website launch SEO checklist and have verified the site in Google Search Console.

Expect delay. Google's Search Console help says a new site or page can take "a week or so" to start being crawled and indexed, that some sites take up to a few weeks to be crawled once URLs are known, and that indexing is never instant. Its starter guide says some changes take effect in hours and others take months, and suggests waiting a few weeks before judging a change. This guide does not promise rankings, traffic or a date for indexing; it helps you spot technical faults early and avoid overreacting to normal behaviour.

Before you begin

Access: a verified Search Console property (a Domain property is the most complete), access to server logs or hosting metrics if you have them, and the baseline crawl you saved before launch.
Time: about an hour on day one, 30 minutes twice a week for the first fortnight, then 30 minutes weekly.
Risk: low if you only observe; moderate if you change redirects, robots.txt or canonicals while you diagnose. Change one thing at a time and write down the date.
Keep a log: a simple dated list of what you changed and why. It is the only way to connect a later change in reports to its cause.
Related setup: if Search Console is not set up yet, start with Google Search Console setup.

Step-by-step instructions

Step 1: Day 0 and 1 — confirm the site is open and healthy

Why: the worst launch problems are visible within hours: a block left in place, a server that fails under load, or a certificate that does not cover a hostname.

Action: re-run the smoke checks from the pre-launch QA guide. Open /robots.txt, view the source of the home page for stray noindex tags, and test a made-up URL for a real 404. Check uptime and error logs. Google reduces crawling when it meets 5xx errors or 429 responses, and only raises it again gradually once the server returns successful responses, so a server that struggles early can slow discovery. See HTTP 500 errors.

Confirm: key pages return 200, there is no unexpected noindex, and the error rate is low.

Step 2: Day 1 to 3 — submit the sitemap and inspect key pages

Why: the sitemap gives Google a list of the URLs you consider canonical, and URL Inspection shows how Google sees a page.

Action: in Search Console, open Sitemaps and add your sitemap URL. The report shows Success, Has errors or Couldn't fetch. "Discovered pages" means URLs parsed from the file; Google states there is no assurance that a discovered URL will be crawled or indexed. If the status is Couldn't fetch, read sitemap couldn't fetch. Then use URL Inspection on the home page and a handful of key templates. You can request indexing for a few important pages, but this is a request, not a command; see request indexing.

Confirm: the sitemap status is Success and URL Inspection reports the page can be indexed.

Step 3: Week 1 — read the Page indexing report

Why: this report shows which URLs Google knows about and why some are not indexed.

Action: open Indexing, then Pages. The report splits URLs into Indexed and Not indexed. Google says "Not indexed" is not necessarily bad, because it includes legitimate cases such as a robots.txt block or a duplicate. Sort the reasons by count and ask for each: did we intend this? Intended reasons (a noindexed thank-you page, a redirected old URL) need no action. Unintended ones do. Typical early findings are "Discovered, currently not indexed" and "Crawled, currently not indexed", which are explained in discovered, not indexed and crawled, not indexed. The example URL lists hold up to 1,000 items and may not show every URL, so use them as samples. For all statuses see page indexing report explained.

Confirm: every Not indexed reason is marked "expected" or "fix", with an owner.

Step 4: Week 1 to 2 — fix errors and validate

Why: unfixed errors keep costing crawl attention and trust.

Action: fix issues at the cause: a template, a redirect rule, a server setting. Then open the issue and select Validate fix. Google says validation typically takes up to about two weeks, with a notification on success or failure. Wait for a validation cycle to finish before requesting another. Do not click Validate before the fix is live.

Confirm: validation shows "Started", then "Passed". If it fails, the report names a URL that still has the problem.

Step 5: Week 2 — check crawl health and how Google reaches the site

Why: crawl data shows whether Google can fetch your pages reliably.

Action: if you have a root-level property, open Settings and then Crawl stats. The report shows total crawl requests, total download size and average response time, plus a host status summary: robots.txt fetching, DNS resolution and server connectivity. Google notes that failures fetching robots.txt can make it slow or stop crawling until it gets a usable response, and that a valid file, an empty file or a 404 counts as success while 429 and 5xx do not. The page also says sites under a thousand pages typically do not need this report, so do not worry if yours is sparse. Check the response codes breakdown: you want mostly 200 and redirects, and few 404 or 5xx.

Confirm: host status shows no recent issue, and no spike in 404 or 5xx responses.

Step 6: Week 2 to 3 — read the Performance report with realistic expectations

Why: it shows whether you are appearing in search at all.

Action: open Performance. It reports clicks, impressions, click-through rate (clicks divided by impressions) and average position, and by default shows the last three months. The most recent data can be preliminary and change within hours. Early on you will see few impressions and many unfamiliar queries. Look for patterns: which pages get impressions, which queries match your content, and whether a page you care about has none. Do not chase average position in the first weeks, because it is an average across whatever you appear for. See Search Console performance report.

Confirm: you can name your top five pages by impressions and one reason each might appear.

Step 7: Week 3 to 4 — review Core Web Vitals and real-user data

Why: field data takes time to collect, so this is the first moment it may be useful.

Action: open Core Web Vitals in Search Console. The report uses real-user data from the last 28 days, grouped by similar pages, and a group is labelled by its worst metric. The thresholds for "good" are LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less. New properties may say "No data available" while data is processed, and URLs with too little data are omitted. If a group is Poor, fix the shared template and use Start tracking; validation watches the data for 28 days. See Core Web Vitals report.

Confirm: you either have data and a fix list, or you have noted that there is not enough data yet.

Step 8: Day 30 — compare with the baseline and decide what is next

Why: a month is long enough to see the shape of problems, even if it is too short to judge results.

Action: re-crawl the site and compare with the pre-launch crawl: new 404s, changed titles, lost internal links, new redirects. Review your change log against the Search Console reports. Write a short note: what is indexed, what is not and why, what was fixed, what remains. Set the review rhythm for month two, such as a weekly check of indexing, a monthly crawl and uptime alerts. See uptime monitoring.

Confirm: the note exists and the next review dates are in someone's calendar.

Final verification checklist

Production robots.txt and key pages carry no accidental block or noindex.
The sitemap is submitted and its status is Success.
Key pages have been inspected with URL Inspection.
Every reason in "Not indexed" is classed as expected or assigned for repair.
Fixes have been validated or are in validation.
Crawl stats show healthy host status and few 404 or 5xx responses.
The Performance report has been reviewed without over-reading average position.
Core Web Vitals data has been checked, or "no data" noted.
A change log and a day-30 comparison exist.

Common mistakes to avoid

Panicking at an empty report in week one. Google says indexing is never instant.
Changing many things at once. Alter one thing, log the date, and wait.
Requesting indexing for every URL. Fix the cause of discovery problems first, such as weak internal links or slow responses.
Treating every Not indexed URL as an error. Many are intentional.
Pressing Validate before the fix is deployed. The check will fail and cost you a cycle.
Ignoring server errors. 5xx and 429 responses make Google slow its crawl.
Judging Core Web Vitals from a lab score alone. The report uses real-user data.
Forgetting the old URLs. After a replacement, keep redirects; Google suggests generally at least a year.

Frequently asked questions

How long until my pages show up in Google?

There is no fixed time. Google's help page says a new site or page can take about a week to start being crawled and indexed, and some sites take weeks. Use URL Inspection to see where a page stands.

Should I keep requesting indexing every day?

No. Request it for a few important pages after a real change, and spend the rest of your time on the causes of any indexing problems.

Is it normal to see "Discovered, currently not indexed" early on?

Yes, it can be. It means Google knows the URL but has not crawled it yet. If it persists across weeks, review internal links and server speed.

What if impressions are very low in month one?

That is common for a new site. Check that your pages are indexed and relevant to real queries, and keep publishing useful content. The report cannot tell you when results will come.

Official references

Next step: See how Crawvix checks a website and capture a baseline once scanning opens. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.