Connect Indexing Status to Airtable

For a list of URLs, read back what Google has on record from your indexing notifications — when each was last submitted, and whether it was an update or a removal.

Coming soon — join the list to get early access

What you can pull from Indexing Status

Indexing Status exposes 1 object you can pull, each as its own job. Every run will pull the records into a flat table, so nested fields arrive as ordinary columns that Airtable can sort, filter and total without further work.

URL notification metadata

What Google recorded for each URL you have notified it about. Reading status costs no publish quota, so this is the safe half of the pair.

Columns returned by url notification metadata
ColumnTypeNotes
urlstring
latest_update_typestring
latest_update_timedatetime
latest_update_urlstring
latest_remove_typestring
latest_remove_timedatetime
latest_remove_urlstring
notify_statusstring
notify_errorstringPopulated only when the lookup failed for that URL

Options you can set

urls
The URL list to read status for

How it lands in Airtable

Airtable accepts append, upsert writes. Upsert is the one that matters on a schedule: it merges on a key you choose, so matching rows are updated in place and only genuinely new records are created. Append instead, and a daily job multiplies your data.

Upsert merges on up to three key fields. Matching records are updated in place; only genuinely new rows are created.

  • At most 3 merge fields - Airtable rejects more.
  • Writes go 10 records per request, at 4 requests per second by default (Airtable’s own ceiling is 5) - roughly 2,400 records a minute.
  • typecast is on by default, letting Airtable coerce strings into select, number and date fields rather than rejecting the write.
  • unknown_fields defaults to error, so a renamed source column fails loudly instead of silently dropping data. Set it to skip if you would rather drop.

Authentication

You connect Indexing Status once through OAuth and the credential is stored server-side, never pasted into a cell or a formula. Only the scopes the connector actually calls are requested — the table below lists each one and what it is for.

What Indexing Status is asked for

indexing sensitive
Covers both publishing notifications and reading their status
userinfo.email non-sensitive
Label the connection

Keeping runs incremental

Not for this source: Each run reads status for the URLs you give it. Where that is expensive, narrow the job itself and run it less often.

Pair a narrowed read with an upsert write and a re-run costs almost nothing: the rows it already knows are updated, and nothing is duplicated. That combination is what makes a frequent schedule affordable.

Common gotchas

Most of what goes wrong with a scheduled sync is not a bug — it is a detail of how one side behaves that nobody wrote down. These are the ones that come up for this pair.

This reports your notifications, not Google’s index

It reads back what you told Google and when. It does not tell you whether a page is actually indexed or ranking - Search Console is where that question belongs.

Verified ownership is required, and is a separate grant

The connecting account must be a verified owner of the site in Search Console. That consent is distinct from the Search Console reporting connector, so you will authorise twice.

Do not key an upsert on email

People change their email address. When they do, upsert cannot match, so it creates a second record - the exact duplicate you were trying to prevent, plus a stale one. Use a stable ID from the source system.

The key field has to be written

If you restrict which columns get written and the key field is not among them, there is nothing to match on and every row is treated as new.

A row that is a fact per period needs a compound key

For a daily history, one row is one entity per day. Key on the entity alone and each day overwrites the last, leaving no history at all.

Set it up in four steps

  1. 1

    Connect Indexing Status

    Connect a Google account that is a verified owner of the site in Search Console. This is a separate grant from the Search Console source - different scopes, different consent - so the two connections cannot be shared.

  2. 2

    Connect Airtable

    Connect your Airtable account once, then pick a base and table.

  3. 3

    Shape the data

    Select the columns you want, filter rows, cast types and add computed fields. Everything else is dropped before it reaches the destination.

  4. 4

    Schedule it

    Run once, or on a cron. Every run refreshes Airtable with the latest Indexing Status data.

Do I need an add-on or extension for this?

No. The job runs server-side and writes into Airtable through its API, so there is nothing installed in the destination itself. It keeps running when nobody has the file open, and a copy of the file does not need anything installed to work.

How often does the data refresh?

On whatever schedule you set with a cron expression — hourly, daily, or a specific time on specific days. Each run pulls the latest from Indexing Status.

Do I need to write any code?

No. You connect both sides, map the fields in a wizard and set a schedule. Computed fields accept small expressions — abs, round, min, max, len — but there is nothing to host or maintain.

How do I stop duplicate records appearing?

Use upsert rather than append, and key it on a stable identifier from the source. Append creates new records every run, so a daily job leaves seven copies of every row by the end of the week.

How fast can it write?

Airtable accepts 10 records per request, and writes are paced at 4 requests a second by default against a ceiling of 5 - roughly 2,400 records a minute. That is comfortable for thousands of rows and worth planning around for hundreds of thousands.

When will Indexing Status be available?

Indexing Status is built and waiting on verification. Join the early-access list and we will let you know the moment it opens.