Roster pages that still work at twenty agents and more

A roster page keeps working past twenty agents when it is generated from one standardised agent record rather than hand-built, when finding a specific person is a filter or a search rather than a scroll, and when a written policy already decides what happens to a profile URL the day someone leaves. A grid of headshots is not a roster system. It is a picture of a roster, taken on one day, that starts drifting out of date immediately.

Why a grid of headshots stops working past a dozen agents

A headshot grid works while the roster is small enough for a visitor to take in with one glance and for one person to maintain by hand. Both of those conditions fail at the same size, somewhere around a dozen agents, and they fail quietly rather than all at once.

What the grid was actually doing

At six agents, the grid is doing something useful. It says the brokerage is a real firm with real people, it lets a visitor recognise the person they already met at an open house, and it is short enough that scrolling the whole thing costs nothing. The page is really a trust signal with a directory function attached, and at that size the trust signal is the larger half.

Where it breaks

At twenty-five agents, the directory function is the larger half, and the grid is bad at it. The failures stack up:

• Nothing sorts usefully. Alphabetical by first name is the default in most builds, which is the one order a visitor almost never wants.
• The page gets heavy. Twenty-five portraits at full resolution is a lot of image weight for a page whose job is navigation, and the guidance on serving images at the dimensions they actually render at applies directly here, since a roster tile is usually displayed at a fraction of the size of the file uploaded into it.
• Nobody can find a person by what they need. A visitor who wants a listing agent for a specific town, or an agent who speaks a specific language, has no way to express that on a page sorted by name.
• It goes stale on a schedule nobody owns. Someone joins, someone leaves, someone changes their phone number. If the grid is hand-coded markup, every one of those is a ticket.
• It gives search engines a wall of names. A single page carrying twenty-five short bios competes for nothing specific. Twenty-five pages each about one agent can each answer a named search.

The move is not to make the grid prettier. It is to treat the roster as generated output from a set of agent records, and to treat the individual profile as the page that actually does the work.

What an agent profile page is actually for

An agent profile page has three jobs, and they are more specific than “introduce the agent.” Get clear on the three and the content decisions stop being arguments about bio length.

Job one: answering a named search

Someone types an agent’s name. They met at an open house, they got a card, they were given the name by a friend, or they saw it on a sign. What they want is a page that confirms this person is real, shows what they currently have listed and gives them a way to make contact. If the brokerage site has no page for that name, the search resolves to a third-party portal profile, a social account or a competitor, and the brokerage is not part of the conversation.

Job two: a referral landing point

Referral traffic does not arrive through your homepage. It arrives as a link pasted into a message, an email signature, a relocation network’s directory entry or a QR code on a sign. All of those point at one URL and expect it to keep working. That makes the profile URL an asset with a maintenance obligation attached, which is the whole reason departures need a policy rather than an improvisation.

Job three: the byline destination

Every listing page carries a listing agent’s name. That name should be a link, and it should land on the profile. This is the internal linking backbone of the roster: with a hundred active listings across twenty agents, profiles receive links from across the site continuously, unlike a roster index that is linked once from the navigation.

What belongs on the page

Given those three jobs, the content list is short and mostly non-negotiable:

• Name, title and the office the agent works out of.
• A portrait shot to the brokerage’s photo spec.
• A short bio, three to five sentences, written in the brokerage’s voice rather than each agent’s.
• Markets served, as links to your market pages rather than as plain text.
• Specialties, drawn from a fixed list so they are filterable.
• Languages spoken, where the agent has told you and is comfortable listing them.
• Licence details as your state requires them, and any broker attribution your display rules call for.
• A live block of that agent’s current listings, pulled from the feed rather than typed in.
• A contact form that routes to that agent, plus direct phone and email if the brokerage’s policy allows it.
• Recently sold or past listings, if your display rules permit it and you want the depth.

Notice what is not on that list: a long personal essay, a hobbies paragraph, a floating testimonial carousel. Those are not wrong, they are just not what the three jobs need, and every one of them is a field somebody has to chase twenty people for.

The fields you have to standardise before a roster can be generated

A roster can be generated instead of hand-built as soon as every agent is described by the same set of fields, with the same allowed values. That is the whole precondition, and it is an operations job rather than a web job.

The reason to take the field list seriously is that real estate already has a standard vocabulary for this. The RESO Data Dictionary defines standard fields for members and offices as well as for properties, which means a brokerage that names its internal fields in line with that vocabulary has a much easier time when a feed, a CRM and a website all need to agree on what “office” or “member key” means.

The practical minimum list:

1. Agent identifier. A stable internal key that never changes, even if the person’s name does. This is what the listing feed joins against and what the profile URL should be derived from once and then frozen.
2. Display name. How the name is written everywhere, including the apostrophes and the middle initial, decided once.
3. Office. A reference to an office record, not a typed string. “Northside” and “North Side Office” are two different offices as far as a filter is concerned.
4. Status. Active, on leave, departed, or whatever set your brokerage actually uses. This single field drives whether a profile is listed, delisted or redirected.
5. Markets served. References to your existing market pages, not free text. If an agent’s market does not have a page yet, that is useful information.
6. Specialties. From a fixed list you control. Ten to fifteen options is usually enough, and the list should be reviewed once a year rather than extended on request.
7. Languages. From a standard language list, and only where the agent has confirmed it. How you present this is worth running past your own compliance counsel, since it touches how the brokerage describes its services.
8. Licence number and licensing state, in whatever form your regulator requires on public materials.
9. Photo, meeting a written spec: aspect ratio, minimum resolution, background, crop point.
10. Contact routing. The address or CRM identifier that enquiries from this profile are delivered to.

Once those exist as data, the roster index, the filters, the profile pages, the listing bylines and the sitemap entries are all generated from the same source. Adding an agent becomes one record, not a ticket.

Finding an agent: why search beats an alphabetical wall

Search and filtering beat an alphabetical list because visitors arrive at a roster with a requirement, not with a letter. Someone looking for “an agent who covers the lake side of the county and speaks Portuguese” cannot express that requirement against a wall of surnames, and will usually leave rather than open twenty profiles to check.

The filters worth building

Keep the filter set small and tied to fields you actually standardised:

• By office, which is the primary axis in any multi-office brokerage.
• By market, which is the primary axis for everyone else.
• By specialty, using your fixed list.
• By language, where the agent has opted in.
• A name search box that matches as the visitor types, for the large share of roster visitors who already know the name.

Filters not worth building: years of experience, sales volume, any ranking. Each either creates an internal ranking problem the brokerage does not want to referee, or drifts out of date the moment it is published.

How the filtered results should behave

Two rules make the difference between a filter that helps and one that quietly breaks things.

First, filtering should change what is on screen without turning every combination into an indexable page. A roster with five offices, twelve markets, fourteen specialties and eight languages produces an enormous number of possible combinations, and letting each one become its own crawlable URL creates a lot of near-identical thin pages. The base roster page and the per-office rosters are the pages worth having as pages.

Second, the profile pages themselves must not depend on the filter. They are real, permanent URLs that exist whether or not anyone used the roster to reach them, and they belong in the sitemap alongside your listing and market pages.

Per-office rosters in a multi-office brokerage

A multi-office brokerage needs a roster page per office as well as a combined one, because the office is a real place with its own address, phone number and local search footprint, and because that is how buyers and recruits actually think about the firm.

The structure that works is a shallow hub and spoke:

• The offices index lists every office with address, phone, hours and a link through.
• Each office page carries that office’s details, its own roster of agents, and its current listings.
• The combined roster lists everyone, filterable by office, for visitors who do not know or care which office someone sits in.
• Each agent profile names its office and links back to the office page.

Two operational points that decide whether this stays clean:

• An agent belongs to one primary office. Agents who genuinely work across two can be shown on both rosters, but one office is primary and appears on the profile. Without that rule, office counts stop adding up and nobody can tell which number is right.
• Office transfers are a data change, not a page rebuild. Change the office reference on the agent record and every roster updates together.

When an agent leaves: the profile URL question

What happens to a departed agent’s profile URL is a policy question the brokerage answers and the website implements, and the worst option is having no policy, because the default behaviour of most systems is to break the link.

That URL has inbound links from listing pages, from signs, from email signatures, from referral directories and possibly from other sites. Deleting it turns all of those into an error page. Google’s documentation on redirects describes a permanent redirect as the way to tell search engines that content has moved to a new location, which is the tool available here, but the tool only helps once you have decided where the person should go.

The three defensible policies

1. Redirect to the office or team page. The visitor lands somewhere real, connected to the brokerage, that can take their enquiry. This is the usual default for an agent who left the industry or moved to another firm.
2. Redirect to the agent who took over their book. Appropriate when the brokerage has formally reassigned the departing agent’s clients, and honest only when that reassignment actually happened.
3. Keep a reduced profile. For a retirement, or for an agent whose name still carries local recognition, a short page stating that the agent is no longer with the brokerage and pointing to the current roster is more useful than a redirect that hides the fact.

Whichever you pick, the mechanics are the same and should run off the status field:

• The profile leaves the roster index and every filter immediately.
• Listing bylines stop linking to it, and existing listings get reassigned to the covering agent in the feed.
• The page is removed from the sitemap.
• The redirect, if there is one, goes straight to its destination rather than through a chain of two or three hops, since each extra hop is another thing to maintain and another chance for a future change to break it.
• Enquiry routing for the old address is repointed the same day, which is usually the step that gets forgotten and the reason enquiries sit unread in a disabled mailbox.

Write the policy down once, in the offboarding checklist next to the badge and the lockbox codes. It takes one paragraph and it saves the argument every time.

Keeping profiles current without asking twenty people to write their own bio

Profiles stay current when the brokerage owns the structure and the agent owns a small, defined set of fields. Asking twenty agents to “send me your bio” produces four replies, three of them in the wrong length and tone, and one of them a resume.

What works instead:

• Write the bios in-house from a short intake. A five-question form, answered in four minutes, gives a marketing director enough to write three to five consistent sentences. Doing twenty of these is a day of work once, and the roster then reads as one firm rather than twenty freelancers.
• Make the structured fields self-service. Markets, specialties, languages, phone number and photo can sit behind a simple form the agent fills in during onboarding, with everything drawn from your controlled lists.
• Attach it to onboarding, not to a campaign. A profile is live before the agent’s first listing goes live, in the same checklist as the email address and the CRM seat. This is the single highest-leverage change for most brokerages.
• Review on a fixed cycle. Once or twice a year, send each agent their own profile as rendered, and ask only whether anything is wrong. A yes-or-no review gets answered. An open request for new copy does not.
• Let the live sections update themselves. Current listings, sold counts and market links should come from the feed and the data, never from a bio paragraph that says “over thirty transactions last year” and is wrong within a month.

Schema, internal linking and photo consistency

These three details separate a roster that merely exists from one that earns traffic, and all three are cheap once the underlying data is standardised.

Structured data

Each profile should carry structured data describing the person and their relationship to the brokerage. Google’s introduction to structured data markup explains that this markup helps search engines understand what a page is about, with the standing requirement that the markup describes what is actually visible on the page rather than a more flattering version of it. For a roster, that means the marked-up name, job title, office and contact details match what a visitor reads, and that an agent who has left is not still marked up as a current member of the organisation.

Internal linking

The links to build, in priority order:

1. Listing page byline to profile, on every listing. This is the highest-volume link on the whole site and the one most often left as plain text.
2. Profile to market pages, for every market that agent serves.
3. Profile to office page, and office page back to its roster.
4. Roster index to every profile, unfiltered, so every profile has at least one plain crawlable path to it.
5. Blog posts to profiles where an agent is quoted or credited.

Photo consistency

Photo consistency is the thing visitors notice first and the thing brokerages fix last. The spec is short: one aspect ratio, one crop point, one background treatment, one minimum resolution, and a rule that the brokerage arranges a shoot for new agents within their first month. Serve those images at the size they actually render at rather than shipping a print-resolution file into a small tile, which is the advice web.dev gives on image dimensions and which matters here because a roster page is a page made almost entirely of images.

A roster checklist before you build

Run the list before anyone starts designing:

1. Does every agent exist as a record with the same fields, or are profiles still hand-built markup?
2. Does every agent have a permanent profile URL derived from a stable identifier?
3. Can a visitor filter by office, market, specialty and language, and search by name?
4. Does every listing byline link to the listing agent’s profile?
5. Does every profile show that agent’s current listings, pulled live from the feed?
6. Does each office have its own roster page and its own contact details?
7. Is there a written policy for what happens to a profile URL when an agent leaves, and does the status field implement it?
8. Is there a photo spec, and a plan for getting new agents photographed inside their first month?
9. Do profiles appear in the sitemap, with structured data that matches the visible content?
10. Is there a fixed review cycle that asks agents to confirm rather than to write?

A brokerage that can answer yes to all ten has a roster that keeps working as the firm grows, instead of one that has to be rebuilt every time the headcount changes.

Want this built against your own roster and feed? Book a demo and we walk through a build at your agent count, or read the features list and pricing first. If you run more than one office, the multi-office franchises page covers the per-office structure in more depth, and the real estate teams page covers the smaller, faster-growing case.