What we are building
Age bands on a baby class site are not a heading on a timetable. They are a small set of records with fields, each rendering a page of its own, matched to the classes configured in your booking platform, and editable by you when you split a band or rename one.
This is the build order we use. It takes an afternoon the first time, and it is the thing that makes the rest of the site work.
1. Write the bands down before touching a website
Bands follow development, not round numbers. Start from what actually changes the session: whether the baby is mobile, whether they can sit, whether they are walking.
A common three-band shape is non-mobile babies, sitters and crawlers, and walkers. Swimming and massage providers band differently, often around the newborn period or water confidence. Whatever you choose, define each band by an age range in months, and make the ranges overlap by a month at each boundary rather than leaving gaps.
If a band has no session running this term, keep the record and mark it as not currently running rather than deleting it.
2. Set the bands in the booking platform first
Configure the classes in ClassForKids, Bookeo, TeamUp or Sawyer before you write anything on the website, with the age range, the venue, the day and time, the capacity and the term dates on each class. Where the platform supports an age restriction or a required date of birth field, turn it on.
Then write the website from the platform. In that order, the range a parent reads on the site is the range the booking flow enforces. The other way round, the two drift apart within a term.
3. Model the band as a record
In the CMS a band is a record with fields: name, age range in months, the developmental focus paragraph, a longer description, what a session looks like, the photo set, the price fields, the booking link for each venue, and a display order.
The page renders whatever records exist. Add a band and a page appears in the navigation. Change a range and every mention of it updates. Nobody opens code, and nothing goes stale because a developer was busy in enrolment week.
4. Write the focus paragraph for each band
Two or three sentences, plain, specific, about what happens in the room for a baby that age. Tracking a scarf across the midline. Reaching for a shaker and learning that it makes a noise. Rolling, then pushing up. Floating on their back and getting used to water on their face.
Say what happens in the session. Do not claim developmental outcomes you cannot support, and do not use jargon a parent would have to look up.
5. Answer the boundary questions on every band page
Three lines that stop most of the messages:
- Which band to choose when a baby sits on the boundary, and that you will move them if it is wrong.
- What happens when a baby moves up mid-term, whether they finish the term where they started or transfer where there is space.
- That babies arrive at sitting, crawling and walking at their own pace, and the range is a guide rather than a test.
6. Attach the timetable, filtered
Each band page shows only the sessions for that band, with venue, day and time, and whether it is full. Do not send a parent who has just worked out their band to a grid of every session you run at every hall.
Where a class is full, show the waitlist rather than showing nothing.
7. Attach booking, deep-linked
Under the timetable for each band, two buttons: Book a trial and Enrol for the term, each deep-linked to the right class at the right venue in your platform, with the band pre-selected. The parent has just decided which band their baby is in, which is the exact moment they are willing to act.
Make sure the platform's flow asks for the baby's date of birth so a mis-band is caught at checkout.
8. Attach the price fields
Trial price, term price, number of sessions in the term, sibling arrangement, and what happens about a missed week. On the band page, beside the buttons, not on a separate prices page. Hold them as fields on the band record so a price change is one edit.
9. Lay it out for a phone
Almost all of this traffic is one-handed on a phone at ten at night. Band ranges in large type at the top of each page, focus paragraph next, timetable as stacked cards rather than a wide grid, buttons full width and reachable with a thumb. Test on a real handset and inside the Instagram in-app browser.
Do not put the age ranges inside an image, which is invisible to search engines and unreadable to screen readers.
10. Test, then set a review date
Check three things agree: the range on the band page, the range on the platform class, and what you actually run. Try booking a trial as a stranger on a phone. Then put a reminder in the calendar a fortnight before each enrolment opens to reread every band page, because term dates and full classes are what go stale first.
Where this sits
Age bands as editable records, each with its own page, timetable slice, prices and deep-linked booking, are part of every baby class business website we build, and the same record-driven pattern is used across our childcare and family websites. The packages that include it are on pricing. Build the bands once as records and they stay true for years of terms.