On August 12 we published a post about duplicate job postings. Its headline number was simple: we held 16,559 postings, and once you merged the copies there were 9,247 actual jobs. Its worked example was Speechify: 1,768 postings that collapsed into 8 roles, with one title appearing 361 times across 221 locations.
On September 16 we went back through our older posts to put a date on every figure, and re-ran that measurement the same way. 16,018 postings. 12,726 roles. Speechify: 1,218 postings, 1,134 roles.
Same method, roughly the same number of postings, and about 3,500 more "jobs" than five weeks earlier. A jump that size, with that little change in postings, pointed at our counting rather than the market. It was our counting.
This is what went wrong, what it touched, and how we fixed it. It is a small bug with a long tail, and we would rather you hear about it from us.
Why we merge postings at all
A lot of companies post one role many times. Same title, same team, one posting per city, sometimes dozens. If we counted every posting, the board would say we had thousands of jobs we do not have, and you would scroll past the same role over and over.
So every job title gets a collapse key: a cleaned up version of the title, and postings that share a key at the same company count as one role. That key drives the number on the job board, the job count on each company page, and the totals our agent search returns.
Cities glued onto titles
Somewhere between mid-August and mid-September, a lot of titles started arriving with the location glued onto the end:
Software Engineer, Platform - Vilnius, Lithuania
Software Engineer, Platform - Tel Aviv, Israel
Software Engineer, Platform - Stockholm, Sweden
To a human those are obviously one role. To the collapse key they were three different titles, so they became three different jobs. On September 17, 3,407 active postings across 286 companies carried a location in the title.
We still have not pinned down exactly when titles started arriving this way, or whether it was the boards or something on our side (honest answer: we found it by its effects, not its cause, and the fix does not depend on knowing).
What it touched
More than we would like:
The job count on the board and on company pages ran high. Speechify's page said it had over a thousand open roles.
The totals our agent search returns ran high too, including on the keyless search we had just opened up.
The location filter could not find 907 of those postings, because their city lived only in the title and their location field was empty.
And our blog. Three older posts told readers the opposite of what was true about which unit a number was in, and our August duplicates post no longer reproduced.
Nothing about the postings themselves changed. We were counting some of them several times.
Stripping a location, carefully
The collapse key now strips a trailing location, but only when it really is a location: the tail has to end in a country or a US state. That rule sounds simple and was not.
Our first version accepted too much. It would have merged "Software Engineer - Backend, Remote" with "Software Engineer - Frontend, Remote", which are two different jobs. Review caught that before it shipped. We then listed every tail the new rule would strip across all 16,020 active postings. There were 367 distinct ones, and exactly three were not addresses ("Enterprise, Georgia" among them, which is a business segment, not a state). The final rule carries a list of business words like that one, so it leaves them alone.
When it went live on September 17 it changed the key on 1,315 postings across 36 companies. Measured afterwards: 16,020 postings, 11,688 roles. Speechify went from 1,134 roles to 15.
The part that could have hurt search
Merging roles means some job pages disappear. About 1,240 job URLs stopped resolving. When we checked a sample of 30 in Google Search Console, 7 were indexed (and 7 more came back without a status). Letting those turn into 404s would have thrown away pages Google already had.
So a merged URL now redirects to the surviving role. The first version of that redirect had a nasty edge case: two different roles whose titles slugify to the same thing could send one role's old URL to the other role's page, permanently. A second review round found it before prod (we ran two different reviewers, and each caught something the other missed). Now, if an old URL could plausibly belong to more than one role, it stays a 404 rather than guessing. A wrong redirect is worse than a missing page.
Numbers on the blog
We decided the blog publishes the same unit the board shows: distinct roles, not raw postings, with the date the number was taken. If you can open the board and roughly reproduce a figure, the figure is doing its job.
Older posts keep their numbers at their own dates. Where a post measured postings, it now says so, rather than silently swapping in a different number.
A test we did not know we had
The bug was invisible in the product. Every page rendered, every search returned results, and the numbers were plausible. What exposed it was a blog post with a dated figure that stopped reproducing five weeks later.
Which is a slightly funny way to find a data bug, and also the best argument we have for publishing numbers with dates on them. They double as a test.
If you have seen a job count on Remoet that looked off, before or after September 17, tell us in Discord. We would much rather hear about the next one from you than from ourselves in five weeks.
