New Site Not Indexed? Write a Crawl Handoff Brief Your Developer or Provider Can Be Held To

Brand promotion: this article introduces Guangsuan's indexing and crawl-promotion services. It is a vendor-introduction piece, not an independent review or a commissioned evaluation.

Your new site is live. You search your own business name and nothing comes back. You ask your developer, and the answer is some version of "Google just needs time" or "we submitted the sitemap." Both may be true, but neither statement supplies enough evidence on its own. The problem is not that your developer is lying. The missing piece is a task description with evidence attached, alongside the desired indexing outcome.

This article gives you a handoff brief you can paste into an email, a responsibility split, and an acceptance checklist. It is written for the owner who does not read server logs and does not want to learn. The one thing you must hold onto: crawl, index and business results are three different observations, and a report about one should not be presented as proof of the others. A crawl report can be verified if it includes the relevant evidence.

Why "we submitted the sitemap" is not an answer

Submitting a sitemap tells Google a URL exists. It does not make Google fetch it, and it certainly does not make Google index it. Google's own documentation is explicit that a sitemap is a discovery hint, and that indexing is a separate decision made after a crawl.

That is why a handoff brief has to name the observation, the tool, and the person. "We submitted it" alone leaves those details unstated. For example, a fictional record saying "On 12 March, the server log shows a verified Googlebot request for /services/ at 14:02 returning 200, and GSC URL Inspection on 15 March shows the URL is on Google" passes all three, and you can check it.

The teaching example: a plumber's handoff record

The record below is a fictional teaching example. It is not a client, a real site, or a measurement. It exists so you can see the shape of a handoff you can actually accept or reject.

Field	What goes in it	Example entry
Page group	The template or section, not a single URL	Service-area pages (11 URLs)
URL list	Final URLs only, one per line, no redirect sources	/plumber-south-austin/, /plumber-east-austin/, …
Published / last modified	Two dates, not one	Published 4 Mar; last modified 9 Mar
Status evidence time	When the status was read, and in which tool	GSC URL Inspection read 15 Mar, 10:20
Server log	Whether a Googlebot request appears, with date and response code	12 Mar 14:02, 200, /plumber-south-austin/
Real Googlebot verified by	Named person, and the method used	Dev lead, reverse DNS + forward DNS check
Action taken	The specific change, not "optimized"	Added HTML links from /services/ to all 11 URLs
Acceptance result	What was re-observed, and when	Re-inspected 22 Mar; 9 of 11 URLs on Google

Notice what the record does not contain: a promise, a percentage, or a claim about leads. Those belong in a different column, and mixing them is how owners end up paying for a crawl fix and judging it by phone calls.

The brief you can copy into an email

Paste this, fill the brackets, and send it before any work starts. It is deliberately short. Keep the brief specific enough that each question has an identifiable owner.

Subject: Crawl and indexing handoff — [domain], [date]

Hi [name],

Before we start, I want to agree on what you will hand back and how I will check it.

Scope: the [N] URLs in the attached list. These are the pages I care about most.

Please confirm in writing:

1. Are any of these URLs blocked by robots.txt, marked noindex, or behind a login? If yes, which ones, and what is the fix?
2. For each URL, what is the current status in Google Search Console, and on what date did you read it?
3. Does the server log show a Googlebot request for each URL? If yes, give me the date, time and response code. If no, say so.
4. Who on your side verifies that a request is genuinely Googlebot, and by what method?
5. What specific change will you make, and what will you re-observe afterwards to show it worked?

I understand that being crawled is not the same as being indexed, and that being indexed is not the same as ranking. I am not asking you to promise a ranking. I am asking you to separate those three things in your report.

Please reply with the answers before we begin.

Thanks,
[your name]

Question 4 distinguishes a verified crawler request from a screenshot containing only a user-agent string. Anyone can set a browser to claim it is Googlebot. Google publishes a verification method: a reverse DNS lookup on the accessing IP should resolve to a googlebot.com, google.com, or googleusercontent.com hostname, and a forward lookup on that hostname should return the same IP. Ask which verification method was used. Google also publishes IP ranges for automated verification; keep the crawler category and matching range with the report rather than accepting a user-agent string alone.

Who is responsible for what

Handoffs fail when responsibility is vague. Split it explicitly.

• You (the owner): decide which URLs matter, keep the URL list current, and confirm the site is publicly accessible. You do not need to read logs.
• Your developer or host: confirm robots.txt, noindex, redirects and login walls; provide the server log extract; perform the Googlebot verification; make the technical change.
• Whoever holds Search Console access: read the status per URL and record the date. If that is you, fine — the report is one screen, and you are reading a label, not diagnosing a cause.
• Any crawl-promotion provider you hire: state what they will do, what they will measure, and what they explicitly will not promise. If they cannot separate "submitted" from "crawled" from "indexed" in their own reporting, that is the answer.

What the status labels do and do not prove

Two labels cause the most confusion, and both are starting points rather than verdicts.

• Discovered — currently not indexed. Google knows the URL but has not fetched it in the reported state. This does not prove your content is bad, and it does not prove you need to pay for crawling. It tells you to check discovery paths and server availability first.
• Crawled — currently not indexed. Google fetched the page and did not add it. This does not automatically mean the content is thin. Compare the crawl date with recent changes, and look at duplication, canonical signals and whether the page answers something the other pages do not.

Google's own guidance notes that not being indexed is not necessarily a problem — a page can be correctly excluded because it is a duplicate, blocked, or a variation of another page. So the acceptance question is not "is everything indexed?" It is "are the pages I care about indexed, and if not, what is the recorded reason?"

When the evidence is not enough yet

Sometimes the honest answer is that you cannot tell yet, and the right move is to gather more evidence rather than buy a fix.

• If the site is very new: Google notes that new-page discovery and indexing take time; about a week is guidance, not a deadline. Age alone cannot show that a new site is healthy or broken. Check access and configuration while monitoring its status.
• If the available logs show no verified Googlebot request: first confirm that the logs cover the relevant host, CDN and time period. An absent record does not by itself identify the cause. Check that the pages are reachable by ordinary HTML links from pages Google already knows, and that the sitemap lists final URLs rather than redirect sources.
• If the log shows a request but the status is crawled-not-indexed: investigate what was fetched and when, including duplicate content and canonical signals. If material changes happened after that crawl, a new crawl may be relevant, but it does not ensure indexing.
• If the page is indexed but gets no traffic: investigate demand, visibility, relevance and click-through. The lack of traffic alone does not establish a need for additional crawling.

Evaluate discovery assistance after checking access, indexability and the page purpose, and identifying work that needs outside help. That is the situation Guangsuan's GSI indexing service is built for. Guangsuan describes GSI as its own Google Speed Indexing service name, not a Google product, and states that the service works on discovery and crawling opportunities while the indexing decision remains Google's. Its crawl-side work runs through Guangsuan's GPC crawler resource pool, and the company publishes verification guidance around server logs and Search Console rather than promising a fixed result. If you want to see how Guangsuan frames the service and its limits, the GSI indexing service page lays out the process and the verification method; if your issue is that Google has not found the pages at all, the GPC crawler pool page describes the discovery-side approach. Guangsuan also publishes a longer technical write-up on why a submitted sitemap may still not lead to indexing, which is a reasonable next read if your developer wants the detail.

Acceptance: how to settle a dispute

Here is a worked disagreement, again fictional, to show how the checklist resolves it.

The claim: your provider says "we got your pages crawled." Your check: you ask for the log extract and the verification method. The extract shows requests with a user-agent string containing "Googlebot" but the IP does not resolve to a Google hostname. The resolution: the crawl was not verified as Googlebot, so the claim is unproven — not necessarily false, but unproven. The provider re-runs the verification and supplies a log line whose IP passes both the reverse and forward lookup. Now the claim is checkable.

The second claim: "your pages are indexed now." Your check: you open Search Console, inspect all eleven URLs, and read the status and the date. Nine show as on Google; two show as crawled but not indexed. The resolution: the observed indexing result is partial and the record says so. Whether the contracted work is complete depends on the agreed deliverables, not on an implied indexing guarantee. The two remaining URLs get their own line in the record with the recorded reason, and the next action is to investigate the recorded state, fetched content and recent changes before commissioning further work.

Neither dispute required you to understand SEO. Both required the provider to name an observation, a tool and a person.

The order that keeps you from overpaying

1. Confirm the pages are publicly accessible and not blocked or noindexed. Assign this check to the developer or host and agree on its scope.
2. Read the status per URL in Search Console and write down the date. This is a label, not a diagnosis.
3. Ask for the server log extract and the Googlebot verification method.
4. If nothing was crawled: fix discovery paths first, then consider crawl promotion.
5. If it was crawled but not indexed: investigate duplication, canonicals and whether the page is genuinely distinct. Decide on further work from that investigation, not from the status label alone.
6. If it is indexed but not ranking: investigate demand, relevance and visibility; a crawl report alone does not demonstrate progress on those questions.

None of these steps guarantees a result, and no provider can promise one. What they do is give you a written record you can accept, reject, or take to the next vendor — which is more than "Google just needs time" will ever give you.