Five hundred tracked keywords, and what archiving one frees
A cap on tracked keywords is a read-cost decision, not a licence tier. Here is why 500, what archiving actually frees, and why there is no delete.
Market4 allows 500 live tracked keywords per app, and archiving one frees a slot immediately. The count is of non-archived rows only, so an archived keyword costs nothing against the cap while its record of having once been a goal stays. Trying to track a 501st comes back as a plain refusal: at most 500 keywords can be tracked per app, archive one to make room. There is no delete anywhere in the keyword surface — archive is the retirement, and it can be undone.
The cap on tracked keywords exists because of how one particular read behaves, not because of a pricing tier. The report that answers "is the page we chose the page Google actually ranks" fans out over every live keyword in a single pass: it asks Search Console for one report, joins every tracked keyword against it, and then looks up the target pages. Bounded at 500, that read stays two database queries plus one API call. Unbounded, it becomes a read whose cost is set by whatever somebody pasted in last week.
A cap chosen this way lands in a specific place: far past any list a person actually maintains by hand, and low enough that the report behind it stays cheap. That is a different design from a quota meant to sell an upgrade. It also explains why the refusal names the remedy — archive one to make room — rather than pointing at a plan page.
Archiving a tracked keyword frees the slot and nothing else. The row stays. The rank history stays, and it stays for a structural reason: every stored SERP of a query is filed under a fingerprint built from the query and its locale, not under the keyword row, so the history was never the row's property to lose. That is why the product can offer archive and restore instead of delete, and why nobody has to think about whether retiring a keyword throws away six months of measurements. It does not.
| Action | Counts against the 500 | Row survives | Rank history survives |
|---|---|---|---|
| Tracking a keyword | Yes | Yes | Accumulates from here |
| Archiving it | No | Yes, marked archived | Yes — filed under the fingerprint |
| Restoring it | Yes again | Yes | Yes, and rejoins the same series |
| Deleting it | Not available | Not available | Not available |
The same words tracked for two countries are two records with two rank histories. That is the design, not a duplicate — country, language, location and device are part of what a tracked keyword is.
Market4 turns one release note into a changelog page, a blog post, a mail-out and a week of social posts — and then tells you which of them brought anyone back.
Restoring an archived keyword can be refused, and the reason is worth knowing before you rely on archive as an undo button. If the same question has been tracked again in the meantime — same words, same country, same language, same location, same device — the restore would create two live rows with one identity, so it is refused instead. Archive is reversible, but only while nobody has taken the place back.
Two tracked keywords are the same record when their whole identity matches, and the identity is more than the words. It is the query plus the country, the language, the free-text location and the device. The same phrase tracked for the United States and for Germany is two rows against the cap on purpose, because those are two different rankings and merging them would average away the thing you wanted to see. The words themselves are normalised first: trimmed, lower-cased, and runs of inner whitespace collapsed to one space, so a pasted double space cannot silently create a second record.
Tracking the same identity twice while it is live is refused rather than deduplicated, and the message names the query and its locale so it is obvious which of your five near-identical entries collided. This is also why the target page is the sole editable field on a tracked keyword: the rest of the fields build the fingerprint that every stored SERP is filed under, so editing one would quietly re-point the record at a rank history that was never measured for it. The supported repair for a wrong one is to archive it and track the right one.
A small site will not run out of 500 keyword slots by tracking the queries it writes for, so the cap is only ever a problem for a list that grew by accident. The lists that hit it are usually built from an export: every query with an impression, every autocomplete suggestion, every variant of one question. A tracked keyword is a commitment to notice something — if nobody would change a page over its movement, it is taking a slot from a query somebody would.
Five hundred live keywords per app. The count is taken over non-archived rows only, so archiving frees a slot straight away. Attempting to track another one past the limit returns a validation error reading "At most 500 keywords can be tracked per app — archive one to make room". The limit is per app rather than per organisation, so two apps under one account each get their own 500.
No. Every stored SERP snapshot is filed under a fingerprint built from the query and its locale rather than under the keyword row, so the history is not the row's to delete. Archiving marks the row retired and frees its slot; the measurements stay exactly where they were, and a restored keyword rejoins the same series it left.
There is no delete. Archiving is the only retirement, deliberately: it frees the slot so the same question can be tracked again, while keeping the record that the query was once a goal. Since the rank history lives under the fingerprint rather than the row, deleting would destroy the evidence of a decision without freeing anything the archive does not already free.
Because the identity may have been taken back. A tracked keyword is identified by its query together with its country, language, location and device, and two live rows cannot share one identity. If the same question was tracked again after you archived it, restoring the old row would create that duplicate, so the restore is refused and the newer row stays. Archive the newer one first if you want the original back.
The keyword text, country, language, location and device together build the fingerprint that every stored SERP of that query is filed under. Editing one would re-point the record at a rank history that was never measured for the new identity, without any visible sign that it had happened. The target page is the one field outside that fingerprint, so it is the one field that can safely change.
Publishing writes to a database and tells search engines about an address. Preflighting is the step that asks the server answering that address whether it serves a page. What to check, which findings block an announcement, and why the check must never fail a publish.
Search Console's regex filters are RE2 expressions, which is a deliberately smaller syntax than the one most regex tutorials teach. What RE2 leaves out, what to write in place of each missing construct, and the two things a filter does not change.