IndexNow for Static Sites: Submit New Posts After a Coolify Deploy

Static sites are easy to host, but they do not automatically tell search engines when a new HTML file is live. A sitemap helps. RSS helps. Internal links help. IndexNow adds one more useful signal: after a page is actually deployed, the site can notify participating search engines that a specific URL changed.

This is the workflow I use for a small static HTML blog deployed from GitHub through Coolify to an nginx container. It is deliberately conservative. IndexNow is treated as a discovery ping, not as a substitute for good pages, crawlable links, valid feeds, or deploy verification.

Short version: publish the page, verify it is live, verify RSS and sitemap, then submit only the canonical changed URLs through IndexNow.

What IndexNow does and does not do

The IndexNow documentation describes a simple protocol: host a key file on the site, then send changed URLs and the key location to a participating endpoint. The key file proves that the caller has control of the host. The submitted URL tells the search engine what changed.

That is useful for a static blog because a new post is just a file. There is no CMS plugin quietly pinging anything in the background. But it is still only a notification. It does not guarantee ranking, indexing, crawling frequency, or traffic. Google’s sitemap guidance is a useful reminder that discovery systems work best when the site also has clean canonical URLs, sensible links, and valid XML discovery files.

The static-site checklist before submission

For this kind of blog, I only submit a URL after these checks pass:

1. The new post exists as a committed HTML file.
2. The homepage links to the post with the canonical path.
3. feed.xml contains a new item with the same URL.
4. sitemap.xml contains the URL and a current lastmod.
5. The page has a canonical tag, Open Graph metadata, Twitter metadata, and Article JSON-LD.
6. The Docker image builds locally.
7. The Coolify deployment has finished.
8. The production URL returns 200 and the live HTML contains the expected title.

The order matters. If a deploy fails and the IndexNow ping goes out anyway, the submitted URL may point to yesterday’s site. That is noisy and unnecessary.

Where the key file lives

IndexNow uses a text key file on the host being submitted. For a static nginx site, that can be a small .txt file copied into the web root with the rest of the site:

https://example.com/<indexnow-key>.txt

The file has to be reachable over HTTPS. Do not put secret operational material in it. The IndexNow key is a site-verification token, not a mailbox password, API token, deploy key, private key, or server credential. It can be public because crawlers need to fetch it, but the rest of the deployment credentials should never be mixed into the static web root.

Submit the changed URL, not the whole internet

For a one-post update, the changed URLs are usually:

• the new article URL,
• the homepage, because it now links to the post,
• the RSS feed,
• the sitemap.

That is enough. A small site does not need to resubmit every old post on every deploy. Submitting only changed canonical URLs keeps the signal clean and makes the workflow easier to audit.

A safe command shape

The specific key value is deliberately not shown here. The useful shape is a JSON request that names the host, the key, the hosted key-file location, and the canonical URLs that changed:

curl -sS -X POST 'https://api.indexnow.org/indexnow' \
  -H 'Content-Type: application/json' \
  --data '{
    "host": "example.com",
    "key": "<indexnow-key>",
    "keyLocation": "https://example.com/<indexnow-key>.txt",
    "urlList": [
      "https://example.com/posts/new-static-site-post.html",
      "https://example.com/",
      "https://example.com/feed.xml",
      "https://example.com/sitemap.xml"
    ]
  }'

In automation, the same pattern should read the key from a local environment variable or a protected deployment setting, print only the HTTP status, and avoid logging the raw key.

How this fits with Coolify

Coolify is the deployment boundary. GitHub can say the commit exists, and Docker can say the image built, but production is not updated until the Coolify app is running the new container. That is why my static-site deploy checklist verifies the live page, RSS, sitemap, and assets before any discovery ping.

The practical sequence is:

write post
update index, RSS, sitemap, llms.txt
git commit and push
Coolify deploy
fetch live page and discovery files
submit IndexNow URLs

That keeps the source of truth in Git, the running site in Coolify, and the discovery ping at the end where it belongs.

Why it helps organic growth

IndexNow will not rescue thin content or make a private note rank. Its value is more boring and more useful: it reduces the chance that a genuinely helpful new page waits unseen for longer than necessary. For a small technical blog, that means practical posts about Docker Mailserver, Coolify, Cloudflare DNS, privacy-friendly analytics, and static-site operations get a clean path from source file to discoverable public URL.

The growth lesson is simple: write something worth finding, publish it cleanly, make it crawlable, then notify discovery systems after the live site proves the page exists.