Google Sites and private school
Two school sites, one editor, and one paste between them
Schools tend to build in this tool twice: once for the public admissions site and once for the internal pages that pupils and staff use. Both are edited from the same account with the same insert menu, which is the fact that matters most here, because the difference between an admissions tool and a communication channel into a school for children is one paste.
Why this pairing is its own job
The Google Sites 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.
- The public site and the internal site are the same product under the same login. An embed block that belongs on the fees page is one paste away from a pupil facing page, and that second placement is a safeguarding decision that has to be taken deliberately rather than discovered later.
- Pages restricted to the school's own organisation are not readable from outside. Anyone not signed in gets a sign in screen, so material a school assumes is published, because staff can always see it, may be entirely unreachable as source material.
- The documents parents actually want, the fee schedule, the uniform list and the term dates, are files embedded from Drive rather than pages of the site. A crawl of the site does not collect a Drive file, so those have to go in as uploads.
- There is no floating launcher on this platform, so the assistant sits in a box in the page and has to be placed where the question happens. On a school site that is admissions and fees, not the home page a prospectus request is designed around.
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 Google Sites guide. Everything below is about where it goes on a private school site specifically.
Decide which site it goes on, and write that decision down
Nothing about being a school, or about the account type the school holds, opens a code field here. The embed block is the whole of the options, and it is available on the internal site exactly as it is on the public one, with no prompt to distinguish them.
So make the decision once, in writing, with whoever holds the safeguarding responsibility rather than whoever holds the site. A parent facing assistant on a public admissions page is an admissions tool. The same box on a page a pupil reaches is a channel into the school for a child, and channels into a school for children come with a named person and a policy.
Whichever you choose, write the refusal wording before you publish rather than after. The reply to anything that reads as a concern about a child has to name the school's published route and hand over immediately, without taking a report, asking follow up questions or reassuring anybody.
Put the box where the fee question happens
The block is part of the page flow and stays where you put it, so placement is a real choice rather than a detail. A box on the home page gets seen by people who are browsing. A box on the fees page and the admissions page gets used by people who have a specific question and no obvious person to ask it of.
Size it on purpose too, and check it on a phone. It occupies that space on every visit whether or not anybody uses it, and on a narrow screen a generous box pushes the admissions timeline below the fold, which is the content the parent came for.
One or two placements is usually right for a school. An embed repeated on every page of the site costs layout everywhere and adds nothing on the pages nobody asks questions from.
Drive files are not pages of your site
A fee schedule embedded from Drive renders inside the page for a reader and remains a Drive file. A crawl that follows your site's own links does not collect it, so the single most requested document in this trade can be sitting in plain view on the page and still be absent from the material.
Upload those files directly instead: the fee schedule with the compulsory extras, the uniform list, the term dates and the bursary policy. That also gives you a moment to check the version, which on school sites is frequently a year out of date without anyone noticing, because the embed keeps rendering whatever it points at.
Where the answerable material lives
| The fee schedule, uploaded rather than embedded | Termly tuition by year group with the registration and acceptance deposits and the compulsory extras included. The embedded copy on the page is for reading. The uploaded copy is the one that answers questions, and the two need to be the same version. |
|---|---|
| The admissions timeline, split by entry point | Written as page text rather than as another file, and separated per entry year. A parent asking about entry at seven has no use for sixth form dates, and one blended calendar produces answers that mix the two. |
| Anything restricted to the organisation | List what is on internal pages and therefore unreadable from outside. If a policy parents ask about exists only there, it needs a public version, because the assistant cannot sign in to fetch it and neither can the parent. |
| The safeguarding route, written as a chat reply | The exact wording the assistant gives to anything that reads as a concern about a child: name the school's published route, give the phone number, and stop. Not a paragraph of policy, and not a request for more detail. |
The first thing to get right
Agree and write the safeguarding refusal wording with the designated lead before the embed block is published anywhere.
On this platform the assistant sits inside the page rather than floating over it, so it looks like a part of the school's own site rather than a bolted on chat button. That makes it more likely, not less, that a child will type into it, and the wording that governs that moment should not be drafted in a hurry afterwards.
The failure that belongs to this combination
The same block, pasted onto the internal site
Somebody who built the admissions page is later asked to tidy up the pupil pages. The embed code is still in the clipboard or still in a document of useful snippets, the insert menu is identical, and it takes four seconds. Nothing in the editor asks who this site is for.
Now a child has a chat box inside a school page, answering from admissions material, with a refusal that was written for a parent asking about fees. The first safeguarding disclosure typed into it is handled by wording nobody reviewed for that purpose, and the school finds out afterwards.
Keep the snippet out of shared documents, keep a written record of which sites carry it, and check the internal sites periodically. This is a governance problem rather than a technical one, and there is no setting on this platform that will catch it for you.
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 get a floating launcher on a school site here?
- No, and no account type changes that. The embed block is the only route and it sits in the page flow, in the rectangle you gave it. If the requirement really is a launcher on every page of the site, this platform cannot produce it and the honest options are to accept an embedded box on two pages or to host the admissions pages somewhere that allows a script.
- Our fee schedule is a Drive file on the page. Why can it not read it?
- Because it is a file rendered inside the page rather than part of the page, and a crawl of your site's own links does not collect it. Upload the file directly as source material. While you are there, check which version the page has been pointing at, because that is a very common way for a school to be quoting last year's fees to itself.
- Should pupils be able to use it?
- That is a decision for the safeguarding lead rather than for whoever manages the site, and this platform makes it unusually easy to take by accident. Decide it explicitly, record which sites carry the block, and if the answer is no, keep the snippet out of any shared document where a colleague might reasonably reuse it.
Keep reading
- Installing on Google SitesGoogle Sites blocks page level scripts. The only route is an embed block, so the assistant sits in a box in the page, not in the corner.
- Everything for a private schoolAdmissions timelines, fees, bursaries and uniform lists are safe ground for a school assistant. Anything about a named pupil or applicant is not.
- The term dates page a school site builds once and forgetsTerm dates sit in a data file and the page shows what was next when the site was last built. A crawl then copies that moment.
- A school site on WordPress, and the documents it deliberately withholdsThe fee schedule and prospectus are gated files, the parent portal is a separate origin, and safeguarding decides where the launcher may appear.
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.