Gatsby and university
Two snapshots: the build and the crawl
A Gatsby site is generated, so every page a visitor reads is a copy made at the last build from content somebody edits elsewhere. The assistant reads a second copy, made by a crawl at some other moment. On most sites that gap is invisible. On a university site, where nearly every answer carries a year and a closing date, it is the whole problem.
Why this pairing is its own job
The Gatsby install guide covers the tag, and the university guide covers what the assistant has to know. What follows is the part that belongs to neither.
- Content is baked at build time. A department changes a fee or a deadline in the source and the page stays wrong until the next build, at which point the material stays wrong until the next crawl. Two clocks, and neither of them is the calendar the applicant is working to.
- onRenderBody covers the pages this project generates and nothing else. A university estate is many sites, most of them not this one, each on its own address with its own material and its own allowlist entry.
- Preview builds get addresses of their own. Branch and pull request previews are separate origins, which is exactly where a web team does its reviewing and exactly where the launcher will be missing.
- Archived cycles stay published. A generated site rebuilds last year's pages as happily as this year's, and a crawl treats them as equally current unless the year appears in the visible text.
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 Gatsby guide. Everything below is about where it goes on a university site specifically.
One export here, and the same conversation for every other site in the estate
gatsby-ssr.js puts the tag on every page this project generates, including pages created later from data, which is the appeal of doing it there. It does not reach the library catalogue, the department that never migrated, or the student portal, each of which answers on its own address and is built on something else.
List those addresses before promising anybody a sitewide assistant. Each is a separate install in whatever it runs on, a separate allowlist entry, and a separate decision about whether it should carry one at all. The student portal usually should not.
Build, then crawl, and keep that order
Run the crawl against the deployed site rather than a local preview, and run it after a build rather than before. Material taken from a branch preview describes a site no applicant can visit and will contradict the live pages in ways nobody can reproduce.
Then set the recrawl cadence against the admissions calendar rather than against a round number of days. The weeks either side of a closing date are when the pages change and when the questions arrive, and they are the same weeks.
Local ports, preview addresses and the deployed domain
The development server, the local preview of a built site and the deployed domain are three origins already, and preview deployments add one per branch. That last group is what catches university web teams, because reviewing on a preview address is the normal way work gets approved.
Where preview addresses are generated per branch they cannot all be listed in advance. Either review on one stable preview address you can allowlist, or accept that the launcher gets checked on the deployed site and nowhere earlier, and tell the reviewers so they stop reporting it as broken.
Where the answerable material lives
| Course pages with their entry requirements | Generated at build, so the requirement text sits in the HTML the crawl receives. That is why this axis works here at all: what the visitor reads and what the crawl reads are the same generated file. |
|---|---|
| The admissions cycle calendar | Dates with a year attached, and the material that goes stale first. A date changed in the source but not yet built is invisible to applicants as well as to the assistant, which makes the build cadence an admissions problem rather than an engineering one. |
| Fees and funding by fee status | Tables generated from the source, quotable exactly as rendered. Have the assistant quote rather than summarise wherever a number is involved, because a fee restated in different words is a fee misquoted in the institution's name. |
| Archived cycles | The thing to exclude. Leave old cycle paths out of the crawl. Where they must stay published, the academic year has to appear in the visible text, since the generated HTML is all the assistant has and the path it sat under is not part of any answer. |
The first thing to get right
Exclude the archived cycle paths from the crawl, then check that every current cycle page states its year in visible text rather than only in its address.
The most damaging answer a university assistant gives is last year's deadline delivered in a confident sentence with a citation attached. Both halves of that are content decisions made before the first index, and neither can be repaired afterwards by tuning anything.
The failure that belongs to this combination
The deadline moved, the site rebuilt, and the assistant kept the old one
Deadlines move. An extension is announced, a clearing date shifts, a scholarship round closes early. The source is edited, a build goes out, and the site is correct within the hour, which is what a generated site is good at.
The material is not correct and nothing about the build touches it. The assistant keeps quoting the previous date in a fluent sentence with a citation to a page that now says something else, which is the worst available combination, because the citation reads as proof to somebody who does not click it.
Tie a recrawl to the deploy for the pages carrying dates, or keep dates out of the indexed material entirely and have the assistant point at the calendar page. Either is defensible. Doing neither is how an applicant misses a deadline in your name.
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 university 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 it tell an applicant whether their grades are enough?
- No, and the material makes that easy to hold. It quotes the published requirement for a named course, which is a statement about the course. Weighing a person against it is an admissions decision, and the refusal should say that admissions assess individually and offer to pass the question on.
- Departments run their own sites. Do they each need their own assistant?
- They each need their own install and their own allowlist entry, because they are separate origins. Whether they need separate assistants depends on whether their material is distinct enough to be worth separating, and a department with its own entry requirements and its own deadlines usually is.
- Why does nothing appear on my preview build?
- The preview has its own address, so the origin is refused and the console names it. Add a stable preview address if reviewing there matters, and remember that per branch addresses cannot be allowlisted before they exist.
Keep reading
- Installing on GatsbyReturn the script from onRenderBody in gatsby-ssr.js with setPostBodyComponents, or use gatsby-browser.js, then rebuild before you check.
- Everything for a universityApplicants and enrolled students ask different things. What a university assistant can answer about entry, fees and visas, and what it must never predict.
- One university, forty sites, and the question of whose assistant this isEach department runs its own site, material and allowlist entry. Course requirements sit in fields and tabs that a plain crawl never assembles.
- One network, one checkbox, and every site under itNetwork activation puts the tag on every departmental site at once, including a conference microsite from years ago and a lecturer's personal blog.
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.