A website search checklist should test the entire find-and-recover path, not just whether the box returns something. Check discovery, labeling, query persistence, result relevance, empty states, keyboard operation, and the path from a result to the promised content.
Decide what search is for
Write down the content search covers and the visitor problems it should solve. The U.S. Web Design System describes search as useful when people know the terms they want or cannot find desired content in main navigation (USWDS search guidance). A tiny single-page site may not need a search feature, but a growing catalog or knowledge base should not make the main menu carry every destination.
Build a small test set from real page titles, common synonyms, abbreviations, misspellings, category names, and questions visitors may type. Include at least one query that should return no result. Define what a good first page looks like before tuning the engine.
Review the search control
Confirm that the control is easy to locate on the homepage and on deep pages. Use a visible or programmatically associated label and a submit button with an accessible name. USWDS recommends retaining the original terms on the results page so people can review, correct, and resubmit their query. Test that behavior with keyboard navigation and enlarged text.
Do not rely on a magnifying-glass image alone in the accessibility layer. If the compact visual design hides the word “Search,” keep an accessible text name for the input and button. Check focus visibility, touch size, and whether opening an expanded search control shifts or obscures nearby content.
Judge the results page
For each test query, record whether the leading results match the likely intent. Each result should provide a descriptive title and enough context to distinguish similar pages. Keep the query visible, show the approximate scope being searched, and make filters or sorting choices understandable if they exist. Avoid presenting internal identifiers or unexplained ranking signals.
W3C material notes that people benefit from multiple ways to locate pages, including search and sitemaps in addition to hierarchical menus (W3C navigation guidance). Search should complement navigation. If a common query repeatedly exposes a missing category or confusing label, repair the information structure too.
Design useful recovery states
A zero-result page should repeat the query, explain that nothing matched, and offer practical next steps: correct the spelling, use fewer terms, browse relevant categories, view a sitemap, or contact the business. Preserve the entered words so the visitor does not have to reconstruct the query. Distinguish “no matches” from a service error.
Also test stale links and permissions. A result that opens a missing or inaccessible page damages trust even if ranking is otherwise good. Remove retired content from the index or redirect it to a genuinely equivalent destination.
Record evidence and retest
Capture the test queries, expected intent, observed top results, empty-state behavior, defects, and date. Prioritize failures that block finding a key service, policy, support answer, or product. After changes, rerun the same set and add new queries from support requests and analytics only when those records are available and properly handled.
Sources
- Search — U.S. Web Design System
- Interaction: Navigating and Finding — W3C Web Accessibility Initiative