Discoverability: apply rel=canonical to record detail and library pages
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
* Evergreen master and all TPAC versions
Search engines use the "<link rel=canonical>" convention to determine that, no matter how many variations on a URL you might generate through the likes of appending &query= parameters, etc, those URLs are all the same as the value of the href attribute in the <link> element.
A simplistic approach for record detail pages would be to simply trim records down to their record ID and throw away all query params. For the purpose of holdings, it might be more accurate to include the org_unit params. As that would make the number of possible URLs = # of records * number of OUs (that is, a huge ballooning in the number of URLs we would expect search engines to index), I'm tempted to avoid that for a first iteration.
Library pages are a little easier because we don't have to worry about query params, but we do have to choose between making either the shortname or the numeric ID the canonical version. As the holdings link to the shortname version of the library URL, that's what I'm tempted to go with.
A third consideration is that some consortial sites use different hostnames for different parts of their consortium (e.g. we have laurentian.
Changed in evergreen: | |
milestone: | 2.next → 2.8-beta |
Changed in evergreen: | |
status: | Fix Committed → Fix Released |
Please see http:// git.evergreen- ils.org/ ?p=working/ Evergreen. git;a=shortlog; h=refs/ heads/user/ dbs/lp1406451_ rel_canonical for an initial simple approach to providing rel=canonical declarations for library and record pages.
I haven't addressed the library numeric ID vs. shortname, because upon further reflection I think the best way to handle that would be to issue a 301 that redirects from the numeric ID to the shortname and should be the subject of a separate bug.