Building a content & growth platform from scratch

Summary

Content arrived weekly in spreadsheets and was uploaded by hand. Structured data (colleges, courses, exams, cutoffs) went in through raw CSV uploads that created duplicates and broken pages. I led the build of a platform where one validated data layer powers every page, tool and SEO surface. It includes a CMS with validation and audit trails, templated pages, student decision tools, and technical SEO designed in from the start.

Context

Students choosing a college move through Discover → Explore → Compare → Evaluate → Decide. Established players (Shiksha, Careers360 and others) already own this search space. A new entrant cannot win with more articles alone. It wins with better-structured information, connected into journeys, at a scale that search engines can index.

The problem

• Publishing was manual. Articles were shared weekly in sheets and uploaded by hand. That meant delays, formatting errors, and dependency on a few people.
• Data was unsafe at scale. Direct CSV uploads created duplicate articles and malformed data, and nothing stopped bad data from going live.
• Pages were islands. Content, college data and tools weren't connected, so a student reading about an exam had no path to cutoffs, predictors or comparisons.
• SEO was an afterthought. With hundreds of thousands of potential URLs, crawl budget, canonicals, internal linking and performance had to be product decisions rather than post-launch fixes.

Options considered

• Speed up the spreadsheet workflow

  Quick win, but publishing would still depend on people and bad data would still reach the site. Rejected: it optimizes the wrong process.

• Adopt an off-the-shelf headless CMS

  Fine for articles, but weak for relational education data (college ↔ course ↔ exam ↔ cutoff) and bulk validation. We'd have ended up building the hard part anyway.

• Build a CMS + structured-data layer designed for templates and SEO

  Chosen

  Higher upfront investment, but one data layer could feed every page type, tool and schema markup, and validation could happen before anything went live.

What we built

I owned discovery, competitor analysis, information architecture, CMS design, prioritization and technical SEO strategy, working with engineering, content, SEO and business teams.

1. A CMS that is a product, not an admin panel. It manages articles and structured data, with bulk uploads that pass format checks, duplicate detection and error flags before publishing.

2. User-level activity tracking. Every change records who changed what, and when. When something broke, we fixed the process that caused it, not just the page: issue → trace → root cause → fix workflow → prevent recurrence.

3. One data layer, many experiences.

• College data → college pages → comparison → evaluation
• Exam data → exam pages → calendar → cutoffs → predictor
• Course data → course pages → course finder → comparison

4. Student decision tools. College and course discovery, side-by-side comparison, exam calendar, exam and college cutoffs, college predictor, course finder, mock tests, and a personal dashboard.

5. Templated pages at scale. Data → template → page → internal links → search discovery → user journey. New page types launched by adding data, not by writing pages.

6. Technical SEO as architecture. Crawlability, indexation rules, URL design, redirects, metadata, canonicals, schema markup, internal linking, sitemaps, robots.txt, and continuous audits. Performance was built into templates, not fixed at the end.

Trade-offs

Results

Monthly sessions (2025–26)

Traffic grew 3.6× from January to the June peak. The Jul–Aug dip came from a full website revamp in those months: URLs, templates and page structures all changed at once, so rankings reset temporarily. It coincided with the end of the admission season. Traffic was already recovering by September.

Structured, templated page types were driving real traffic, not just articles:

Other results:

• PageSpeed Insights of 75+ mobile / 90+ desktop on key templates, at 300K+ pages.
• Content processing went from ~4 hours to ~10 minutes, with validation instead of manual checking.
• Duplicate-content issues from raw CSV uploads were largely eliminated through validation before publishing.

What I learned (and what I'd do differently)

• I brought the lessons from Collegedunia with me. I had seen what goes wrong when content, data and SEO grow separately. This time I talked to multiple users directly before planning, and designed the information architecture to be easy to understand and to scale from day one.
• Stage big migrations. The July–August revamp changed URLs, templates and page structures at once. Next time I'd roll out section by section, with rollback criteria, to shrink the dip and make it easier to diagnose.
• Instrument the funnel, not just sessions. Sessions show discovery. I would track compare → predictor → lead conversion per page type from day one to prove which tools drive business value.

If I built this today with AI

• AI-assisted structured data entry. Extract college, fee, cutoff and eligibility data from official PDFs and notices with an LLM using structured outputs, validated against the schema the CMS already enforces. A human approves anything with low confidence.
• Content QA agent. Flag outdated dates, contradictions with the structured data ("article says the fee is X, the data layer says Y"), and missing internal links before publishing.
• Conversational predictor. "Which colleges can I get with rank 12,000 in JEE Main?" answered from our cutoff data with citations, not from the model's memory.

How I'd evaluate it: field-level extraction accuracy on a labeled set of 200 documents, factual-consistency rate against the data layer, citation coverage, cost per page updated, and latency. The non-negotiable is that no AI-generated number goes live without passing the same validation a human upload would.