Why we use metadata factories instead of copying SEO tags page by page

Metadata is repetitive enough to tempt copy and paste, but important enough that copy and paste becomes dangerous.

Every public page may need a title, description, canonical URL, Open Graph title, Open Graph description, social image, Twitter card, robots behavior, and sometimes publication metadata.

If those fields are assembled independently on every route, they drift.

We prefer shared metadata factories.

The page supplies meaning, the helper supplies consistency

On several of our sites, a route calls a helper with a small set of page-specific facts: title, description, path, image, and any article-specific dates or author information.

The helper turns those facts into the complete metadata object expected by Next.js.

That means the route still owns the important editorial decision. It decides what the page is called and what it is about.

The helper owns the repetitive mechanics.

Canonical URLs are a good example

A canonical should use the production origin and the correct route.

Rather than constructing that URL differently in every page, our metadata utilities centralize the production site URL and a helper for turning relative paths into absolute URLs.

That reduces subtle bugs such as preview hostnames leaking into canonicals, missing slashes, relative social image URLs being interpreted incorrectly, or one route using a different hostname convention from the rest of the site.

Social metadata should not be an afterthought

A page can have a perfectly good HTML title and still share badly if Open Graph or social card data is incomplete.

The factory pattern makes social metadata part of the normal page contract.

If you provide title, description, path, and image, the helper can produce a consistent Open Graph object and a matching large-image card.

That is better than treating social metadata as a launch-day checklist item.

Article pages need different fields

A normal service page and an article are not identical.

On one codebase, the shared metadata function accepts a page type. When the page is an article, the helper can include published time, modified time, and author data. For ordinary pages, it produces website metadata instead.

That lets the content type drive the details without duplicating the entire function.

Environment behavior can live there too

On another project, the same metadata layer also participates in preview-indexing rules.

Production metadata returns index and follow. Preview metadata returns noindex and nofollow.

That is useful because every route that uses the helper inherits the deployment rule automatically.

We may reinforce that rule at the response-header level too, but the metadata remains internally consistent.

Why not set one global title and call it done?

Because metadata is not boilerplate in the editorial sense.

A service page should describe that service. A location page should describe that location. An article should describe its actual topic.

The factory does not homogenize those pages. It standardizes the mechanics around their unique content.

Centralization makes audits practical

If we decide every social image should resolve to an absolute production URL, there is one utility to inspect.

If we want article pages to include modified dates consistently, there is one branch of the helper to review.

If we want to change how the site name is appended to social titles, there is one place to do it.

The alternative is searching dozens of files for slightly different hand-written metadata objects and hoping none were missed.

The value is consistency under growth

This matters more as a site grows.

With five pages, duplicated metadata is annoying. With fifty pages across services, articles, locations, projects, and documentation, duplicated metadata becomes an operational problem.

Our goal is not to hide SEO in a helper. It is to make the mechanical parts reliable enough that page authors can focus on the parts that require judgment.