In most projects launch day is a moment of celebration: the link gets shared, the team congratulates itself, the file is closed. Three weeks later a different sentence starts going round the same team — "the site is live, but we don't show up on Google." That sentence is usually the result not of an error but of a gap: nobody wrote a plan for after launch.
Turkish-language sources are full of pre-launch checklists. What has been written about the period after launch mostly repeats one pattern: lists in the "7 reasons your site isn't showing up" mould, with no order and no timeline. A sequenced measurement plan — what to look at on day one, which question to answer in week one, which decision to make at the end of week four — sits outside that content.
What follows lays out the first thirty days after launch as a calendar. The aim is not to list problems; it is to set down which problem can be understood in which week, and which finding triggers which fix.
Launch is not the finish line; it is where measurement starts
When a new site goes live, two things are true at once: the technical work is done, and nothing has been proven yet. Pages loading, forms working and the search engine seeing the pages are three independent states; the first does not guarantee the second, and the second does not guarantee the third.
That is why the first thirty days are not a maintenance period but a verification period. The questions to verify, in order, are: is the page actually reachable, can the search engine get in, does it index the page it reaches, which queries is the indexed page shown for, do impressions turn into clicks, and do clicks turn into enquiries.
The order matters, because a problem near the top of the list makes everything below it meaningless. There is no point debating the click-through rate of a page that is not in the index. The plan for the first thirty days follows this same order.
One expectation needs correcting here: what you have at the end of these thirty days is not performance but the ability to diagnose. A new site's position in search results settles over time, and how long that takes depends on the size of the site, how competitive the topic is and how deep the content goes — it cannot be known in advance. The honest sentence you can say after thirty days is this: either a technical obstacle is still there, or it is not.
The first 24 hours: six checks that prove what works
The checks done on day one form the basis for every measurement that follows. Six of them are mandatory, and all can be finished within a few hours.
Do the pages load at the right addresses? Every address in the page plan is requested one by one. If this was a redesign, the old addresses need checking as well; we wrote in detail about how that work is run in our article on protecting rankings during a site redesign.
Is there a single preferred address? There should be one choice between www and the bare domain, and between the secure connection and the old protocol; if both routes serve the same content, a single page stays live under two addresses.
Has the indexing block been lifted? Blocking lines left over from the test environment are the item most often overlooked, and the one with the largest impact. Both robots.txt and the page-level tags get checked.
Is the content in the page source? The text you read on screen also has to be present in the page's raw source. If the text is generated entirely on the client side, anything that reads the page without running scripts never sees part of the content. How this check is done, and why it is a decision at the infrastructure level, is covered in our small business website infrastructure guide.
Is the measurement code working? Does the analytics setup show your own visit in the real-time report?
Has the sitemap been submitted? The new sitemap is submitted to the search console. The reason it comes last in the sequence is this: a site that gets crawled in its broken state keeps your fixes waiting to be reprocessed.
Week one: how to read indexing
Week one has a single subject: indexing. The search console's indexing report is the main screen for the week, and there are three states to read.
"Not crawled yet." The search engine knows the address but has not visited it. This is expected on new sites and usually resolves with time. If a large number of addresses stay in this state for weeks, look at the internal linking structure: a page that no other page links to stays in the background even if it is in the sitemap.
"Discovered – currently not indexed." The address is known and waiting its turn to be visited. This state is not an error notice and on its own does not point to anything that needs fixing. If it persists across many pages for a long time, two possibilities stand out: the site's crawl priority is low, or a large number of pages with similar content have been produced.
"Crawled – currently not indexed." The search engine has seen the page and chosen not to index it. This is the only state that calls for a look at the content side. The page may be too short, it may be nearly identical to another page, or it may not answer a question on its own.
There is also something not to do this week: checking the report every day and trying to read conclusions into fluctuating numbers. The indexing report runs with a delay; a meaningful reading comes from a trend over several days.
Are the forms actually arriving: an end-to-end submission test
On new sites this is the quietest and most expensive failure. The site works, visitors arrive, a form gets filled in, a thank-you message appears on screen — and the email reaches nobody. No one complains, because the visitor assumes the message went through.
The test has to be end to end. The form should be filled in not by someone on the team but from an outside address, and the spam folder should be checked alongside the inbox. That the reply-to address comes through correctly, that attachments arrive and, if there is an automatic thank-you email, that it goes out too, should each be confirmed separately.
The second check is on the delivery side. In most setups form emails go out through a sending service, and if the domain's authentication records are missing, messages can end up in spam. Confirming these records on launch day beats having a "we're not getting any enquiries" argument three weeks later.
The third check is on the measurement side: is a form submission being recorded as a conversion? If it is not, the question of which page generates enquiries stays unanswered in the weeks that follow.
Phone and messaging links belong to the same test: is the number right, does it start a call on mobile, does the messaging link go to the right account.
404 and soft 404: which errors are really errors
After launch it is normal for addresses to pile up in the error report; not all of them are errors that need fixing. Drawing the line removes a lot of needless work.
A real error: an address that existed on the old site and received visits or external links, now leading nowhere. These go back into the mapping table and get redirected.
Not an error: requests for addresses that never existed. Automated crawlers constantly try paths that are not there; seeing them in the error report does not indicate a problem.
A separate category — soft 404: the server returns a success response even though the page displays a "not found" message. This tells the search engine the page exists and leads to empty pages getting indexed. The check is simple: when a non-existent address is requested, the status code that comes back must genuinely be an error code.
The habit to build this week is splitting the error report into two columns: to redirect and to ignore. When the split is made in writing, the same argument about the same addresses does not repeat in the months that follow.
Week two: lab data versus field data in speed testing
Speed is left for week two, because optimising speed while indexing problems remain breaks the order.
The one conceptual distinction you need here is this: lab data is a measurement taken in a controlled environment with a single simulated device and connection. It gives instant results and shows what is slowing things down. Field data is measurement collected from the devices of the people who actually visit your site; it reflects the real situation but takes time to build up.
On a new site there is no field data at first, and if visit volume is low it may not appear for a long time. That is not a fault. The job in week two is to close the obvious problems with lab measurement — large images, late-loading fonts, unnecessary scripts — and wait for field data to accumulate.
The second subject of week two is whether crawlers can actually get into the site. The server or a security layer may block some crawlers, and that block does not always show clearly in the indexing report. We wrote up how to test this directly, and how to read the results, step by step in our article on whether AI bots can reach your site.
Week three: which page gets impressions for which query
In week three the search console's performance report starts carrying meaningful data. The real task here is not to look at rankings but to read the match.
The method: list the pages with the most impressions, look at which queries each page is shown for, and compare that with the sentence in the page plan that says "this page answers this question". Three kinds of finding come out.
The match is right. The page is shown for the family of questions it was written to answer. There is nothing to do; the page is left to time.
The match has drifted. The page is shown for queries that were never targeted. Sometimes that is an opportunity — the content holds a demand nobody had noticed — and sometimes it is a sign that the page's topic is blurred.
The wrong page is being shown. If the home page or an unrelated page comes forward for a question, the page meant to answer that question is either not distinct enough or has not received enough links from within the site.
The same week is the first time you can look at the relationship between impressions and clicks. For pages that get impressions but no clicks, the first place to look is the page title and description: does the text shown in the search result say what the page actually answers?
Week four: what the first round of fixes covers
Week four is when the list built up over three weeks of observation gets worked through. The scope of the fix round is kept narrow on purpose; changing everything at once makes it impossible to measure what worked.
The items that belong in the round are usually these: grouping unindexed pages by cause and expanding the ones with thin content, giving links to pages that receive no internal links, sharpening the titles and introductions of pages whose match has drifted, redirecting addresses that return real errors, and closing the obvious speed problems found in lab measurement.
There is also an item that should not go into the round: fundamental changes to page structure and addresses. Changing addresses a month after launch resets an index record that has not settled yet. If an address change is needed, the reason has to be strong and the change made in one go.
The last task at the end of this week is to record the changes made, with their dates. Without that record, finding the reason behind a shift in the second month comes down to guesswork.
What you should be able to answer after 30 days
What should not be expected at the end of day thirty is a performance table. What should be expected is a clear answer to these five questions:
- How many of my pages are indexed, and why are the rest not?
- Do my enquiry channels — form, phone, messaging — work end to end?
- Which page is shown for which family of questions, and does that match my page plan?
- Is there a technical obstacle that has not been closed?
- What are next month's content and fix priorities?
If these five questions have answers, the first month has done its job. The direction the answers point in usually sets the subject of the second month too: if the technical side is clean, the work shifts to content depth; if it is not, that gets closed first.
Measuring visits from AI assistants as a separate channel also comes up at this point; we covered how to set it up and where that measurement stops in our article on measuring AI traffic. You can see how the first month after launch is run within our service scope on our corporate website service page; if you would like to review your site's post-launch state together, write to us.
Frequently Asked Questions
How long does it take for a new website to be indexed?
There is no reliable timeframe to give, and any statement that offers one is a guess. Indexing varies with the search engine's crawl priority, the size of the site, how the pages link to one another and whether the content answers a question on its own; even two pages on the same site can be indexed at different times. What you can do is not predict the timing but monitor the process: tracking which category each page falls into in the indexing report lets you separate real obstacles from states where you simply need to wait.
Does submitting a sitemap speed up indexing?
A sitemap is not an accelerator but a notification tool: it regularly tells the search engine which addresses make up the site and when they were updated. Its benefit shows mostly on pages that are hard to reach through internal links or have only just been added. But submitting a sitemap does not guarantee that a page will be indexed; once the page has been crawled and assessed, the search engine decides whether to index it. Generating the sitemap correctly matters too: it should not contain addresses that redirect, return errors or are closed to indexing.
If there is no traffic, is the problem the site or the content?
The distinction is made in order. First, access: are the pages indexed? If not, the problem is on the technical side and changing the content will have no effect. If they are indexed, the second question is impressions: is the page shown for any query at all? If there are no impressions, the question the page answers is either too narrow or the page does not answer it distinctly enough. If there are impressions but no clicks, the problem most likely lies in the title and description shown in the search result. A verdict of "the content isn't good enough" reached without checking these three steps in order is usually premature.
Should we keep adding content right after launch?
Yes, but with the priorities set correctly. In the first month, watching whether existing pages get indexed and how they match tells you more than producing new pages; that observation also shows which topics are missing. There is one exception: if pages that have a place in the page plan did not make it in time for launch, finishing them is not worth putting off. What to avoid is producing lots of similar pages before measurement has started — growing the inventory without seeing which approach works makes the clean-up later expensive.
Which measurement tools are mandatory and which are optional?
Two items can be treated as mandatory: a search console property and a web analytics setup. The first is the only source that shows how the search engine sees the site — indexing, impressions, query matching — and no other tool can stand in for it. The second shows what visitors do on the site and which page enquiries come from. Anything beyond these is optional: a tag manager makes life easier for those who want to manage the measurement setup without touching code, and reviewing server access logs comes in when crawler behaviour needs confirming. Whichever tools you install, creating the properties under the business's own account is a separate and important matter.