Send every new page to Google as soon as it goes live. Watch your sitemap, add one step to your deploy, or let your AI agent do it. Each page reports back when it is indexed.
Every setup does the same thing: checks each URL, sends it to Google, searches for it, and reports the result. You can use more than one. A URL already in progress is never charged twice.
No code. Best for blogs, docs, and marketing sites.
/blog/ or /docs/.Best when pages live in your repo and deploy from main.
INDEXMYSITE_API_KEY..github/workflows/index-pages.yml. It runs when your host reports a successful production deploy.sed line so file paths map to your page URLs.name: Index changed pages
on: deployment_status
jobs:
index:
if: >-
github.event.deployment_status.state == 'success' &&
github.event.deployment.environment == 'Production'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 2
- name: List pages added or changed in this deploy
run: |
git diff --name-only --diff-filter=AM HEAD~1 HEAD -- content/ \
| sed -E 's#^content/(.*)\.mdx?$#https://example.com/\1#' > urls.txt
cat urls.txt
- name: Submit them for indexing
env:
INDEXMYSITE_API_KEY: ${{ secrets.INDEXMYSITE_API_KEY }}
run: |
[ -s urls.txt ] || exit 0
npx -y indexmysite submit --file urls.txt --name "Deploy ${GITHUB_SHA::7}"Best for custom pipelines and programmatic pages.
urls.txt.INDEXMYSITE_API_KEY, so it needs no sign-in in CI.curl call does the same thing from any language.export INDEXMYSITE_API_KEY="..."
npx -y indexmysite submit --file urls.txt --name "Release $(date +%F)"
curl -X POST https://indexmysite.app/api/indexing/jobs \
-H "Authorization: Bearer $INDEXMYSITE_API_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: release-$(git rev-parse --short HEAD)" \
-d "{\"urls\": $(jq -R . urls.txt | jq -s .)}"Best when an agent writes or ships your pages.
## Indexing
After you publish a new public page, or make a significant update to one,
submit its URL with the indexmysite MCP server (submit_urls).
Put every URL from the same release in one job named after the release.Submit new pages and pages with big changes. Skip small edits: Google says repeat requests for the same page do not make it crawl faster.
| Question | Submit it? | Best route |
|---|---|---|
| A new public page | Yes, as soon as it is live | Sitemap watch, CI, or your agent |
| A big update: new pricing, features, or a rewrite | Yes, so Google sees the current version | CI or your agent. Sitemap watches only send pages they have not sent before. |
| A typo fix or small edit | No | Google will pick it up on its next normal visit |
| Drafts, staging, and pages behind a login | No | Google cannot index them, so the checks skip them without charging |
Eventually, through links and your sitemap. On a newer or larger site that can take days or weeks, and some pages sit as discovered but not crawled. Submitting each page when it goes live gets Googlebot to it now, and you get a report on whether it was indexed.
Every six hours, or straight away when you choose Check now. Pages already in the sitemap when you start are recorded and not sent unless you choose them, so turning it on does not resubmit your whole site.
Only if you turn on Submit new URLs automatically for a sitemap. Each read then sends at most your limit (100 by default). If one read finds more, for example after a site move, those URLs wait for you. Every URL goes through the checks before sending and uses a credit only if it is sent.
Each URL is opened before it is sent. Error pages, redirects, and noindex pages are skipped and not charged, and the skip reason is in the job. Trigger the step after your production deploy succeeds, as in the GitHub Actions example, and you will rarely see it.
Not if you send the same Idempotency-Key header with the API, or pass the CLI request ID back with --request-id. A repeated request returns the original job. A URL that is still in progress from an earlier job is also skipped without charge.
We check every URL once after 24 hours. Your full report follows around day 5, with final checks around day 14. Each job shows every URL with its status in the app, the API, the CLI, and over MCP. A URL confirmed as not indexed after the final check gets its standard credit back.
Eventually, through links and your sitemap. On a newer or larger site that can take days or weeks, and some pages sit as discovered but not crawled. Submitting each page when it goes live gets Googlebot to it now, and you get a report on whether it was indexed.
Every six hours, or straight away when you choose Check now. Pages already in the sitemap when you start are recorded and not sent unless you choose them, so turning it on does not resubmit your whole site.
Only if you turn on Submit new URLs automatically for a sitemap. Each read then sends at most your limit (100 by default). If one read finds more, for example after a site move, those URLs wait for you. Every URL goes through the checks before sending and uses a credit only if it is sent.
Each URL is opened before it is sent. Error pages, redirects, and noindex pages are skipped and not charged, and the skip reason is in the job. Trigger the step after your production deploy succeeds, as in the GitHub Actions example, and you will rarely see it.
Not if you send the same Idempotency-Key header with the API, or pass the CLI request ID back with --request-id. A repeated request returns the original job. A URL that is still in progress from an earlier job is also skipped without charge.
We check every URL once after 24 hours. Your full report follows around day 5, with final checks around day 14. Each job shows every URL with its status in the app, the API, the CLI, and over MCP. A URL confirmed as not indexed after the final check gets its standard credit back.
Create an account, buy credits from $25, and set up a sitemap watch or a CI step in a few minutes.