Skip to content

Add canonical link tags for item pages and bitstream downloads#5172

Draft
bram-atmire wants to merge 1 commit intoDSpace:mainfrom
bram-atmire:feat/4509-canonical-links
Draft

Add canonical link tags for item pages and bitstream downloads#5172
bram-atmire wants to merge 1 commit intoDSpace:mainfrom
bram-atmire:feat/4509-canonical-links

Conversation

@bram-atmire
Copy link
Member

References

Description

Adds <link rel="canonical"> to item page HTML heads and a Link HTTP header with rel="canonical" to bitstream download responses, improving SEO by declaring preferred URLs.

Instructions for Reviewers

List of changes in this PR:

  • New SeoConfig interface (src/config/seo-config.interface.ts) with canonical.items and canonical.bitstreams boolean settings (both default to true)
  • HeadTagService: injects LinkHeadService, adds <link rel="canonical"> pointing to the simple item view URL (via getItemPageRoute()), and removes it on every route change. This covers both simple (/items/{uuid}) and full (/items/{uuid}/full) views — the canonical always points to the simple view. Entity pages (/entities/{type}/{uuid}) get their own canonical. Handle URLs (/handle/{p}/{s}) already 301-redirect, so no canonical is needed there.
  • BitstreamDownloadPageComponent: adds <link rel="canonical"> to the HTML <head> (works for both SSR and client-side rendering) and appends rel="canonical" to the Link HTTP header (SSR only). Implements OnDestroy to clean up the tag.
  • Tests added for both HeadTagService and BitstreamDownloadPageComponent covering: tag added for Items, not added for non-Item DSOs, not added for non-DSO pages, removed on route change, respects config false, and cleanup on destroy.

How to test:

  1. Build with SSR: npm run build:ssr && npm run serve:ssr
  2. Visit an item page, view page source — confirm <link rel="canonical" href="https://your-host/items/{uuid}"> is present in the <head>
  3. Visit the full item page (/items/{uuid}/full), view source — canonical should still point to /items/{uuid} (without /full)
  4. Visit an entity page (/entities/{type}/{uuid}) — canonical should point to /entities/{type}/{uuid}
  5. curl -I https://localhost:4000/bitstreams/{uuid}/download — confirm the Link header contains rel="canonical"
  6. To test the config toggle, set seo.canonical.items: false or seo.canonical.bitstreams: false in your config and verify the canonical tags are no longer added

New configuration (in config.yml or environment config):

seo:
  canonical:
    items: true        # default: true
    bitstreams: true   # default: true

Checklist

  • My PR is created against the main branch of code (unless it is a backport or is fixing an issue specific to an older branch).
  • My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
  • My PR passes ESLint validation using npm run lint
  • My PR doesn't introduce circular dependencies (verified via npm run check-circ-deps)
  • My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
  • My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
  • My PR aligns with Accessibility guidelines if it makes changes to the user interface.
  • My PR uses i18n (internationalization) keys instead of hardcoded English text, to allow for translations.
  • My PR includes details on how to test it. I've provided clear instructions to reviewers on how to successfully test this fix or feature.
  • If my PR includes new libraries/dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
  • If my PR includes new features or configurations, I've provided basic technical documentation in the PR itself.
  • If my PR fixes an issue ticket, I've linked them together.

Adds <link rel="canonical"> to item page HTML heads and a Link HTTP
header with rel="canonical" to bitstream download responses. This helps
search engines identify the preferred URL for each page, preventing
self-competition between /items/{uuid}, /entities/{type}/{uuid}, and
/items/{uuid}/full routes.

Both features are configurable via seo.canonical.items and
seo.canonical.bitstreams settings (enabled by default).

Refs DSpace#4509

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

SEO: DSpace should be able to declare its item pages and bitstream links as canonical

1 participant