The Challenge
Growing search visibility for a BFSI platform with over a dozen dynamic financial products — each requiring compliant, accurate schema markup — without creating an engineering bottleneck. The initial approach was to add JSON-LD snippets manually per product page, but this had three problems: inconsistency across pages (different schema versions for the same product type), schema that became stale as product details changed, and zero scalability for new product launches.
The platform was also using Schema.org types incorrectly in places — the MobileApplication schema was missing key properties (applicationCategory, operatingSystem, aggregateRating), and the Organization schema had hardcoded values that had drifted from the live product. Google Search Console was flagging rich result errors, but the source of truth was unclear because schema lived in multiple templates.
The Solution
The answer was a centralised, modular JSON-LD architecture — a single schema layer that could be configured per page via PHP variables, rather than edited per template. This mirrors how design systems work: define the structure once, then compose instances.
Schema architecture design
I mapped all page types to Schema.org types first, before writing a line of code:
- Homepage → Organization + WebSite + ProfilePage
- Product pages → FinancialProduct (with FinancialService sub-type per product) + WebPage
- App pages → MobileApplication + WebPage
- Blog/Article → Article + WebPage + BreadcrumbList
- Category/Listing → CollectionPage + WebPage
Modular PHP includes
Each schema type became a PHP function accepting an array of parameters. The homepage would call render_organization_schema($org_data); a product page would call render_financial_product_schema($product_data). Product-specific variables (name, description, provider, feesAndCommissions, offers) were set at the top of each page file and passed into the schema layer — keeping content and schema in sync by design.
FinancialProduct schema implementation
The most complex component was FinancialProduct — a Schema.org type not heavily documented with BFSI-specific implementation examples. I used a combination of the official specification, Google's structured data guidelines for financial products, and reverse-engineering what Google was already showing in rich results for competitor BFSI pages. Key properties implemented: feesAndCommissionsSpecification, annualPercentageRate (for FD products), offers (with priceSpecification for processing fees), and eligibleRegion.
Automated validation
I added a lightweight CI step: before any product page deploy, a Python script fetches the canonical URL, extracts JSON-LD blocks, validates them against the Schema.org specification using the schemaorg library, and posts a Slack notification with pass/fail status. This caught three schema regressions in the first quarter — before they reached production.
The Outcome
Within six weeks of rollout, Google Search Console showed rich result impressions appearing for product pages that had previously generated zero rich result data. Organic CTR on product landing pages improved by an average of 14% month-on-month over the following quarter, attributable primarily to rich snippet eligibility in SERPs. New product page launches went from requiring manual schema work (2–3 days of back-and-forth with engineering) to deploying with schema on day one.
The framework also had an unexpected benefit: because schema now lived in one place, updating the brand name, logo URL, or contact details across every page on the site became a single file edit rather than a find-and-replace across 40+ templates.
Tools & Stack
Schema.org · JSON-LD · PHP includes architecture · Google Rich Results Test · Search Console Rich Results report · Python schema validation · Slack webhook CI notifications