Case study

A listed Indian stockbroking platform

Seven months of search engineering on a high-velocity Indian stockbroking platform — news sitemap architecture, phishing-flag remediation, and a crawl-rate collapse traced to recurring server errors.

Fintech & capital marketsIndiaSeven-month engagement
Reporting periodResults cover six months of reporting; the engagement ran for seven months.
Executive summary

What this engagement was

A stockbroking platform publishing at news velocity was losing search visibility to problems that had nothing to do with content quality. Two workstreams ran in parallel: sustaining a high-volume editorial output across business and market categories, and diagnosing the technical faults — a domain safety flag, recurring server errors, and a metadata defect on a templated page type — that were suppressing how much of that output search engines could actually reach.

Client
A listed Indian stockbroking platform
Sector
Stockbroking & financial news
Location
India
Engagement
Search engineering retainer
Period
Seven months
Workstreams
News SEO · Technical SEO
The problem

What was going wrong

The platform publishes short-lived news across several financial categories every day, alongside a large estate of templated stock pages. Both halves of that estate were underperforming in ways the editorial team could not fix from the CMS: the news content was not being picked up at the speed its shelf life required, and the stock pages were losing impressions despite no change in their content.

Financial news has a freshness window measured in hours. An article that is discovered a day late has lost most of its value — which makes indexing speed a commercial concern rather than a housekeeping one. At the same time, the domain had been flagged by antivirus and firewall vendors as unsafe, a condition that suppresses trust signals well beyond the immediate symptom.

Diagnosis

What we established

The reported symptom is frequently two layers above the cause. These are the findings that shaped the work.

Discovery was slower than the content's shelf life

News articles were being submitted through the same general sitemap as the rest of the estate. That gave crawlers no signal that these URLs were time-critical or short-lived, so they competed for crawl attention with permanent pages that had no such urgency.

A domain safety flag was distorting trust signals

Multiple antivirus and firewall engines had marked the domain as unsafe after a phishing report. The immediate user-facing symptom was a warning interstitial, but the more material effect was on how search infrastructure assessed the domain.

Recurring 5xx errors were throttling crawl

Server errors were occurring at a consistent point in the daily cycle, alongside unplanned downtime. Intermittent 5xx responses teach a crawler that the host is unreliable, and the documented consequence is a reduced crawl rate — which compounds the first problem directly.

A templated metadata defect was suppressing a whole page type

Stock pages were rendering incorrect or incomplete metadata. Because the defect was in the template rather than in individual pages, it affected the entire page type at once, and impressions fell across all of them rather than on a subset.

Engineering approach

How we worked

Including the sequencing decisions, which are usually where the work succeeds or has to be repeated.

  1. Separate the time-critical estate

    Specified a dedicated news sitemap so that short-lived articles carried an explicit freshness signal, distinct from the permanent estate. This is an architectural change to discovery rather than a submission tweak — it tells the crawler what kind of content it is looking at.

  2. Diagnose the errors with evidence, not guesses

    Instrumented the failure window and raised it with detailed logs and timestamps rather than a general report of instability. A recurring error at a consistent hour is a far more actionable bug report than an intermittent one, and it is what let the development team find and fix the cause.

  3. Restore domain trust methodically

    Reviewed the flagged elements, removed the triggers, submitted removal requests, and validated the domain across the major antivirus databases rather than assuming a single submission would propagate.

  4. Fix the template, not the instance

    Documented the stock-page metadata defect with enough specificity for the development team to correct the meta structure at source. Correcting the template restored the page type in one change.

  5. Keep the editorial pipeline running

    Technical remediation ran alongside sustained publishing, so visibility work was not paused while the platform was being repaired.

Implementation

What was built or changed

Scope of work, grouped by area.

Discovery architecture

  • Dedicated news sitemap specification for short-lived articles
  • Freshness signalling separated from the permanent estate
  • Crawl-path documentation for the editorial workflow

Reliability engineering

  • Timed failure-window instrumentation
  • Detailed 5xx logging raised to the development team
  • Server response stabilisation to restore consistent crawling

Domain trust remediation

  • Flagged-element review and removal
  • Removal requests across antivirus and firewall vendors
  • Validation across major security databases

Indexation recovery

  • Stock-page template metadata audit
  • Meta-structure correction at template level
  • Post-fix impression monitoring by page type
Technical challenges

What made it difficult

The technical and operational constraints that shaped the work.

Correlation is not attribution

Impression and click growth occurred across a period in which many things changed — editorial volume, publishing cadence, platform stability and security posture. The honest position is that the technical work removed specific, identified impediments; it is not possible to isolate each metric's precise contribution.

Security remediation crosses organisational boundaries

Clearing a flag across multiple independent vendors is not a single action. Each database has its own reassessment process and timeline, and progress is not linear.

Two teams, one critical path

Several of the most consequential fixes depended on the client's development team rather than on us. The engagement's output was therefore as much documentation and severity communication as it was direct implementation.

Results

What the work produced

Across the six-month reporting window the platform published more than eight thousand curated articles across major business and market categories. During that window the site recorded 225 million impressions and 1.52 million clicks; the news section alone accounted for 92.6 million impressions and 1.04 million clicks of that total. The more durable outcomes are structural rather than statistical: a discovery architecture that treats time-critical content as a distinct class, documented closure of the major template-level indexing defects, and a domain that no longer carries a safety flag across the major security vendors.

Figures

Measured outcomes

Measured outcomes from the engagement.

225Msitewide impressionsSix months
1.52Msitewide clicksSix months
92.6Mnews-section impressionsSix months
1.04Mnews-section clicksSix months
8,000+news articles curatedFour-plus categories, daily
60+issues reported; all major issues closed
What changed

The lasting difference

Durable structural change rather than a one-off improvement — which is what a client is actually buying.

  • Time-critical news content is now a distinct discovery class with its own sitemap, rather than competing with permanent pages for crawl attention.
  • Server errors are instrumented with timestamps, turning an intermittent stability complaint into a reproducible bug report.
  • The stock-page metadata defect was corrected at template level, restoring an entire page type in one change.
  • The domain was cleared across the major antivirus and firewall databases, removing a trust penalty that had nothing to do with content.
  • A defect register exists, with severity and resolution state, so future issues are tracked rather than rediscovered.

Have a system with a similar problem?

Tell us what it is doing. The diagnosis is usually the part that has been missing.