TL;DR: If you're pushing updates to a static site every week, manually notifying search engines is a waste of time. GitHub Actions can detect exactly which files changed in each commit, convert those paths to URLs, and submit them to IndexNow automatically. You build once, push to main, and search engines get notified within minutes - no batch uploads, no forgotten submissions, no resubmitting 388 URLs when only three changed.
If your static site gets a dozen updates a week, manually notifying search engines gets old fast. Most builders either skip the submissions entirely or batch them monthly, which means new pages sit invisible for weeks.
GitHub Actions combined with IndexNow solves this. Your repo already knows what changed, and search engines support instant notifications. You just need to wire them together.
Here's the real difference: instead of pushing code and then remembering to notify Bing or Yandex later, you build a workflow that detects changed files, waits for your deployment to finish, and submits only the modified URLs. No manual script runs. No forgotten submissions. No resubmitting all 388 URLs when only three changed.
This article walks through what GitHub Actions does, how IndexNow works, and how to set up submissions that fire on every push to main.
What GitHub Actions Actually Does
GitHub Actions is GitHub's built-in automation system. You write a workflow file, drop it in .github/workflows/, and GitHub runs it whenever a trigger fires. Common triggers include pushing code, opening a pull request, or hitting a cron schedule.
For static sites and micro-tools, this becomes a deployment and notification engine. You can:
- Run a build step when you push to main
- Detect which files changed in the commit
- Convert those file paths into live URLs
- Wait for your hosting platform to finish deploying
- Submit only the changed URLs to search engines
The key advantage: GitHub already has the commit diff. It knows exactly which pages you modified. You don't need to scan your entire sitemap or keep a separate change log.
Run on Every Push
The most common trigger is push to a specific branch:
yaml
on:
push:
branches:
- main
Every time you merge a PR or push directly to main, the workflow fires. This matches how most teams deploy: main is production, and every merge should trigger a deployment notification.
For teams managing multiple repositories with similar automation needs, GitHub repository best practices covers how to structure .github/ folders, share workflows across repos, and maintain consistency when scaling to dozens of projects.
Detect Changed Files
GitHub Actions can extract the list of modified files from the commit diff. The official IndexNow Action supports multiple input modes:
- urls-from: generate URLs from a shell command (like parsing the diff)
- file: read URLs from a text file you generate in an earlier step
- sitemap: submit URLs from an existing XML sitemap
- urls: pass a direct list of URLs as a string
For changed-file workflows, urls-from is cleanest. You run a command that outputs one URL per line, and the Action reads that output.
Example shell logic on macOS or Linux:
bash
git diff-tree --no-commit-id --name-only -r HEAD | \
grep 'index\.html$' | \
sed 's|^|https://yourdomain.com/|' | \
sed 's|/index\.html$|/|'
This grabs modified files, filters for index.html entries (assuming each page is a folder with an index file), and converts paths into full URLs.
On Windows with PowerShell, you'd use native cmdlets instead:
powershell
$changedFiles = git diff-tree --no-commit-id --name-only -r HEAD
$urls = $changedFiles | Where-Object { $_ -like '*index.html' } | ForEach-Object {
$_ -replace '^', 'https://yourdomain.com/' -replace '/index\.html$', '/'
}
$urls -join "`n"
Both produce the same output: a list of URLs, one per line, ready to feed into the IndexNow Action.
Submit URLs to IndexNow Automatically
The IndexNow Action handles the actual submission. It supports five search engines:
- Bing
- Yandex
- Naver
- Seznam
- Yep
IndexNow submissions are shared across all supporting engines. You submit once, and Bing tells Yandex, Naver, Seznam, and Yep about the update.
The Action supports multiple feed formats:
- XML sitemaps
- RSS feeds
- Atom feeds
- Direct URL lists
- Custom endpoints
For changed-file workflows, direct URL lists are simplest. You pass the output of your diff command and let the Action batch the submissions.
If you're building workflows for rapid deployment and want to see how to structure automation logic around changed files and deployment hooks, check out building your first automated workflow step for a deeper dive into event-driven automation patterns.
The Action also supports limits (submit only the first N URLs), time filtering (submit only URLs modified since X days ago), and custom key file locations.
Example workflow snippet:
``yaml
- name: Submit changed URLs to IndexNow uses: bojieyang/indexnow-action@v2 with: sitemap-location: 'https://yourdomain.com/sitemap.xml' key: ${{ secrets.INDEXNOW_KEY }} key-location: 'https://yourdomain.com/indexnow-key.txt' ``
This submits URLs from your sitemap. For changed-file workflows, you'd replace sitemap-location with urls-from and pass your diff command.
Run on a Schedule
You can also trigger workflows on a cron schedule:
yaml
on:
schedule:
- cron: '0 2 * * *' # 2 AM UTC daily
This is useful for submitting your full sitemap once a day, even if nothing changed. Some builders use this as a safety net: changed-file submissions run on every push, and a daily full-sitemap submission catches anything the diff logic missed.
Use Secrets for Keys
GitHub Actions supports encrypted secrets. You store your IndexNow key in repository settings under Secrets and variables, then reference it in your workflow as ${{ secrets.INDEXNOW_KEY }}.
This keeps the key out of your public repository. The workflow file itself is visible, but the key value is encrypted and only decrypted during workflow runs.
Generate Key Files Dynamically
The official IndexNow docs warn against committing your key file to a public repository. If the file is visible in your repo, anyone can see the key contents.
The recommended approach: generate the key file during deployment. Your hosting platform writes the key to disk as part of the build step, so it's available at https://yourdomain.com/indexnow-key.txt but never committed to version control.
Most static site hosts support build hooks or environment variable injection. You can write a simple script that creates the key file from a secret environment variable during the build process.
What You Get
A typical static site might have 388 URLs total but only 3 changed URLs per update.
With this workflow in place:
- Every push to main triggers the workflow
- GitHub extracts the diff and converts changed paths to URLs
- The IndexNow Action submits only those URLs to all five supported search engines
- Search engines crawl the updated pages within hours instead of weeks
- You never manually submit a URL again
Traditional sitemap-based indexing can take days or weeks. IndexNow reduces this to hours. Sites that receive a dozen updates per week benefit the most, because each batch of changes gets notified immediately instead of sitting in a queue until someone remembers to submit them.
Common Mistakes to Avoid
Submitting the entire sitemap on every push. This works, but it wastes API quota and makes it harder for search engines to prioritize your fresh content. Only submit what changed.
Forgetting to wait for deployment. GitHub Actions can't detect deployment completion automatically. If your workflow submits URLs before your hosting platform finishes deploying, search engines will crawl stale versions. Add a delay step or poll your deployment status endpoint before submitting.
Committing your IndexNow key to a public repo. Use GitHub Secrets and generate the key file dynamically during deployment. Never hardcode the key in a workflow file or commit it to version control.
Assuming Google supports IndexNow. Google does not. You need a separate notification mechanism, either through the Search Console API or by updating your XML sitemap and pinging Google's submission endpoint.
Why This Matters for Static Sites
Static sites change frequently in small batches rather than all at once. You publish a new blog post, fix a typo on three pages, add a new product page. Each of these events is a small diff.
Most static site builds finish in under 60 seconds. That means your workflow can detect changes, wait for deployment, and submit URLs within two minutes of pushing to main.
This kind of speed doesn't matter for sites that update once a month. But if you're shipping updates every few days, the difference between manual batch submissions and automatic change detection is the difference between pages that index in hours and pages that sit invisible for weeks.
You build the workflow once. After that, every push to main handles its own search engine notifications. No manual steps. No forgotten submissions. No wasted API quota on unchanged URLs.
📦 Publishing Kit — Dev.to
Title Options (5)
Selected: Auto-Submit Changed Pages to Search Engines with GitHub Actions and IndexNow
Alternates:
- Stop Manual Search Submissions: Automate IndexNow with GitHub Actions
- GitHub Actions + IndexNow: Submit Only Changed URLs to Search Engines
- How to Auto-Notify Search Engines When You Push Static Site Updates
- Automate Search Engine Notifications for Static Sites with GitHub Actions
Slug
auto-submit-changed-pages-search-engines-github-actions-indexnow
Tags
webdev, devops, tutorial, indexnow
Top comments (0)