In software development, silent errors are the most dangerous. Those that don't throw an exception, don't throw an error code and don't break execution, but simply fake the output. The case of a SEO tracker that for weeks showed incorrect data to all its users is a perfect example of how a seemingly minor change in an upstream API can cause an operational catastrophe without anyone noticing. And the worst thing is that these types of failures not only affect SEO tools, but any system that depends on third parties to obtain critical data.
The problem began when Google, without warning, removed support for the num=100 parameter in its search results. For years, SERP APIs (search engine results pages) accepted this parameter to return up to 100 organic results per query. But, at some point, the engine stopped respecting it. The APIs built on top of these services, when they received the request with num=100, simply returned a reduced set of results – usually between 9 and 10 – without throwing any errors. The code, seeing that the answer was a success (code 200) and that it contained a list, continued its logic as if everything was fine. The result: for keywords that were actually in positions 11 to 100, the system recorded 'not in the top 100'. And so, for weeks, dashboards were updated, alert emails didn't skyrocket, and no user – not even the founders – noticed the lie.
The technical lesson here goes beyond search APIs. Any integration that assumes that a parameter will remain respected forever runs the same risk. Large platforms such as Google, AWS, or Azure are constantly updating their APIs; sometimes in a documented way, sometimes silently. That's why, in Q2BSTUDIO, when developing custom applications for our customers, one of the fundamental principles is not to blindly trust any external source. We implement cross-checks, inconsistency alarms and, above all, systems that verify the reliability of the data received before using it to make business decisions.
The team behind the crawler had to redesign the paging logic. At first, they assumed that if a page returned less than 10 results, it was because there were no more. Error. In today's search results, the presence of featured snippets, knowledge panels, ads, and other interface elements mean that the first page can return only 9 organics. The real sign of an end is not a short page, but a completely empty page. This forced the implementation of pagination that iterates until a page with no results is obtained, and also adjusts the absolute positions: page 2 does not return positions 11-20, but starts again at 1. Without that calculation, the data would still be incorrect.
But cost was another issue. Verifying that a keyword is NOT in the top 100 requires scanning all 100 positions, while one that is in the top 5 is solved with a single request. Keywords not found become the most expensive, and new users often add many of them. The solution was to implement adaptive depth: if a keyword has already been evaluated and was not in the top 100, the next check only scans the first 30 positions, and once a month a full sweep is done to detect late escalations. This strategy cut the API cost in half without altering the product promise.
What's interesting about this case is that the flaw wasn't in the internal logic of the software as they had developed, but in an assumption about the behavior of an external service. This often happens in projects that integrate AWS and Azure cloud services, or any other infrastructure as a service. The long-term solution is not just to fix the code, but to incorporate a culture of monitoring based on independent sources. For example, comparing crawler data to Google Search Console data, or using a second backup API to validate metrics.
In today's business world, where decisions are made based on automated data, a silent mistake of this type can have millions of dollars in consequences. Imagine a company that uses artificial intelligence to predict demand, and the model is trained on incorrect SEO data. Or a business intelligence services system that feeds a Power BI with unrealistic figures. Trust in data is the cornerstone of any data strategy. That's why at Q2BSTUDIO we offer AWS and Azure cloud services that include data validation layers and proactive alarms, preventing these failures from going unnoticed.
Another aspect that is often overlooked is the need for AI for companies that not only automates processes, but can also detect anomalies. AI agents specialized in monitoring can compare sources, calculate deviations, and notify when an indicator is out of the expected. In the case of the crawler, once the 'execution failed' alert was implemented, the system started sending automated emails if the API was not responding correctly or if the results differed from a referral source. That simple addition turned a product that silently lied into one that warned of its own limitations.
Cybersecurity also plays a role here, even if it is not obvious. When an external API changes its behavior, it can be an attack vector if the system is not ready. A malicious actor could manipulate the returned data to fool decision algorithms. Having verification mechanisms, such as a second measurement instrument, is also a basic security practice. At Q2BSTUDIO we integrate validation protocols into all our developments, both in custom software solutions and in cloud infrastructures, to ensure that data is reliable and secure.
The epilogue of this story is revealing: when the fix was deployed, the alerts began to go off for the first time for real. One user received an email informing them that their main keyword had risen to #2. That email was the product doing exactly what it promised. But without cross-validation, that user would have continued to believe that their page was outside the top 100, missing out on business opportunities for weeks. The moral for any company that develops technology: you never assume that an API will behave as you expect. You should always have a plan B, a second sensor, and an alarm that goes off when the two sensors disagree.
If your organization is building systems that rely on external data – whether for web analytics, process automation, business intelligence services, or power bi – we invite you to review your pipelines with critical eyes. Do you have an alternative source to validate the results? Would your dashboards be lying to you without you knowing? At Q2BSTUDIO we help companies design robust architectures, with data redundancy, intelligent alarms and continuous verification processes. Because a silent mistake is unforgiving, but good engineering can catch it before it causes damage.
.jpg)
.jpg)
.jpg)