Recruitment and the member panel — a guild site that converts

A Discord post asks for "healers, DM". That works for friends. For someone arriving from outside, it does not state hours, loot rules, or whether the guild still exists. Recruitment on the guild site exists for that person: a page that answers before there is a conversation, and a clear path into the member panel after the yes.

The site lives on hosting. Battlehorns is that hosting for gaming communities, not the metal band. The internal panel — members, events, loot, resources — is GuildOps. Putting both on the same public page is like leaving the loot sheet in the shop window.

What applicants need to see

• Game, mode, and schedule in one sentence. "Heroic raid, three nights, 21:00–00:00 Lisbon" filters better than a paragraph about how the guild is a family.
• What you want right now, not "we always need people". Concrete spots.
• What you offer without inventing it. A stable calendar, coaching if it exists. Prizes that do not exist drive people out when they join and find out.
• Rules that sting: attendance, loot, mandatory mic, age. Hiding them until the trial wastes everyone's time.
• Minimum proof: one result, one light image, the officers' names.

An earlier sketch lives in the recruitment page guide. Here the focus is the whole funnel: from the window to the member record, on hosting and in GuildOps.

The landing page

The recruitment landing is not the entire home page. It is a URL you can paste in Discord, in a league sheet, and in a bio: /recrutamento. It fits a phone screen.

1. A title with the opening, not only the guild name.
2. Three blocks: we want, we offer, we require.
3. One button to the form. Another, secondary, to Discord, for people who already know the house and only want voice.
4. No background video. On the reference free plan traffic is 5 GB a month. The limits are in free hosting.

Whoever maintains the page updates openings when they close. A tank spot from four months ago is false advertising.

Forms

The form filters. It does not replace the trial. Fields worth asking: in-game name, role, region and timezone, real hours, a profile or tracker link, and a short note on why they want to join. That is enough.

On Battlehorns hosting that is a candidatura.php file using PDO or mysqli with prepared statements, writing into the free plan's single MariaDB database. The visitor never sees the password. Do not ask for the game-account password. Do not store applicant passwords: this form does not need accounts.

• A reply within 48 hours, even if it is "still reading".
• One person owns the queue, not "the officers will see it".
• A trial with an end date, written down. An infinite trial is a spot held by a maybe.

A queue that does not need expensive software: the application lands in the table, the officer marks "call to voice / decline / trial". The voice call is thirty minutes for schedule, mic, and whether they read the rules. The trial lasts two weeks or four events, whichever ends first, and is written on the GuildOps record. At the end they become a member or they leave, with one sentence of reason. Guilds that "let it ride" collect eternal trials and openings the landing still advertises.

For a month, measure one thing: how many visits to the openings page became a form, and how many forms became a trial. Visits and zero forms means the text does not answer the questions above. Forms and zero replies within 48 hours means the problem is no longer the site.

How to publish the file is in the setup tutorial. If you would rather use a builder with applications already built and nobody will touch PHP, that choice is legitimate and covered in hosting versus builders and the platform comparison.

The member area

When you say yes, the person stops being a row in the applications table and becomes a member. That step should not be "here, look at the loot channel". It should be a record.

In GuildOps the record has the role (trial or member), and from there events and loot stop living only in chat. The public site does not need to repeat the record. It needs a "members" link that takes people who already joined to the panel, and that does not show the loot bank to someone still on the form.

Common mistakes: an HTML roster nobody updates; a Discord role granted before the person has read the rules; FTP access "so the member can upload a photo". If there is a photo, they send it to an officer. FTP belongs to whoever publishes the site — one user on the free plan.

Discord, in the right place

• From the Discord recruitment post to the https:// openings page, not to a loose invite as the only step.
• From the page to the invite, after the person knows the schedule. Or to the form, if you want to filter before voice.
• From the rules channel to the rules URL on the site, so there are not two versions.

The logic is in Discord and your website. Invites that expire in hours are not an address. The domain or subdomain is. When your own name matters for a league, see a custom domain.

How to build this on Battlehorns

1. Register with the Discord account of the officer who will handle applications.
2. Order the plan on shared hosting. On the free plan, publish the landing and the form inside 700 MB.
3. Test the form yourself, over HTTPS, and export the database. Support will not write the PHP for you; it helps with FTP, the subdomain, and the certificate.
4. Create the guild in GuildOps and add the trial on the day you say yes, not the following week.
5. Review openings when each one closes. A true page converts better than a complete false one.

The guild site does not need to look like a portal. It needs to tell the truth about the opening, store the application, and not mix the loot bank with the shop window. The rest of the stack — performance, SSL, when to pay — is in the web hosting guide for communities.

In this series: free guild hosting, hosting or a builder, the hosting guide, GuildOps, the setup tutorial, the platform comparison, and recruitment that converts.