Drupal and university
One university, forty sites, and the question of whose assistant this is
A university on Drupal is almost never one site. It is a central site owned by marketing, a set of departmental sites owned by departments, a research centre or two that predate the current design, and a student services site with its own team. Each has its own editors, its own content model, its own cache and often its own install. The instinct is to buy one assistant for the university. The structure of the estate says otherwise, and the structure is right.
Why this pairing is its own job
The Drupal 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.
- Departmental sites are maintained by departments, which means the entry requirements, the fees and the contact routes on them are maintained at different speeds and to different standards. One assistant reading all of them will answer a question about one department from another department's page and cite it correctly.
- Course pages are assembled rather than written. Entry requirements, module lists and fee lines are separate fields and referenced entities rendered into tabs, so what a reader sees as one coherent page arrives at a crawl as pieces, and the tabs that load on demand arrive as nothing.
- Every fact on a university site has a year attached, and old cycles stay published. Fees, deadlines, scholarship rounds and entry grades all change by intake, and an archived page answers in exactly the same confident tone as the current one.
- The site has a signed in half: the student portal, the virtual learning environment, the applicant tracker. All of it is on separate addresses, none of it is readable, and a student who is already inside it does not need a chat panel there.
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 Drupal guide. Everything below is about where it goes on a university site specifically.
One key per site, and be honest about which sites those are
Start by listing every address the university answers on that a prospective student might reach. On a Drupal estate that list is longer than anybody expects, because departments have accumulated their own domains and subdomains over years and some of them predate the current visual identity.
Each site that gets the tag gets its own key and its own material, matched to what that site is about. A departmental assistant that reads the department's own pages plus the central admissions and fees pages answers better than one that reads everything, because the retrieval step has fewer near duplicates to pick between.
The install route is the same on each of them, whichever of the three you chose on the platform page, but the decision about which sites get one at all is the part worth spending time on. A research centre site with four pages and no applicants does not need an assistant.
Read a course page as a crawl receives it, before deciding anything
Open a course page signed out, view the source, and look for the entry requirements. On many Drupal course pages they are in a referenced entity rendered into a tab that arrives separately, which means they are not in what a crawl reads even though the tab shows them instantly to a reader.
If they are missing, the answer is not to fight the content model. Ask the admissions team for the requirements as a document, per course, and upload that. It exists already in some form, because somebody has to keep the offer levels consistent across the cohort.
The same applies to the qualification equivalency tables, which are the highest volume international question and are usually a spreadsheet in an office rather than anything on the site at all.
Scope the crawl to the current cycle
Archived cycles are still live pages on a university site, deliberately, because applicants who applied last year still need them. Leave them out of the material rather than trusting a path pattern to keep them out, and check what came back after the first crawl by asking the assistant for a deadline.
Where an old page has to stay indexed, make sure the academic year appears in the visible text rather than only in the path. The answer is built from what the page says, and a page that only carries its year in the address will answer with a date and no context at all.
Where the answerable material lives
| Course entry requirements, per course, as documents | Subject prerequisites and grade profiles for each course, taken from whatever admissions maintains rather than from the rendered course page. This is the material most likely to be unreadable on the page and most likely to already exist as a file somewhere. |
|---|---|
| The qualification equivalency tables | The country by country mapping of school leaving qualifications to your own offer levels. Highest volume international question, genuinely hard to find on most university sites, and usually held in admissions as a working document rather than published as a page. |
| The admissions cycle calendar for this intake only | Opening and closing dates, the deferral window, the document deadline, when decisions are released, and any late entry route. Dates carry a year, which is why this has to be the current version and nothing else. |
| Fees, funding and accommodation, from the central site | Fee levels by status and course, instalment options, the international deposit, each scholarship with its own criteria and closing date, and hall types with rents and contract lengths. These belong to central teams, so index them from the central site even when the assistant lives on a department's. |
The first thing to get right
Get the entry requirements out of the course pages and in as documents, one per course, from whoever maintains them in admissions.
It is the question underneath a large share of applicant traffic, it is the field most likely to be rendered in a way a crawl never receives, and the version admissions maintains is the version that is actually correct. Fixing this first also tells you whether the rest of the course page is worth crawling at all.
The failure that belongs to this combination
The archived deadline, delivered in a perfectly current voice
This is the failure that belongs to a university estate on a content system that keeps everything. An applicant asks when applications close. The assistant answers with a date, cites a page, and the page is real and was correct for the intake before last.
Two things make it hard to catch. The wrong answer is plausible, because deadlines move by days rather than months, and the citation is genuine, so the applicant has no reason to doubt it and neither does the person who reports it. It is usually found when somebody misses a deadline they believed they had a fortnight left for.
The prevention is boring and it works: crawl only the current cycle, make the academic year appear in the visible text of every page that describes one, and test after every crawl by asking for three dates you already know. The test takes a minute and it is the only reliable way to find out what actually came back.
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
- Should each department have its own assistant?
- Where a department maintains its own site and its own entry requirements, yes. One assistant over the whole estate has to choose between many similar course pages maintained at different speeds, and it will sometimes answer about one department from another's material with a citation that checks out.
- Our course pages use tabs and the requirements do not appear in the source. Now what?
- Do not try to fix it in the content model for the sake of the assistant. Ask admissions for the requirements as documents, per course, and upload those instead. They exist already in some form, and they are more accurate than the rendered page because they are what admissions actually applies.
- Can it tell an applicant whether their grades are good enough?
- No, and this is the line to hold hardest, because applicants ask it in disguise. It can quote the published requirement, which is a statement about a course. Weighing a person against it is an admissions decision made across a cohort, and an assistant that says somebody looks fine has made an offer in the university's name.
Keep reading
- Installing on DrupalText formats strip script tags from blocks. Use a small custom module, an asset injection module, or html.html.twig, then rebuild the cache.
- 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.
- Practice sites on Drupal, and the install that may not be availableBlocks strip the tag and a supplier managed install may leave no route at all. What a practice can answer, and where the tag must not go.
- 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.
- Two snapshots: the build and the crawlThe page comes from the last build and the material came from a crawl at another moment. A moved deadline is what exposes the gap.
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.