HubSpot and recruitment agency
HubSpot pages, an ATS job board, and the answers in between
A recruitment agency on HubSpot usually runs two websites and thinks of one. The service pages, the client terms and the candidate guidance sit in the portal, where one field puts the tag on all of them at once. The vacancies live in the applicant tracking system, on a subdomain the portal has no reach into, and vacancies are what most candidates came to ask about.
Why this pairing is its own job
The HubSpot install guide covers the tag, and the recruitment agency guide covers what the assistant has to know. What follows is the part that belongs to neither.
- The site footer HTML field is stored per domain in your portal, and your job board is almost certainly not one of those domains. Nothing pasted in settings reaches it, and nothing a crawl of your HubSpot pages read describes a single live role.
- Registration runs through a HubSpot form, and the form is where candidates stall. The assistant can explain what a field is asking for, in the wording your own page uses, and it can never fill one in, submit one, or check whether one arrived.
- The client half of an agency site is gated on purpose. Terms of business and fee structures sit behind a form, so a crawl collects a landing page and three bullet points where you expected the document.
- Candidate records sit in the CRM on the same account, under the same login, two clicks from the settings screen you installed from. None of that proximity gives the assistant access to a contact record, and every consultant on the team will assume it does.
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 HubSpot guide. Everything below is about where it goes on a recruitment agency site specifically.
The job board is a different property and often a different vendor
Open a vacancy and read the address bar. If it names a jobs or careers subdomain, or an address belonging to your tracking system, that is a separate origin serving pages HubSpot does not render. The footer HTML field has no effect there whichever domain is selected above it.
Some tracking systems allow custom markup on a hosted board and some do not. Where yours does, the tag goes in through their settings and their board address becomes an allowlist entry of its own. Where it does not, the board simply has no launcher, and saying so early beats three days of checking the key.
The material question is unchanged either way. A crawl that starts at your HubSpot domain does not walk into the board, so the roles are absent from the answers no matter which side the launcher ends up on.
One page gets one assistant, so the two audiences split in the material
The instinct is to run one assistant for candidates and another for employers. On a single HubSpot domain that does not work: the footer field applies to every page served from that domain, and a second tag on the same page is ignored rather than honoured. Pasting another key into a page's own footer HTML buys you a confusing page source and nothing else.
If the two audiences genuinely need separate assistants, the split has to be by domain, with the employer site on its own domain in the portal and its own footer field. Short of that, run one assistant across both sets of material and keep the wording of each set distinct, so the citations under an answer show you at a glance when a candidate question has been answered out of the client terms.
Landing pages are covered, forms embedded elsewhere are not
The field covers what HubSpot serves from that domain, landing pages included, so a registration landing page carries the launcher with no extra work and no second paste.
The exception people trip on is a HubSpot form embedded on a page hosted somewhere else. That page is served by whatever built it, so the tag has to go in through that platform in its own way, and that address needs its own allowlist entry.
Where the answerable material lives
| Registration and right to work guidance | Ordinary website pages in the portal, which a crawl reads directly. Highest volume candidate material, changes rarely, and worth getting right before anything else on this list. |
|---|---|
| Timesheet deadlines and pay dates | Usually a file rather than a page: a payroll guide in the file manager, linked from a page. Read the address on that link, because a file served from a content host is a document a crawl follows out of your site. Upload the version you want quoted. |
| Client terms of business | Behind a form by design, so a crawl gets the form. Upload the summary you are willing to see quoted verbatim by an assistant, and keep any negotiated version out of the material completely. |
| Live vacancies | In the tracking system, not in anything the assistant reads. Treat them as out of scope, say so in the refusal wording, and link the board rather than describing roles in the agency's name. |
The first thing to get right
Write the refusal message so it states in one sentence that it cannot see the board or an application, then names the board address and the consultant inbox.
Application status is the most asked question on a recruitment site and the assistant will never answer it. A refusal that arrives carrying the board and a route to a person turns the most common dead end on the site into the one useful thing that could have happened there. Write it before you index a page, because until it exists every unanswerable question ends in an apology.
The failure that belongs to this combination
One login for everything, so everyone assumes it can see the record
You installed from a settings screen a few clicks from a candidate's timeline. Consultants watch the demo, ask what stage somebody is at, and read the refusal as a gap in the configuration rather than as the shape of the product. Within a fortnight somebody has told a client it will report on their roles once it is properly set up.
It reads pages and documents you give it. There is no connection to the records in that account, no lookup, and nothing on the settings screen that would create one. Say this in the same sentence you announce the launcher, because the assumption is very hard to unwind after a client has heard the other version.
The candidate side is worse. Somebody who believes they are talking to the agency's own system will type a reference number and wait for a status. The refusal has to close that door in the first reply rather than in the fourth.
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 recruitment agency 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 a candidate which roles are open?
- Not from your HubSpot pages, because the vacancies are not on them. It can explain registration, documents, timesheets and pay dates, and send somebody to the board. Making it describe roles means indexing the board itself, which needs the board to be crawlable and needs you to accept that a filled role stays in the material until the next crawl.
- We have a separate employer site in the same portal. Two keys?
- Two if you want two assistants, since the footer field is set per domain and each domain carries one. Two keys also means two sets of material and two refusal messages, which is the actual work. One assistant across both, with candidate and client documents clearly separated, is usually the better trade for an agency of any size.
- It answered a candidate out of our client fee page. Why?
- Because that page matched the question better than anything else in the material, which happens when the candidate pages are thin and the client pages are detailed. That is the normal state of an agency site. Fill out the candidate material rather than rewording the question, and use the citations to see which document it reached for.
Keep reading
- Installing on HubSpotAdd the tag to the site footer HTML for your domain, check which consent category holds it back, and allowlist the preview address too.
- Everything for a recruitment agencyTwo audiences on one website. Process, payroll and compliance questions are answerable, application outcomes never are.
- Installing on your own domain when the portal also holds your clientsOne portal, several client domains, a footer field stored per domain. Where the tag goes, and why the gated case studies stay unread.
- Vacancies move faster than the material on a Rails agency siteTurbo means the visitor never reloads, and a role withdrawn on Friday is still in the assistant's material on Monday morning.
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.