Digital Hall of Fame Hyphenated Surname Search Rules for Inductee Profiles

Compound family names are common across every sport and every generation of school athletics. A cross-country standout from the 1990s may have a hyphenated surname that reflects a family naming tradition; a basketball captain from last decade may carry a hyphenated name that combines two recognized alumni family names from the same district. When the school’s recognition program captures twenty years of inductees, it may hold dozens of profiles with hyphenated surnames — all of them subject to the same entry inconsistencies that cause silent search gaps.

The gap is specific: most full-text search engines treat a hyphen as a token boundary character, splitting “Garcia-Lopez” into two separate index tokens, “garcia” and “lopez.” A visitor who searches “Garcia-Lopez” with the hyphen may match the full string; a visitor who searches “Garcia Lopez” with a space may match the two tokens but not the original hyphenated form; a visitor who searches “Garcia” alone may or may not match, depending on the platform’s search configuration. None of this behavior is visible to the athletic director who entered the name — until a community member reports that searching for a longtime local legend returns no results because they searched with a space instead of a hyphen.

A digital hall of fame web directory must return an inductee's profile whether a visitor types the full hyphenated surname, either element alone, or the name without a hyphen — consistent entry rules and verified search index behavior make this possible

Program Snapshot: Hyphenated Surname Search Rules for School Hall of Fame Platforms

Define the full scope of the name-handling policy before auditing existing entries or testing the search index.

Why Hyphenated Surnames Create Search Gaps in Recognition Platforms

Text search indexes break an input string into tokens — the individual words or word-like units that the index stores and compares against incoming queries. How a platform’s search index handles the hyphen character in “Smith-Johnson” determines whether visitors find the inductee or not.

Hyphen as word boundary (most common): The index splits “Smith-Johnson” into two tokens: “smith” and “johnson.” A query for “Smith-Johnson” may be split the same way, effectively searching for documents containing both “smith” and “johnson.” This produces matches for “Smith Johnson” (with a space), “Smith-Johnson” (with a hyphen), and even separate mentions of “Smith” and “Johnson” in the same document. However, it can produce false positives when a document mentions a different “Smith” and a different “Johnson” in the same profile.

Hyphen as non-tokenizing character (less common): The index treats “Smith-Johnson” as a single token — a complete, indivisible string. A query for “Smith Johnson” with a space does not match the token “Smith-Johnson” because it is two tokens, not one. A query for “Smith” alone does not match because the token is “Smith-Johnson,” not “Smith.” This approach is accurate for exact-match retrieval but fails for the partial and variant queries that real visitors submit.

Mixed behavior: Some platforms index the hyphenated form both as the full string and as individual tokens simultaneously, giving visitors the best of both approaches. This is the target behavior for a digital hall of fame, but it requires either platform configuration or a manual workaround using the alternate-name field.

Understanding which behavior your platform uses is the first step in establishing effective digital hall of fame hyphenated surname search rules.

Establishing consistent search behavior also supports the broader goal of maintaining accurate heading and navigation structure on search pages in a digital hall of fame, where name display in headings and the underlying search data must stay aligned.

Content Architecture: Hyphenated Surname Search Decision Table

The table below maps each common search scenario to the desired outcome and the configuration or entry practice that produces it. Use this as the reference document when defining the platform’s house style.

Entry Rule for the CMS

Apply one canonical form across every record: enter hyphenated surnames with the hyphen and no spaces — Garcia-Lopez, not Garcia - Lopez and not Garcia Lopez. The hyphen-without-spaces form is the standard typographic convention for compound surnames and the form that most search indexes tokenize consistently.

Where a school’s records include legacy entries that omit the hyphen (common in older data exports from student information systems), correct those entries to the canonical form during the next scheduled recognition platform update cycle.

For platforms managed through a cloud CMS with a scheduled publishing workflow, a batch name-correction pass can be performed by an IT administrator outside of public-facing update hours, preventing interim inconsistency from appearing in the live directory.

Execution Timeline: Plan → Audit → Test → Enforce → Refresh

Step 1 — Inventory All Hyphenated Surname Entries in the CMS

Open the recognition platform’s administrative CMS. Export or browse the full inductee roster. Search for hyphens (-) in the surname field to identify every entry with a compound name. For platforms without a dedicated surname field (where the full name is a single string), search for the pattern [A-Za-z]-[A-Za-z] to locate hyphenated entries.

Record each hyphenated-surname entry in a working spreadsheet with columns for: inductee ID, current CMS name form, sport, induction year, and any variant forms found in associated records (event rosters, photo captions, award citations). Variants appear frequently when name data has been pulled from multiple source systems — student information system exports, yearbook records, and manually entered profile data often use different conventions.

For each entry, document the single canonical form that matches the inductee’s legal or preferred name, using the hyphen-without-spaces convention. This canonical form becomes the corrected CMS entry.

Step 2 — Correct Inconsistent CMS Entries to the Canonical Form

For each entry where the current CMS form does not match the canonical form, update the record. Common corrections include:

• Smith Johnson → Smith-Johnson (space replaced with hyphen)
• Smith - Johnson → Smith-Johnson (spaces around the hyphen removed)
• SmithJohnson → Smith-Johnson (hyphen added between elements)

Update the surname field only. Do not change sport, year, or statistical data during a name-correction pass — the risk of accidental edits to other fields increases when making batch corrections.

After corrections are complete, re-export the roster and verify that no hyphenated entries appear in variant forms. A second export with a text comparison against the original confirms that only the surname fields changed.

Step 3 — Test the Search Index with the Full Hyphenated Form

Navigate to the public-facing inductee search page on the hall of fame web directory. Type the full hyphenated surname of a known inductee — for example, Garcia-Lopez — into the search field. Verify that the inductee’s profile appears in the results.

If the profile does not appear, the search index has not yet incorporated the corrected CMS entry. Re-index the platform (the process varies by platform — consult the vendor’s documentation for the scheduled or on-demand re-index option) and repeat the search.

Record the result: pass or fail.

Step 4 — Test the Search Index with the Unhyphenated Space Form

In the same search field, type the surname without the hyphen, using a space: Garcia Lopez. Verify that the same inductee profile appears in the results.

This test reveals whether the platform’s tokenizer treats the hyphen as a word boundary. If the profile appears, the tokenizer splits on the hyphen and the space-separated search query matches the two resulting tokens. If the profile does not appear, the platform treats Garcia-Lopez as a single non-tokenized string and the space-separated query does not match.

If the profile does not appear for the space-separated query: contact the platform vendor to confirm the tokenizer behavior and ask whether the hyphen can be configured as a word-boundary character. If the configuration change is not available on the hosted platform, use the alternate-name field (if available) to add Garcia Lopez as a searchable alternate, or ask the vendor to add the space-separated form as a supplemental index entry.

For platforms with a full-text database search layer, configuring GIN index policies for searchable athletic award profiles is the technical mechanism that controls how tokens are extracted from name fields — including whether hyphens generate separate tokens for each compound element.

Step 5 — Test the Search Index with Each Surname Element Separately

Search for only the first element of the compound surname: Garcia. Then search for only the second element: Lopez. Verify that the inductee’s profile appears for both single-element searches.

If either single-element search returns no results, the platform’s index is not producing individual tokens for the compound name’s parts. This is the search gap most frequently reported by school communities: a family member searches for a relative’s surname and finds nothing, even though the inductee is in the archive.

Document the result for each single-element test separately. Both must pass for the inductee’s profile to be reliably discoverable by visitors who know only one of the two surname components.

Step 6 — Set and Document the Alphabetical Sort Rule

Determine how the platform sorts inductees whose surnames are hyphenated. Two defensible rules exist:

Sort by the full compound surname as written: Garcia-Lopez sorts between all “Gar-” entries and all “Gas-” entries, treating the hyphen as a non-sorting character. This is the convention used in most library and archival catalogs and is the most predictable for visitors browsing an alphabetical roster.

Sort by the first element of the compound surname: Garcia-Lopez sorts with other “Garcia” entries. This is natural for visitors who expect to find the inductee by the first surname.

Both rules are valid; the critical requirement is that the same rule is applied to every entry. Choose one rule, document it in the recognition program’s editorial guide, and verify that the platform’s sort implementation matches.

For platforms that use the raw CMS entry to drive sort order, the hyphen-without-spaces canonical form sorts correctly under either rule. For platforms that tokenize before sorting, verify that the sort key is derived from the first token (the first surname element) consistently.

Step 7 — Verify Display Labels on Profile Headers and Search Results

Navigate to each inductee’s full profile page and to the search results listing. Confirm that the inductee’s name appears in the canonical form (Garcia-Lopez) rather than in any variant form. Check:

• The profile page heading (the inductee’s name as it appears at the top of the profile)
• The search results row (the name as it appears in the results list when searched by name)
• The alphabetical roster browse page (the name as it appears in the A–Z roster view)
• The kiosk display roster, if the platform powers both a web directory and a touchscreen kiosk

If any surface displays a variant form, trace the discrepancy to its source: a template that pulls from a different field, a kiosk data sync that has not picked up the corrected entry, or a cached display that has not refreshed since the CMS correction was saved.

Recognition programs that use autocomplete suggestions on touchscreen kiosk search interfaces must also verify that the autocomplete list displays the canonical hyphenated form as the suggestion text, not a variant form from a stale or unsynced data layer.

Touchscreen kiosk displays must present hyphenated surnames in the canonical form across the inductee roster, search results, and profile headers — and must return the profile when a visitor searches either the full compound name or either surname element alone

Step 8 — Document the House Style and Distribute to All Editors

Create a one-page entry guide for recognition program staff and any volunteers or contractors who enter inductee data. The guide should cover:

1. Enter hyphenated surnames with the hyphen and no surrounding spaces: Smith-Johnson, not Smith - Johnson and not Smith Johnson.
2. Capitalize each element as the inductee uses it: O'Brien-Clarke if that is the inductee’s own usage, not Obrien-Clarke or o'brien-clarke.
3. Check the inductee’s name against a primary source — a school letter of induction, a program document, or the inductee’s own confirmation — before finalizing the CMS entry. Do not rely on older roster exports, which often drop hyphens.
4. When an inductee’s name has changed over time (marriage, legal name change, preference update), enter the name under which the inductee is being honored and document the alternate name in the platform’s alternate-name or notes field.
5. After every new entry is saved, test the name in the public-facing search field using all three query forms: hyphenated, space-separated, and each element alone. Record the results in the platform’s audit log.

Distribute the guide to every person with CMS editing access before the next induction class is entered. For school programs that process one induction class per year, the ideal timing for distributing and reviewing the guide is four to six weeks before the new class data-entry window opens.

Step 9 — Re-Verify After Platform or CMS Updates

Platform updates — including search index library upgrades, theme changes, and CMS schema migrations — can change how the search engine tokenizes name fields. A tokenizer update that changes hyphen handling from word-boundary to non-tokenizing (or vice versa) will silently alter search behavior for every hyphenated surname in the archive.

Schedule a targeted search-verification pass immediately after any platform update: test at least three hyphenated-surname inductees using the full hyphenated form, the space-separated form, and each element separately. If results change relative to the pre-update baseline, investigate the platform change log and contact the vendor.

Schools building searchable digital trophy displays that serve both the web and a school hallway kiosk — including programs that have reviewed approaches to searchable awards on digital trophy case kiosk systems — should include hyphenated-surname search verification as a standard item in the post-update check protocol, since kiosk search interfaces frequently use a separate index layer that may not inherit tokenizer changes from the web layer automatically.

Display Integration: Web Directory, Kiosk, and QR-Linked Profile Pages

Hyphenated surname rules must produce consistent behavior across every surface where an inductee’s name appears.

Web directory search: The search field on the web directory landing page is the primary surface for name-based inductee lookup. All three query forms — full hyphenated, space-separated, each element alone — must return the inductee’s profile. Most web directory search implementations use a single server-side search index; a tokenizer configuration change at the index level propagates to all query forms at once.

Touchscreen kiosk roster and search: Kiosk interfaces frequently implement search as a separate JavaScript or native layer that queries the same CMS data through an API, but may apply different tokenization settings. Confirm with the recognition platform vendor whether the kiosk search layer shares the web search index or uses a separate configuration. If separate, the hyphenated-surname verification tests in Steps 3–5 must be run against the kiosk interface independently.

Alphabetical browse on the kiosk: Many kiosk interfaces display an A–Z roster that visitors can browse by letter tile. Confirm that the sort order for hyphenated entries follows the documented rule — and that the letter tile the inductee appears under is predictable. “Garcia-Lopez” should consistently appear under the G tile (for the first surname element) or be discoverable from the G tile by a browsing visitor. If the kiosk’s letter-browse function sorts on the full string including the hyphen, “Garcia-Lopez” will sort correctly under G. If it sorts on tokens, verify which token is used as the primary sort key.

QR-linked profile pages: Schools that place QR codes in physical trophy cases, hallway displays, and ceremony programs link directly to individual inductee profile pages. These deep-linked pages carry the inductee’s name in the profile header. Confirm that QR-linked profile headers display the canonical hyphenated form, not a variant pulled from a URL slug or a cached field that has not updated since the CMS correction.

Shared CMS name field architecture: Recognition platforms that manage inductee records through a cloud CMS often provide separate structured fields for first name, last name, and middle name. Where a hyphenated surname is the full surname — “Garcia-Lopez” as the complete last name, not two separate fields — enter it entirely in the last-name field. Platforms that split compound names across two surname fields (last name 1: Garcia, last name 2: Lopez) may produce different sort and display behavior; confirm with the vendor how the combined form is assembled for display and how the separate fields are indexed.

Reusable Checklist: Hyphenated Surname Entry and Search Verification

Copy this checklist into the recognition program’s editorial guide and complete it for each inductee with a hyphenated surname at the time of entry.

CMS Entry

• Surname entered in canonical hyphenated form with no spaces around the hyphen
• Capitalization verified against a primary source document (induction letter, official program, or inductee confirmation)
• No variant form (space-separated or unhyphenated) exists in any other field or associated record for the same inductee

Search Verification (run after saving the CMS entry)

• Full hyphenated form returns the inductee’s profile in the web directory search
• Space-separated form (no hyphen) returns the inductee’s profile in the web directory search
• First surname element alone returns the inductee’s profile in the web directory search
• Second surname element alone returns the inductee’s profile in the web directory search
• Kiosk search returns the inductee’s profile for the full hyphenated form (if the kiosk uses a separate search layer)
• Autocomplete suggestions (if enabled) display the canonical hyphenated form

Display Verification

• Profile page heading displays the canonical hyphenated form
• Search results listing displays the canonical hyphenated form
• Alphabetical roster browse places the inductee under the correct letter tile
• QR-linked profile page (if a QR code exists for this inductee) displays the canonical hyphenated form

Hyphenated surname search rules must produce consistent results across every device and interface — desktop web directory, tablet browser, mobile, and touchscreen kiosk — so that community members find the inductee they are looking for regardless of how they type the name

Measurement: Indicators of a Well-Configured Hyphenated Surname Search Implementation

Run the full check for every inductee with a hyphenated surname: at the time of initial entry, after any CMS correction, and after any platform update. For schools with fewer than ten hyphenated-surname inductees, the full check takes under fifteen minutes. For programs with larger archives, a spot check of five to ten entries covers most risk.

Schools that have reviewed best practices for searchable athletic awards databases in the context of recognition platform data integrity should apply the same verification discipline to hyphenated surname entries: the quality of the recognition archive depends on both what data is entered and whether visitors can retrieve it reliably.

The community impact of accurate digital hall of fame hyphenated surname search is direct: when an alumnus brings family members to the school’s recognition display at a reunion, a championship celebration, or an induction ceremony, and searches for their own family name, the archive should return the inductee without requiring the visitor to guess the correct punctuation. A search that fails because a hyphen was missing from the CMS entry — or because the search index does not split on hyphens — leaves a well-recognized community member invisible in the program that was built to honor them.

FAQ: Digital Hall of Fame Hyphenated Surname Search

Should “Garcia-Lopez” sort under G or under L in the alphabetical roster?

The standard in most archival and library catalog practice is to sort by the first element of the compound surname — G for Garcia-Lopez — treating the full hyphenated string as a single surname that begins with its first letter. This approach is the most predictable for visitors browsing an alphabetical roster, because they expect to find “Garcia-Lopez” by looking under G, the same letter they would use to find “Garcia.” The alternative — sorting by the second element — creates roster inconsistency because it separates an inductee from other members of the same primary family name. Choose one rule, document it, and verify that the platform’s sort implementation matches. Most platforms sort on the raw string, which places “Garcia-Lopez” correctly under G when the canonical entry form uses a hyphen without spaces.

What if an inductee’s name has changed — for example, a maiden name that became a hyphenated married name during or after their playing years?

Enter the name under which the inductee is being recognized in the hall of fame — typically the name they used during their playing years, which is the name the community knows them by. If the inductee prefers to be listed under their current legal name, honor that preference and add the historical name (the name used during their athletic career) in the platform’s alternate-name or alias field. Configure the search index to search the alternate-name field alongside the primary surname field so visitors who remember the inductee by their earlier name still find the profile. Document the name-change context in the inductee’s profile notes for future editors who may encounter the discrepancy and wonder why the name in old newspaper archives differs from the current CMS entry.

What if a visitor types the name without any hyphen or space — for example, “GarciaLopez” or “garcialopez” as a single string?

This form — no hyphen and no space between elements — is a distinct string that does not match the canonical form or either separate element by conventional tokenization. Most platforms will not return the inductee’s profile for this query, and that is an acceptable outcome; the query form is not a standard punctuation variant but a data-entry error or a mobile auto-correct artifact. If the platform offers fuzzy-match or approximate-string search, it may surface the inductee through edit-distance matching. Schools that want to handle this case can add GarciaLopez as an alternate-name entry, but this is an optional enhancement rather than a baseline requirement.

Does the hyphen handling rule change on the touchscreen kiosk compared to the web directory?

It depends on whether the kiosk search layer shares the web search index or uses a separate implementation. When both surfaces query the same search API, a tokenizer configuration change propagates to both automatically, and the verification tests described in Steps 3–5 apply equally. When the kiosk uses a separate search layer — common in platforms where the kiosk runs a native app that queries the CMS through a different API endpoint than the web directory — the hyphen tokenization behavior may differ, and the verification tests must be run against the kiosk search interface independently. Ask the recognition platform vendor directly: does the kiosk search interface use the same search index and tokenizer configuration as the web directory, or a separate one? The answer determines how many separate verification passes are needed.

How should editors handle a hyphenated surname that includes an apostrophe in one element, such as “O’Brien-Clarke”?

Enter it exactly as the inductee uses it: O'Brien-Clarke. The apostrophe in a name like “O’Brien” is a possessive or elision marker that is part of the name’s conventional spelling, and it should not be removed or replaced with a straight quote. The search index may or may not tokenize on the apostrophe — most platforms treat it as a non-tokenizing character, producing a single token “O’Brien” rather than splitting into “O” and “Brien.” Test the entry using all relevant query forms: O'Brien-Clarke, O'Brien Clarke, OBrien-Clarke, OBrien Clarke, O'Brien, and Clarke. Document which forms return the inductee’s profile and note any gaps in the alternate-name field.

Should hyphenated surnames be entered differently in the slug or URL for the inductee’s profile page?

URL slugs cannot contain hyphens with the same meaning as name hyphens, because hyphens in URL paths serve as word separators in SEO and web conventions. A profile URL slug for “Garcia-Lopez” should use a different separator or drop the hyphen entirely — for example, /inductees/garcia-lopez-sport-year/ where the first hyphen is the slug separator and the name elements read as garcia and lopez. The slug is a technical URL component, not a display field; the display name on the profile page should still use the canonical Garcia-Lopez form. Do not copy a URL slug back into the CMS name field as the canonical form — the two fields serve different purposes and must be maintained separately.

Rocket Alumni Solutions builds digital recognition platforms for schools, athletic programs, and university alumni offices. Explore the digital hall of fame platform to see how inductee data entry, search configuration, and display labels are managed for every name in the archive — including inductees with hyphenated, compound, or historically variant surnames.