Gemin
Get in touch

Webflow for EdTech

One website often has to convince two very different audiences. The person using an education product is not always the person buying it.

Start a project

Built for Course Hero.

What these builds involve

What these sites need, and what we figure out first.

What these sites need

  • Separate paths for the learner who signs up and the institution that procures
  • Accessibility built in rather than retrofitted, because procurement asks for evidence
  • Course, program and instructor pages built from linked collections, with real filtering over them
  • Clear pricing and signup paths for free and paid plans, where there are both
  • Seasonal campaign pages that go up and come down without a developer
  • Connections to payments, scheduling, video, CRM and the learning platform

What we figure out first

  • Which audience the homepage is actually for. One of them gets the homepage, and the other gets a real, findable route to the pages, the proof and the call to action built for them. Writing every page down the middle is what leaves both of them half-served.
  • Whether the content library belongs in the CMS at all. It depends on the structure, the volume, the permissions and what has to be searchable. Public course and resource pages often fit the CMS well. A library that needs accounts, progress or real search is a database with a website in front of it, and finding that out during an import is the expensive version of this conversation.
  • What the analytics may collect. Before anything is installed, I work with your team to agree which events and fields may be collected. Education sites can involve student records, institutional data and younger users, and whether FERPA, COPPA or anything else applies is for your legal and privacy teams to determine. I implement the rules they agree.
  • What procurement will ask for. The accessibility evidence, the security documentation and the data-handling information a buyer needs, alongside product requirements such as SSO. Some of that is website work and some of it is not, and knowing which is which early is the difference from finding out in month three.
  • What the site has to be ready for, and when. Education runs on dates somebody else set: a semester start, a conference, a funding announcement. A phased launch that is genuinely live for the date beats a complete one that is not, and deciding which half ships first is a decision, not a compromise.

Students, teachers, administrators, parents and procurement teams can all arrive at the same site looking for different answers. I build Webflow sites that give those audiences clear paths without creating a separate website for each of them.

Separate the journeys without separating the brand

Two audiences, and the part they share

The learner

Arrives asking

  • What does it actually do?
  • Is it free, and what does it cost?
  • Does my school already use it?
  • How quickly can I start?

Both

Needed by each

  • Pricing, in their terms
  • Proof from peers
  • Accessibility
  • Data handling

The institution

Arrives asking

  • Is there a VPAT?
  • Security review and SSO
  • Data handling and retention
  • References, and how we buy it
The middle is what both sides need, and it is what most sites write once for the learner and then expect the institution to accept. It is the part worth writing twice.

Build resource libraries as systems

Education companies tend to accumulate content quickly.

Subjects, courses, resources, guides, institutions and learning materials can turn a simple CMS into a structural problem if the relationships are not planned early.

I map those relationships before building the templates so the library can grow without requiring a redesign every time a new content type appears.

Accessibility is part of the product

Education sites serve a broad audience and often face accessibility requirements from institutional buyers as well.

I build semantic structure, keyboard behavior, focus states, contrast and responsive layouts into the implementation rather than treating accessibility as a final QA task.

In this sector it is often a procurement gate rather than a nice-to-have, which is a good reason to build it in rather than to find out what it would take to add later.

Know what belongs in the CMS

Where the line actually falls

A fit for Webflow

  • Marketing content and landing pages
  • Resources, guides and institutional information
  • Public learning materials
  • A curated set of subject or course pages

Keep in the learning platform or application

  • Student records and course progress
  • Authentication and assessments
  • A library that needs real search or permissions
  • Protected learner data, and anything needing privacy controls beyond a marketing site
The left column is what the CMS is genuinely good at. The right is a database, and the best architecture keeps Webflow rendering in front of it rather than trying to hold it.

I keep that boundary clear so Webflow stays easy for the marketing team without becoming a fragile substitute for the learning platform. What Webflow will not do covers how to tell which side you are on.

What it connects to

The stack these sites usually run on.

And what they are usually moving off

Before you ask

Questions I get asked about EdTech.

Can Webflow hold our content library?

It depends on the content structure, the volume, the permissions and the search requirements. Public course and resource pages often fit Webflow CMS well and benefit from being indexable. Student records, progress tracking and application features belong in systems designed for them. I map that boundary before the build, and the answer is often both: the library in your product, Webflow rendering the pages that need to rank.

Do you handle accessibility properly? We get asked for a VPAT.

I use WCAG 2.2 AA as the implementation target: semantic structure, keyboard navigation, visible focus states and appropriate contrast. I do not provide an independent accessibility audit or prepare a VPAT. If procurement requires either, that is worth planning for early rather than discovering at the review.

Our buyers are institutions but our users are students. Who is the site for?

Both, but not on the same page. One clear primary audience above the fold, and a genuine findable route for the other with its own pages, proof and call to action. Splitting every page down the middle leaves both of them half-served.

Can our team launch a back-to-school campaign without a developer?

That is the point of building it properly. Seasonal pages are the most predictable work in this sector and the worst thing to queue behind a release. Campaign and subject pages are CMS content with the Editor scoped to them, so the people who write the copy publish it.

What about student privacy in the analytics?

Settle it before anything is installed, because it is hard to retrofit. A product reaching younger users, or one holding institutional records, raises questions most default analytics setups were never built with in mind, and whether COPPA or FERPA apply is a call for your legal and privacy teams rather than a setting in a tag manager. I implement the collection rules they agree.

We are on WordPress or Drupal. Is moving worth it?

The useful test is whether your current setup supports your publishing workflow. If a routine content update or a campaign launch needs development work, that is a real reason to look at the architecture, and then the question is whether improving what you have or moving to Webflow serves the team better. The migration pages cover what actually carries across.

Other industries

Building something else?

Reach out and see if we are a good fit.

Start a conversation

Currently booking two to four weeks out.