Squarespace and private school

Open mornings, member areas, and an install you cannot subtract from

Two things about this platform decide what a school assistant does. The events collection is built to keep what has already happened, which collides with the single most asked question on an independent school site. And code injection is a site wide field with no negative form, so the decision about which pages a launcher may appear on is a decision about the shape of the whole install rather than a setting you can revisit on a Tuesday. Both are worth settling before the tag goes in, because both are awkward to unwind afterwards.

Why this pairing is its own job

The Squarespace install guide covers the tag, and the private school guide covers what the assistant has to know. What follows is the part that belongs to neither.

  • An events collection keeps past entries published at their own addresses and lists them, which is exactly right for a school that wants a record of its year. It is exactly wrong as material, because when is the next open morning is the highest volume question on the site and the strongest match for it is frequently a morning that has already been and gone.
  • Member area pages are ordinary pages of your site, so the site wide footer field prints the tag on them and the launcher appears to a signed in parent. The content of those pages is behind a login, so a crawl reads none of it. The widget is present on precisely the pages whose material it does not have.
  • Per page injection adds code to a page and can never remove the site wide field from another. So keeping the launcher off anything a pupil routinely opens is not an exclusion, it is a rebuild: the site wide field comes out and the tag goes in page by page, on every page you do want it on, forever.
  • Term dates and the school calendar are usually an embedded calendar dropped into a code block. The dates a parent asks about most sit inside a frame served from somewhere else, on a page that otherwise carries a heading and nothing.

What changes about the install here

<script src="https://cdn.askably.xyz/w.js" data-key="pk_live_YOUR_KEY" defer></script>

The tag is the same one on the Squarespace guide. Everything below is about where it goes on a private school site specifically.

Decide the shape of the install before anything is pasted

There are two shapes and they are not equally easy to change your mind about. Site wide means the footer field, one paste, and the launcher on every page including the member area and anything a pupil reaches. Page by page means removing the site wide field entirely and adding the tag through each page's own injection field, which is more work at the start and is the only way to leave a page out.

Take that decision with whoever holds safeguarding rather than with whoever manages the website, and take it now. The reason is mechanical rather than procedural: there is no exclusion setting to reach for later, so a decision deferred is a decision to be site wide, and reversing it means visiting every page you meant to keep.

Write the choice down with the reason next to it. Schools change website managers more often than they change platforms, and the next person will find a site wide field missing and a dozen page level ones and assume somebody did it wrong.

The member area is where a parent trusts it most and it knows least

A parent who has just signed in reasonably assumes that whatever appears afterwards is part of the school's system. It is not. It cannot read the letter on the screen, it cannot see the account they signed in to, and it has no idea which family it is talking to.

So if the launcher stays there, the greeting and the refusal have to say so immediately and without hedging: it answers from the school's published pages, it cannot see anything to do with a particular child, and here is who to contact. A parent who gets a vague answer instead reads it as the school avoiding them, which is a worse outcome than not being there at all.

If you would rather it were not there, that is the page by page install, and it is worth costing honestly before promising it.

Take the past events out before the first crawl

Go through the events collection and unpublish or archive everything that has already happened, or exclude the events path from the crawl entirely. Both work. Doing neither means the material contains a run of open mornings, each with a real date and a real address, none of which say in their own text that they are over.

Then look at how the remaining entries are written. An event titled Open Morning with the date only in the collection field will produce an answer carrying a day and a month and no year, which a parent reads in the way that suits them. Put the full date into the first line of the description so the answer carries its own timing.

Where the answerable material lives

Source material on a Squarespace private school site
The events that have not happened yet, with the year in the textOpen mornings, taster days, entrance assessment dates and the deadline attached to each. Written so the date appears in a sentence rather than only in a field, because the answer arrives in a chat panel with no page around it and nothing else to date it by.
Transport routes and how far the buses actually goEach route with its pick up points, the times, the cost, and whether places are limited. Distance decides applications more than any other practical fact, and a family that cannot establish whether you reach their village does not enquire, they simply do not appear.
What happens on an assessment dayHow long it lasts, what a child actually does, whether a parent stays, what to bring, whether there is an interview and who conducts it. This is anxiety material, it is asked in the evening by people who will not ring the office to ask it, and it costs nothing to publish.
Term dates as a plain list beside the embedded calendarThe same dates the calendar embed shows, typed out as text on the same page. Keep the embed for parents who want to subscribe to it. The list exists so the dates are readable at all, and so a question about the last day of term has something to match against.

The first thing to get right

Do this first
Unpublish every event that has already taken place, then ask the assistant when the next open morning is and check the date it gives you.

It is the question this trade gets most and it is the one the platform is structurally most likely to get wrong, because an events collection is designed to keep a record and material is not a record. One minute of housekeeping changes the answer to the most valuable question on the site, and the test tells you immediately whether anything else is still lurking in there.

The failure that belongs to this combination

The launcher is inside the members area and the material is not

A parent signs in, opens the letter about next term's arrangements, and asks the launcher sitting in the corner what time the coach leaves. The page in front of them says so. The assistant cannot read that page, because a crawl arrived at the login screen and went no further.

What happens next depends on your material rather than on the widget. If there is a public page mentioning coach times it will answer from that, which may be last year's arrangement described in the present tense. If there is not, it refuses, and a parent who is looking at the answer while being told it is unavailable does not conclude that the assistant has limits. They conclude the school is being unhelpful on purpose.

Both versions are the same fault seen from different sides, and neither is fixed by indexing harder. Either publish the practical arrangements where they can be read, or state in the greeting on those pages that it answers only from the public site. The one thing not to do is leave a confident general purpose launcher on a page whose entire content is invisible to it.

Before you go live

  • The origin the page is served from has to be on the allowlist for that assistant, or nothing renders and the browser console says which origin was refused. An apex domain and its www are two different origins to a browser, so list both, along with any staging or preview host you want it to work on.
  • Open the site as a visitor would, on the pages a private school visitor actually lands on, and ask it something only your own material could answer. A widget that renders is not the same as a widget that has read anything.

Questions

Can we keep it on the public pages and off the parent login?
Only by giving up the site wide field. Page level injection adds and never subtracts, so the exclusion has to be built by placing the tag on each page you want rather than by removing it from one you do not. Decide that before launch, because retrofitting it means going through every page twice.
We keep old open mornings up deliberately as a record. Can we?
Yes, and then exclude that path from the crawl rather than from the site. The pages carry on doing their job for readers and stop competing with the current event for the one question everybody asks. Keeping them in the material and hoping the newest one wins is not a plan.
What if a pupil types something worrying into it?
The reply has to name the school's published route and a phone number straight away, ask nothing further and reassure nobody. Agree that wording with the safeguarding lead before publishing, and remember that on this platform whether a pupil can reach the launcher at all is decided by the install shape rather than by a setting.

Keep reading

Try it on your own material

Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.