A desired word appearing in an address can also occur on a lookalike host or another path. Conversely, one added tracking parameter can make an exact comparison reject a valid search. I separated exact destination equality from route-based expectations.
Preserve whole-destination semantics for exact equality
An exact destination expectation parses both values and compares their normalized href. It is not a substring search. Path, query and fragment remain part of the whole destination being compared. That meaning stays useful when a task requires a precise target.
Parser normalization also differs from content identity. Two representations resolving to one address do not establish equal page content or account state. A matching address could still display a login screen, so destination equality cannot establish every workflow outcome.
Bind route matching to origin and pathname first
A route expectation requires equal origin and pathname. Another host is not accepted merely because its name contains the desired text. Similarly, a search path differs from a longer path with a similar prefix.
This permits additional query metadata while retaining the intended service and route. Origin includes protocol and port semantics as well as the host text. A change of scheme or a different nondefault port is not merely extra tracking metadata. A sophisticated comparison still checks the wrong destination if the expectation itself is wrong. The caller owns the intended absolute destination; the tool consistently applies that contract.
Count repeated query pairs instead of collapsing them
For each requested key-value pair, the matcher removes one matching available pair. Requiring the same pair twice needs two actual occurrences. Converting query parameters into a simple dictionary would discard multiplicity.
Additional actual parameters are allowed by route matching. Omitting a necessary query can therefore admit another search on the same path. Fragment equality is not a route condition either. Choosing the expectation requires understanding which differences it deliberately ignores.
Reject relative fragments before dispatch
A query fragment or bare search word may communicate intent, but it is not an absolute expected destination. The convenience API rejects invalid URL expectations before dispatch, and contract tests reject relative expectations too.
Repair should supply the intended absolute route or another appropriate condition rather than repeatedly pressing Enter and calling it a browser defect. Earlier comparison evidence separated caller expectation errors from actual input-path repairs. Identifying the failing layer makes the correction meaningful.
Test rejection of lookalike destinations too
The unit test accepts an intended route with extra tracking values and rejects a lookalike host, different path and wrong query. Exact equality still rejects the added values, and missing repeated query pairs fail.
I read the matcher, unit and security tests and the page API's pre-dispatch check. This is not another external navigation test. URL parsing and query comparison do not establish business meaning across every redirect or confirm service authentication. Navigation and the subsequent operation need separate outcome checks.
Turn similar enough into an explicit contract
A business tool also needs to define what makes a destination correct. Whole-address equality and a matching route with required conditions are different requirements. A comparison that passes conveniently is not necessarily accurate.
Separating the expectations makes the caller deliberately choose which differences may be ignored. The decision is not simply strict versus loose; it defines the equivalence needed by the work. An explicit criterion avoids rejecting valid results unnecessarily while preventing another destination from being counted as success.