CampusPrep case study: RGPV papers for 67,000 a month
How CampusPrep serves over 220,000 page views a month to RGPV B.Tech students: free to read without an account, 570 subjects, fast pages on cheap phones and patchy networks, and an SEO structure built around how students search.
Divyansh Shukla7 min read
CampusPrep is a study site for B.Tech students at RGPV, the technical university of Madhya Pradesh. It brings together the syllabus, previous-year papers, notes and important questions for 570 subjects, from first year to eighth semester, with subject analytics and a personal workspace for students who want one.
Cloudflare reports 224,275 page views and 67,297 unique visitors in the 30 days from 22 September to 21 October 2026, with a busiest single day of 16,216 unique visitors, and about 772,000 page views since the site launched in late January 2026. Those are Cloudflare's counts, which can include some automated traffic, but the shape is clear: a lot of students, arriving in bursts around exams, mostly from search, mostly on phones.
This post covers the product decisions behind that and the engineering that supports them.
The problem
RGPV material is scattered. Syllabus PDFs sit on the university site, papers circulate as photos in WhatsApp groups, and notes live in whichever folder a senior shared last year. A student the night before an exam wants one thing: the right document for their branch, semester and subject, quickly, on the phone in their hand.
That framed every decision. The audience is large, impatient, price-sensitive and on mid-range Android phones with mobile data that comes and goes.
Product decisions
1. No sign-up wall for the material students came for
The syllabus, unsolved previous-year papers, notes, short notes and important questions are readable without an account. An account adds things that genuinely need one, such as the personal workspace.
This was not the original design. An earlier version asked visitors to log in to read most documents, and the analytics showed the cost: the login page was the most common page people entered on and the most common page they left from. Visitors who arrived from Google on a document were being bounced to a sign-in form, and most of them left.
Two changes followed. Free material became readable straight away. And where something does need an account, a visitor now gets a short page that explains what the document is and offers one clear "free account" action, instead of a bare redirect to a login screen. The login and sign-up links keep the page the visitor came from, so they land back where they started.
2. Structure the site the way students search
Students do not search for "AD-306". Search Console showed queries such as "rgpv 5th sem syllabus", "rgpv 4th sem syllabus cse" and "rgpv compiler design syllabus": ordinal semesters, branch abbreviations and subject names.
So the URL tree and page titles follow that: university, branch, semester, subject, then the resource type (syllabus, previous-year papers, notes, important questions). Titles use the words students type, "4th Semester", the subject name and its code, "Syllabus", "Previous Year Papers", and are fitted to 60 characters, with descriptions held under 158, so search results do not cut off the important part. Semester pages print every subject's syllabus unit by unit, and branch pages list every subject year by year, so a hub page carries real content instead of a list of links.
3. Only index pages that hold something
A content site with 570 subjects can generate thousands of URLs, and many of them start empty. Indexing empty pages hurts the whole site, so CampusPrep follows one rule: a page is indexable only if it carries real, free content. Empty resource pages and teaser pages are marked noindex,follow and left out of the sitemap; unit or year pages with nothing under them return a 404.
Duplicates were the other half. First-year subjects are shared across branches, so the same subject appeared under several URLs. Each shared subject now has one canonical page, and the variants point to it. The www host redirects to the bare domain. Old URLs of documents that were replaced redirect permanently to the live version.
4. Make every page fast on a cheap phone
Since most search visits come from phones, the site was designed mobile-first and checked at 320, 360, 390 and 414 px wide: no horizontal scrolling, tap targets at least 44 by 44 px, body text at 15 to 16 px, one sticky element at most.
The engineering behind it
CampusPrep runs on Django 5.2 with PostgreSQL and Redis, served by Gunicorn with Uvicorn workers, with document storage on Cloudflare R2 and Cloudflare in front of the whole site. Most of the interesting work is in how pages reach the student.
Text that crawlers and slow phones can read
Earlier, the document reader delivered content as an encrypted blob that JavaScript decrypted after a second request. For logged-in material that has a purpose. For a public syllabus it meant that search engine crawlers, and any phone that had not finished loading the script, saw a spinner instead of the text.
Now, documents that are free to read are rendered on the server as plain HTML with structured data, and the page no longer depends on a session or a second request. Locked material keeps its protection. The check is simple: fetch a reader page as Googlebot and the syllabus or paper text is in the response, with one title, one description, one canonical URL and one H1.
Less JavaScript and CSS on the first load
An audit on a throttled slow-4G profile found the styling framework being compiled in the browser on every visit. Its first contentful paint was 3.17 seconds on a subject page and 1.68 seconds with only that one script blocked. Tailwind is now compiled at build time into a single stylesheet, and the change was checked rule by rule against what the old setup produced so pages looked the same.
Maths in public papers is typeset with KaTeX. The much heavier MathJax is loaded only for members' notes that need it. Scripts that only logged-in members use, such as htmx and the reading telemetry, are no longer sent to visitors.
Caching at three layers
Exam season means traffic arrives in waves, and crawlers arrive in bursts. Three layers keep that off the database:
| Layer | What it does |
|---|---|
| Cloudflare edge | Caches public pages for visitors without a session cookie; public pages send Cache-Control: public, max-age=3600, stale-while-revalidate=86400 |
| In-app page cache | Keeps rendered HTML of public pages for visitors without a session, fresh for 15 minutes; if a fresh render fails with a server error, a stale copy (up to six hours old) is served instead |
| Service worker | Serves CSS, JS, fonts and images stale-while-revalidate; fetches pages network-first with an offline fallback page |
Two details made the edge cache possible. Public pages no longer set a CSRF cookie, because a page that sets a cookie cannot be shared from a cache. And the in-app cache is cleared by signals when a document, subject, branch or semester is published or edited, so a correction shows up without waiting for a timeout.
The motivation was concrete: crawlers were meeting too many errors and slow responses at peak times, and a crawler that meets errors and slow pages crawls less and trusts the site less.
Fewer, lighter queries
Some of the slowest public pages were loading far more than they showed: document lists carried full parsed bodies for every document in a subject. Lists now load only the fields a page displays, which in one case took a first-year paper's page data from 67 KB to 5 KB. The sitemap is built from two narrow queries and lists real last-modified dates, not today's date on every URL.
What we learned
- A login wall on search traffic is expensive. It is worth measuring where people enter and leave before deciding what to gate.
- SEO on a large content site is mostly subtraction. Removing empty, duplicate and thin pages from the index did more than adding keywords.
- Use your users' words. Titles built from real search queries ("4th sem", subject names) beat titles built from internal codes.
- Design for the worst network you serve. Pages that are fast on throttled 4G are fast everywhere.
- Cache public pages aggressively and private pages never. Getting the cookie rules right is what makes that possible.
Where it stands
CampusPrep is live and still growing. The work continues as the product does: more papers and notes as they arrive, and regular checks of what students search for and where they drop off.
If you run a content-heavy site, an education product or anything that needs to stay fast under exam-day traffic, we would be glad to talk it through. See our web and software work, other projects, or get in touch.