Most school websites are built once and then quietly rot.
The photos are from a sports day three years ago. The "Latest News" panel stops at a circular from last October. The faculty page lists two teachers who have left and none of the four who joined. Somewhere in an inbox there is a thread with a web agency about updating it, and it has been unanswered for a month.
Meanwhile the same school has completely current information about all of those things. The staff records are up to date because payroll depends on them. The notices are current because parents read them. The calendar is current because the exams are on it. The information exists. It simply lives somewhere the website cannot reach.
That gap is the entire problem, and it is a plumbing problem rather than a design one.
Why school websites go stale
Ask an administrator why the site is out of date and the answer is almost never "we don't care." It is usually one of these:
Updating it is somebody else's job. The site was built by an agency or a past staff member. Changing a paragraph means raising a request, waiting, checking, and often paying. So small corrections never get made, and the site drifts further from reality.
The people with the information cannot publish it. The exam coordinator knows the date sheet. The admissions head knows this year's fee structure. Neither has a login, so the information has to be relayed to whoever does, and something is lost each time.
Nobody wants to be the one who breaks it. When there is no draft mode, no preview and no way back, editing a live page is genuinely risky. The safest action is to leave it alone.
The same fact has to be typed in several places. A new teacher joins. They are added to staff records, and then, separately, to the website's faculty page. The second step is the one that gets skipped, every time.
The last one matters most, because it never resolves itself. Any process that depends on someone remembering to copy the same fact into a second system will eventually stop being done.
What "built on your own infrastructure" actually changes
ScolaOS is Education Infrastructure as a Service. Traditional school ERPs digitised records and left the public website as a separate project entirely, with a different vendor, a different login and a different copy of the truth. When the website is part of the same infrastructure that runs the school, the relationship inverts: the site reads from the records your staff already maintain, instead of asking someone to retype them.
Concretely, that means a faculty section that lists staff because they are staff, a notices panel that shows notices because they were issued, and an events section that reflects the school calendar because the calendar is the calendar.
Pages that update themselves
Four kinds of live school information can be bound directly into page sections:
| Section | Reads from | Stays current when |
|---|---|---|
| Faculty | Staff records | Someone joins or leaves |
| Programmes | Classes offered | Your academic structure changes |
| Notices | Issued notices | A notice goes out to parents |
| Events | The school calendar | An event is scheduled or moved |
A few properties of this are worth being precise about, because "the website shows live data" is the kind of sentence that deserves scrutiny.
The binding is read-time only. Your page content is never rewritten behind your back: the stored page is left exactly as authored, and the live values are resolved when a visitor loads it. Nothing is quietly overwritten, and turning a binding off returns you to plain authored content.
It is scoped and filtered by design. Each query is restricted to your school, and the projection is limited to public-facing attributes. No student information, no financial information and no private staff fields are reachable through a page block, regardless of how the block is configured. A section also has a sensible cap, at six items by default and never more than fifty, so a page cannot accidentally become a data dump.
You choose what is bound. Sections that should be editorial, such as your principal's message or your admissions philosophy, stay editorial. Binding is opt-in per section.
The practical effect is that the two pages that go stale fastest, faculty and news, stop going stale, because keeping them current is no longer a separate task anyone has to remember.
Who can change what
Letting more people edit the website only works if there is a way to review what they write. The publishing flow is built around that:
- Someone edits a page. Their work is saved as a draft, so the live page is untouched.
- They submit it for review. A reviewer sees exactly what changed.
- The reviewer approves it, or rejects it with a reason and it goes back for another pass.
- Approved pages publish, either immediately or scheduled for a date and time you pick.
Two supporting features make this safe rather than merely orderly.
Preview links for drafts. You can generate a private preview link for an unpublished page and send it to whoever needs to sign off, whether a director, a trustee or the head of admissions. They see the page as it will look, without needing a login and without anything going live.
Version history you can actually use. Every published version is kept. You can view the history for any page, revert a draft, restore a previous published version, and remove versions you no longer want to keep. If a change goes out wrong at 9pm before an admissions deadline, putting the old page back is a decision, not a rescue operation.
There is an audit log over the whole thing, so "who changed the fee page, and when" has an answer.
Starting from a template, not a blank page
Twelve multi-page templates ship with the platform, each covering the pages a school actually needs (home, about, academics, admissions, contact) with a shared navigation and footer already wired up. They are built for different kinds of institutions rather than being one design in twelve colour schemes:
- Schools: Modern CBSE School, Traditional K-12, Premium International, Little Learners (preschool), Residential Boarding School
- Higher education: University Pro, Medical College
- Training: Coaching Institute, Skills Academy
- Groups and trusts: Multi-Campus Group, Trust School
- Design-forward: Minimal Modern
Each template also carries a colour and typography preset that you can apply independently, so you can keep a layout you like and move it onto your own brand colours. Additional templates published centrally appear in the same list.
Your own domain
A school website on a vendor's subdomain looks like what it is. Custom domains are supported: you point your domain at the platform, and DNS verification runs in the background and reports its status. If you have just fixed a DNS record and don't want to wait for the next automatic check, you can trigger re-verification yourself.
Talk to your domain registrar or IT provider about the DNS records themselves, because that part happens on their side, not yours.
Turning visitors into admissions enquiries
An admission enquiry form on your website submits directly into your admissions pipeline. The enquiry appears where your admissions team already works, with the rest of the funnel, meaning interviews, entrance tests, decisions and enrolment, around it.
To be exact about the boundary: this is enquiry capture, not a self-service application portal. A prospective parent can tell you they are interested and reach the right person quickly. Completing a full application, uploading documents and paying an admission fee online is not part of the public site today.
That distinction matters more than it might seem. The enquiry is the step where schools actually lose people, whether through a form that goes to an unread inbox or a phone number nobody answers on a Saturday. Closing that gap is worth doing on its own.
Where AI fits, and where it doesn't
Drafting website copy is the one place AI is genuinely useful here: a first pass at an about page or a programme description that you then edit into your school's voice. That assistance is available, and its usage is governed by a credit system with per-role controls, so a school can decide who may use it and see what has been used.
What it is not: it does not analyse your school data, generate insights, or make decisions. It helps with words on a page. Anything published still goes through the same draft, review and approval flow as copy a person wrote from scratch, which is the right default for anything a machine drafted.
Getting your school website live
A realistic sequence for a school starting from an old site or none at all:
- Pick a template that matches your institution type, and apply your colours.
- Set your home page and work through the core pages: about, academics, admissions, contact.
- Bind the sections that should stay live: faculty, programmes, notices, events. Leave editorial pages editorial.
- Add the admission enquiry form to your admissions page.
- Decide who reviews. Give the people with the information editing access, and name one or two approvers.
- Connect your domain and confirm DNS verification has passed.
- Preview, review, publish.
The step schools skip is the fifth one, and it is the one that determines whether the site is still accurate in a year. A website with three editors and one approver stays current. A website with one editor who is also the person handling admissions in June does not.
Common mistakes
Binding everything. Not every section should be live. A page that is entirely generated has no voice, and prospective parents can tell.
Treating the website as a launch project. It is an operational surface, like the noticeboard. Someone needs to own it after go-live.
Leaving one person as the only editor. When they are on leave, the site freezes. When they leave the school, it freezes permanently.
Publishing without preview on mobile. Most parents will see your site on a phone. Check there first, not last.
Keeping a parallel "news" system. If notices go out through the school and are also retyped on the website, one of them will be wrong. Bind the notices section and let it be the same notice.
Frequently asked questions
Do I need a web designer to run a school website builder?
No. The templates cover the standard page set and the editor is built for administrators rather than developers. A designer is worth involving if you want a look that departs significantly from the templates, but for keeping a site accurate and current, which is where most school sites fail, no design skill is needed.
Will the website show student data?
No. Page sections can only read public-facing information, meaning staff, classes offered, notices and calendar events, and the queries are restricted to your school. Student records, fee information and private staff fields are not reachable from a page block.
Can we use our existing domain?
Yes. Point your domain at the platform and DNS verification will confirm it. You keep your domain and your registrar; only where it points changes.
Can teachers update the website without risk?
Yes, when you set it up that way. Editors work on drafts, drafts go through review, and only approved pages publish. Every published version is retained, so any change can be reversed.
What happens to our old website?
It stays where it is until you switch the domain over. Because you can preview complete pages before publishing and choose a scheduled publish time, the switch can happen when you choose rather than the moment you start building.
Does this work for a group with several campuses?
Yes. Live sections resolve within the school and branch they belong to, so a group can run campus pages that reflect each campus's own staff, notices and events.
Is the AI writing feature required?
No. It is optional drafting assistance. Every page can be written entirely by hand, and everything AI drafts goes through the same review before it can go live.
Conclusion
A school website is not a brochure that gets reprinted every few years. It is the first thing a prospective parent sees, the place current parents check when they are unsure, and, when it is out of date, a fairly precise signal about how the rest of the school is run.
The reason most school sites drift is not neglect. It is that keeping them current was designed as a separate job, handed to someone outside the school, and disconnected from the systems where the information actually lives. Building the site on the same infrastructure that runs the school removes that separation: the faculty page is current because your staff records are current, and the notice on the website is the notice you sent.
Want to see what your school's website would look like on live data? Book a demo and we will build a page from your own information, or explore the platform and pricing in your own time.