You Fixed the Site. Now Tell the Engines It Exists.

The VISIBLE-7 audit answers one question: can machines read your site? This is the sequel, and it answers a different one. Do they know it exists, and are they coming back?

Those are not the same problem, and no amount of building solves the second. The work happens on Google's and Bing's own consoles, on accounts you own, in places your deploy pipeline cannot reach.

It is not much work. It is maybe an hour once, then fifteen minutes a month. But it is the part people skip, because it does not feel like building, and because nothing visibly breaks when you skip it. The site just quietly stays unfound.

It is a common shape: good bones, no address.

The order matters, and it is not obvious

Do Google first. Not because Google is more important than the alternatives, but because it is the only one that has no automated shortcut.

There is a protocol called IndexNow that lets you ping search engines the moment you publish. It covers Bing, Yandex, Seznam and Naver. It does not cover Google. Google learns about your site through its sitemap and Search Console, on Google's schedule.

So the highest-value item is always Google Search Console, and it is always step one. IndexNow is the cheapest item, and it handles everything else automatically forever. Between them they cover the field.

Google Search Console

Add the property at search.google.com/search-console. You get two choices, and the choice matters more than it looks.

Domain property covers every subdomain and both http and https in one place. It needs DNS verification, a TXT record on the root of your domain. Choose this if you have anything beyond the apex - an app., an assistant., a staging subdomain you forgot about.

URL prefix covers only the exact prefix you enter. It verifies by uploading an HTML file or adding a meta tag, so it is simpler if you would rather not touch DNS. It is also narrower, and you will end up making several of them.

Take the Domain property. The DNS record is a five-minute job and it stops you discovering later that half your site sits outside the property you set up.

For DNS verification, Google gives you a string like google-site-verification=XXXX. Add it as a TXT record on the root - the same place your A records live. Then check it resolves before clicking verify:

dig TXT example.com +short

If you go the file route instead: the file Google hands you is an ownership token, not a secret. It is fine to commit it to your repo's public/ folder. It proves you control the site and nothing else. Confirm it is actually live before verifying, because a static host that does not copy public/ to the root will fail silently:

curl -s -o /dev/null -w "%{http_code}\n" https://example.com/googXXXXXXXX.html

Then submit your sitemap - Sitemaps in the sidebar, enter sitemap.xml, submit. Within a day it should read Success with roughly the number of URLs you expect. If the number is much lower than your route count, that is your first real finding.

Finally, use URL Inspection on your homepage and your two or three most important pages and hit Request Indexing. It is a one-time nudge to speed the first crawl. Do it once. It is not a lever you pull repeatedly.

Bing Webmaster Tools

Same shape, at bing.com/webmasters, and there is a shortcut: you can import your Google Search Console property in one click and skip verification entirely.

Bing is worth the ten minutes for a reason that has nothing to do with Bing's market share. ChatGPT search has historically leaned on Bing's index. If you care whether an assistant can find you, you care about Bing indexation, whatever you think of Bing as a search engine.

Bing also has an on-demand SEO analyzer that flags title and description problems page by page. It is more direct than anything in Search Console.

IndexNow, the part almost nobody sets up

This is the one I would fix first if you only did one thing, because the cost is so low it barely registers.

IndexNow is a protocol for telling search engines "this URL changed, come look". No account. No API key. No approval process. The entire ownership proof is a text file at your site root, named after a key you invent, containing that key.

The whole mechanism:

1. Generate a key - any hex string will do.
2. Write it to https://example.com/{key}.txt, containing the key itself.
3. On every deploy, POST to https://api.indexnow.org/indexnow with your host, the key, the key file location, and a list of URLs.

One ping fans out to every participating engine. Do not ping them individually.

Two details that matter in practice. Fire the ping after the new build is live, or you are announcing URLs that do not resolve yet. And read the URL list from your sitemap rather than maintaining it by hand, so the two cannot drift apart.

On this site it is a small script in the deploy block. It reports back like this:

IndexNow ping: 200 for 43 URLs

That is the entire integration. It runs on every deploy and I have not thought about it since.

Then re-scrape your social cards

If you changed titles, descriptions or Open Graph images, the social platforms are still holding the old ones. They cache aggressively and they will not notice on their own.

LinkedIn's Post Inspector forces a re-scrape - paste the URL and it refetches. Facebook and X have equivalents. Do this after any metadata change, or your beautifully updated card stays invisible behind a cached copy of the old one.

Part two: what to actually read

Setup is one-time. The consoles earn their keep afterwards, and there is a real risk of either ignoring them entirely or checking them daily and reading noise as signal.

A realistic cadence: every few days for the first fortnight after a launch while indexing settles, then about fifteen minutes monthly, plus a look after any significant change.

Search Console data runs two to three days behind, and a new property shows almost nothing until Google has crawled. An empty graph in week one is not a problem. It is week one.

Pages - the one that matters most

This report splits your URLs into indexed and not indexed, with a reason for each exclusion. It is the closest thing to a direct answer to "is my site in Google".

Healthy looks like: indexed count at or near your route count, and the number climbing after a launch rather than sitting flat.

Worth acting on: Crawled - currently not indexed in volume, Discovered - currently not indexed persisting for weeks, Duplicate without user-selected canonical, Soft 404, and anything reporting a server error.

Safe to ignore: Alternate page with proper canonical tag and Page with redirect. Those are the system working correctly.

The soft-404 one is worth dwelling on, because it is the most common thing I find. If your site returns a 200 status for URLs that do not exist - serving the homepage instead of a real 404 - you have created an unlimited supply of duplicate pages. Every typo, every stale link, every URL an assistant invents resolves to something. Google notices. This is genuinely common in single-page apps and it is invisible until you test for it:

curl -s -o /dev/null -w "%{http_code}\n" https://example.com/this-page-does-not-exist-xyz

That must return 404. If it returns 200, fix that before anything else in this article.

Performance - is anything showing up

Impressions climbing after launch means you are entering the index and starting to appear. That is the first real signal that any of this worked.

The Queries tab is the genuinely useful one. It shows the actual searches you appear for, which is frequently not what you assumed. If you rank on the edge for something relevant, that is a content brief writing itself.

Position is average rank. Improving is good. A sudden drop across many queries at once is worth investigating; small wobbles are weather.

Sitemaps and the rest

Check occasionally that the sitemap still reads Success and the discovered count still matches your routes. A drop means something broke in your build.

Core Web Vitals and Mobile Usability are worth an occasional look, not a monthly ritual, unless you are actively working on performance.

The one alert that genuinely matters is Manual Actions. It is rare, it means a human at Google penalised your site, and it is the only thing in these consoles that constitutes an emergency. Check it once and forget it exists.

On Bing

The IndexNow tab shows which URLs you submitted and when, which is how you confirm your deploy integration is actually firing rather than silently failing. Worth a glance after you wire it up.

The honest ceiling

Do all of this, and every technical check besides, and you reach a specific and limited place: the site no longer loses on technical grounds.

That is not the same as winning. Two levers remain, and neither is a build task or a console task.

The first is off-site presence - mentions, listings, other people's articles linking to you. This appears to be a significant driver of who gets recommended by answer engines, and none of it happens on your own domain.

The second is whether the content is worth citing. Everything in this article makes your writing readable and findable. It cannot make it worth reading.

I keep this distinction sharp because it is where the honest answer to "are we fully optimised?" lives. Yes, on everything technical. The rest was never a technical problem.

And a caveat I would rather state than have you discover: being indexed is not the same as being recommended. I have been measuring monthly what AI assistants actually name when asked who to hire in my category, and the answers churn heavily between runs. Indexing gets you into the pool. It does not get you named.

Do the work anyway. It is an hour, and the alternative is a site nobody can find, which is a much simpler problem to have and a much worse one.