---
title: "Automatic indexing: send new pages to Google on every deploy"
description: "Get new and updated pages indexed without a manual step. Watch your sitemap, add one step to CI, or let your AI agent submit pages as it publishes them."
canonical: "https://indexmysite.app/automatic-indexing"
language: "en"
---

# Submit new pages to Google automatically

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.

[Start indexing](https://app.indexmysite.app/signup)[Choose a setup](#setup)

## Choose how pages get submitted

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.

### Watch your sitemap

No code. Best for blogs, docs, and marketing sites.

1.  Create a project and add your sitemap or sitemap index.
2.  Choose to skip the pages already in it, so only new pages are sent.
3.  Optionally limit it to paths like `/blog/` or `/docs/`.
4.  Turn on **Submit new URLs automatically**.

### What happens next

-   We read the sitemap every six hours.
-   A URL that was not there before is new, and new URLs are sent as a job, up to your limit (100 by default).
-   A page you have already submitted is never sent again by the watch.
-   Each page is searched for in Google after 24 hours and reported in the project.

### Submit after each production deploy

Best when pages live in your repo and deploy from main.

1.  Create an API key in Settings, then Connections, and save it as the repository secret `INDEXMYSITE_API_KEY`.
2.  Save the workflow as `.github/workflows/index-pages.yml`. It runs when your host reports a successful production deploy.
3.  Change the `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}"
```

### One command at the end of your pipeline

Best for custom pipelines and programmatic pages.

-   Run it after your deploy finishes, with one URL per line in `urls.txt`.
-   The CLI reads your API key from `INDEXMYSITE_API_KEY`, so it needs no sign-in in CI.
-   Prefer plain HTTP? The `curl` call does the same thing from any language.
-   Up to 2000 URLs per job. Split bigger releases into several jobs.
-   The idempotency key makes a retried step safe.

```
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 .)}"
```

### Make it part of your agent’s release routine

Best when an agent writes or ships your pages.

1.  Connect the [MCP server](https://indexmysite.app/indexing-mcp-server) to Claude Code, Cursor, Codex, or another client.
2.  Add this rule to AGENTS.md or CLAUDE.md.
3.  Ask your agent which pages are indexed the next day.

```
## 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.
```

## Which pages to submit, and when

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.

When to submit a page for indexing
| 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 |

## Set it up

[

### Indexing API

Send any public URL with one API key. Build a request in curl, JavaScript, or Python.

](https://indexmysite.app/indexing-api)[

### MCP server for agents

Claude Code, Cursor, and Codex can submit pages and report results as they publish.

](https://indexmysite.app/indexing-mcp-server)[

### Sitemap watch docs

Filters, limits, and what counts as a new URL, step by step.

](https://indexmysite.app/docs/projects#watch-a-sitemap)[

### Indexability checker

Free check for robots rules, noindex tags, and thin content before a page goes out.

](https://indexmysite.app/tools/indexability)

## Frequently asked questions

### Doesn’t Google find new pages on its own?

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.

### How often does the sitemap watch check?

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.

### Will automatic submission spend credits without asking?

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.

### What happens if CI submits a page that is not live yet?

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.

### Can a retry in CI charge me twice?

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.

### How do I know it worked?

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.

## Start submitting pages automatically

Create an account, buy credits from $25, and set up a sitemap watch or a CI step in a few minutes.

[Start indexing](https://app.indexmysite.app/signup)

[See pricing](https://indexmysite.app/pricing)