Search Auditor

This auditor targets the search page of the site (for example https://example.com/search), either the monitored URL itself or the page named by the searchPage preference. It fetches that page once, detects the platform, and runs the rules of the matching platform visitor. The first supported platform is Liferay; other platforms (for example WordPress) can be added as new visitors with their own rules and codes.

​

Preferences

These settings can be configured per monitored URL from the URL’s auditor configuration tab. Only resultSelector is required: the platform does not run the auditor for a URL until it is set (the Overview shows Needs configuration), so the 405 failure below only appears for runs started outside the platform.

​

How it works

1. Fetch — loads the search page with the 37 Audits user agent (Basic auth is honoured). If the page cannot be fetched, or answers HTTP 400 or higher, the audit is ERROR (500).
2. Detect — asks each visitor whether it recognises the platform. The Liferay visitor matches when the monitored stack lists Liferay, the response carries a Liferay-Portal header, or the HTML contains the Search Results portlet or Liferay.ThemeDisplay. No match is ERROR (501).
3. Validate — the resultSelector preference must be set (405) and must parse as a CSS selector or XPath (502). Nothing else runs until it does.
4. Probe (Liferay) — sends four requests to the search page, each bounded by timeoutSeconds:
   • ?q= — empty query, default page size.
   • ?q=* — wildcard query, default page size. Also discovers the Search Results portlet namespace and a pagination link.
   • ?q=&delta=101 — empty query with a page size one above maxDelta (plus the namespaced delta when known).
   • ?q=*&delta=101 — wildcard query with a page size one above maxDelta.
5. Count — on every answered probe, the elements matching resultSelector are counted. A probe that times out is a FAIL on its own and is not counted.
6. Redirect chain — links on the wildcard page and on its first pagination page are decoded looking for a redirect parameter that nests another one.
7. Aggregate — ERROR wins, then FAIL, then WARNING; if every rule passes, the audit is SUCCESS (200).

​

What it audits

Every row maps to one checkRule* method and one CheckCode. Codes 500–502, 405 and 200 apply to every platform; 300 and 400–404 belong to the Liferay visitor. A future platform visitor continues the same sequence. CheckCode suffixes use status ranges: 200 success, 300–399 warning, 400–499 fail, 500–599 error.

​

Output documentation

​

Risks and considerations

​

Uncapped page size is a denial-of-service vector

• Liferay reads the delta parameter to size the results page. Without a cap, ?delta=5000 makes the portal ask Elasticsearch for thousands of documents and render them all, on every request.
• Liferay caps delta at 200 by default, but custom themes, fragments and portlet configuration can raise or bypass it. This auditor expects maxDelta (100 by default) or less, and only ever asks for one result more than that.

​

Empty searches list the whole index

• With “Allow Empty Searches” enabled, ?q= returns every indexed document. That surfaces content that is only reachable by search (drafts, internal pages, documents) and makes scraping trivial.

​

Redirect chains break URLs

• Liferay portlets append the current URL as a redirect parameter so “back” navigation works. When a pagination link re-encodes a URL that already carries a redirect, every page change nests one more level. After a few clicks the URL is several kilobytes long, breaks caches and proxies, and eventually hits request-line limits.
• Links from other portlets on the search page (for example Asset Publisher) are scanned too, because the same mechanism affects them.

​

Timeouts are findings

• Liferay renders every result item server side. A request that cannot answer within timeoutSeconds (default 20) is a sign that the page size or the empty search is not capped, and is reported as a FAIL rather than an auditor error.
• Slow but correctly configured sites can raise timeoutSeconds up to 30 per URL.

​

What this auditor does not check

• It does not audit search relevance, indexing coverage, or the search bar on other pages.
• If the search index has maxDelta or fewer documents matching *, the delta rule cannot prove a violation and passes.
• If the results page has no pagination link, the redirect chain rule only inspects the results page itself.
• Counting depends entirely on resultSelector. A selector that matches nothing makes every count rule pass; verify it against the live page when configuring the URL.