WordPress and university
One network, one checkbox, and every site under it
Universities do not run a WordPress site. They run a network, and the difference decides everything about this install. A network has one plugin layer, one theme layer and a list of sites that grew by accretion: departments, research projects, conferences, centres, staff blogs, and a long tail of things created for one term in 2016 and never deleted. Activating across the network is one action that reaches all of it. That is either the fastest install on this axis or the widest, and which one it is depends on a decision nobody usually makes.
Why this pairing is its own job
The WordPress 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.
- The snippet that prints the tag lives in a small plugin of your own, and a plugin on a network can be activated for the network or for one site. There is no middle setting. One checkbox puts a launcher on every site in the estate, including the ones whose owners left, and unpicking it later means visiting each site.
- Whether the network is built on subdirectories or subdomains changes the allowlist completely. Subdirectory sites all answer on one origin, so one entry covers the estate and the boundary between sites is a path. Subdomain sites are separate origins, so every department needs its own entry, and the one you forget is a department whose site silently has no launcher and no error anybody will see.
- Project and conference microsites are what a network is for and what fills it up. A site built for a symposium keeps its pages, its dates, its programme and its registration deadline, all of it in the present tense, and a crawl that walks the network reads it with exactly the confidence it reads the admissions pages.
- Academic staff publish personal writing on the network, on the institution's own host, under the institution's own domain. To a crawl there is no difference between that and a page written by the communications office, and there is nothing in the text of a blog post that says whose opinion it is.
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 WordPress guide. Everything below is about where it goes on a university site specifically.
Network activation is a decision about ownership, not about convenience
Before touching the plugins screen, get the list of sites out of the network admin and look at how long it is. On most university networks the number surprises the person who asked for it, and a meaningful share of the entries have not been edited in years.
Activate per site, and only on sites where somebody can be named as the owner of what the assistant says there. That name is the whole control. A site with an owner gets material chosen for it and gets checked when the material changes. A site without one gets a launcher answering in the university's name with nobody responsible for the answers.
This is slower than the checkbox and it is the version that survives. Network activation is easy to do and easy to forget, and the estate it covers keeps growing without anybody deciding that it should.
Find out which kind of network you are on before you write the allowlist
Open two departmental sites and read the addresses. If the department appears after the domain as a path, the estate is one origin and one allowlist entry covers everything you will ever activate on. If each department has its own subdomain, every one of them is a stranger to the browser and needs listing separately.
The subdomain case has a failure mode worth naming, because it looks like nothing. The tag is present, the snippet is active, the page source is correct, and the corner is empty, and the only place the reason appears is the browser console on that page naming the origin it refused. Somebody in a department will report this as the widget not working, weeks after everybody else stopped checking.
Scope the crawl by who wrote it, not by how much there is
The instinct on a large estate is to crawl broadly because there is so much of it. The estate is the problem. Personal blogs, project sites and conference archives are all public, all on the institutional host, and all written by people who never intended their words to be quoted back as policy.
So decide the crawl on authorship. Central service pages and department pages maintained by a named team go in. Staff blogs, student society sites and anything created for a single event stay out, whatever they contain and however well written they are.
Where a research group genuinely wants an assistant for its own readers, that is a separate assistant on that site with its own material, not a wider crawl on the central one. The separation is the only thing that keeps a personal post from becoming an institutional answer.
Where the answerable material lives
| A register of the network's live sites, with an owner against each | Address, purpose, who maintains it, and when it was last reviewed. This is not documentation for its own sake: it is the document that decides which sites get the tag and which paths the crawl is allowed into, and neither of those decisions can be made honestly without it. |
|---|---|
| The practicalities enrolled students actually ask about | Term and semester dates, library and IT service hours, campus access and building opening, replacing a card, where to report an absence, and how to reach a department office. This is most of the question volume on a departmental site and it belongs to central services, so it has to be indexed from wherever it lives rather than from wherever the assistant is standing. |
| Wellbeing and support routes, taken from the central service pages | The published routes to counselling, disability support, the students union advice service and out of hours help. Somebody will type that they are struggling into a launcher on a department site at midnight, and the reply has to name a real service in the first line rather than search a departmental page set that has never mentioned one. |
| Who answers what, so a handover reaches a team | The department, service or office that owns each kind of question, with the address a handover should go to. On an estate this size the difference between a message landing with the right team and landing in a general enquiries inbox is a week, and the person waiting is usually the one with the deadline. |
The first thing to get right
Get the site list out of the network admin and put a name beside every entry, then activate only where you managed to write one.
It converts an install decision that is otherwise a checkbox into the only question that matters on an estate this size, which is who is responsible for what this thing says on a given site. It also produces the crawl scope for free, because a site with nobody's name on it is a site nobody is maintaining, and material nobody maintains is material that answers a current question with an old one.
The failure that belongs to this combination
A lecturer's blog post, delivered as the position of the university
A prospective student asks something the institution has a careful published line on: how a policy is applied, what a department thinks of a qualification, whether something is allowed. The strongest match in the material is a post by an academic on their own blog, which is thoughtful, specific, written in the first person and hosted on the university's own domain.
The answer that comes back is fluent and carries a citation that resolves to a real page on a real institutional address. Nothing about it looks like a personal opinion, because retrieval has no way to tell an institutional page from a personal one when both are served by the same network under the same domain, and the post itself never says it is speaking only for its author.
This is the failure a network produces and a single site does not, and it is not fixed by tuning anything. It is fixed by deciding the crawl on authorship: central and department pages with a named maintainer in, everything personal out. If a staff blog has to stay in scope for some reason, the network path it sits on should be excluded and the useful posts republished by whoever owns the institutional voice.
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 one assistant serve the whole network?
- It can be installed across the whole network. Whether it should read the whole network is a different question and the answer is usually no, because the estate contains personal writing, dead project sites and event archives alongside the pages you would stand behind. Scope the material tightly and let the install be as wide as you have owners for.
- Ours is a subdirectory network. Does that make it simpler?
- For the allowlist, yes, because everything answers on one origin and one entry covers it. It changes nothing about the rest. The crawl boundary is now a path rather than a domain, which makes it easier to get wrong, and the decision about which sites carry a launcher is still per site.
- What about student society and project sites on the network?
- Leave them out of both the install and the material unless somebody will own what is said there. They are public and they are on your domain, which is exactly what makes them dangerous as material: an answer sourced from one carries the institution's address and none of the institution's review.
Keep reading
- Installing on WordPressHook the tag into wp_footer with a snippet plugin, keep it out of the theme, and stop optimisation plugins from deferring it away.
- 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.
- A garden centre on WordPress, where the archive is the problemWordPress keeps every seasonal post at its own address forever, so a crawl reads April's advice in November. In this trade that is not stale, it is wrong.
- Writing that is correct for a fortnight and published for yearsDeadline and threshold posts stay live at permanent addresses. In this trade an old figure quoted with a citation reads as advice, not as a stale tip.
- 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.
- 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.
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.