My og:image URLs were broken for months. baseURL was the culprit.

The symptom

#

Share cards without images, that was the visible part. View source on any page and the metadata told the fuller story:

<link rel="canonical" href="/">
<meta property="og:image" content="/img/og-default.png">

Both relative. The Open Graph spec wants og:image to be a full URL, and social scrapers do not resolve relative paths against the page they happen to be scraping. To LinkedIn or Slack, that image simply does not exist. Same for rel="canonical": a canonical of / tells a crawler nothing about which site this content belongs to.

Nothing in day-to-day use surfaces this. Browsers resolve relative URLs without complaint, so the site looked healthy for months while every machine-facing tag it emitted was useless.

Investigation

#

The config had:

# config/_default/hugo.toml
baseURL = "/"

Hugo’s absURL builds absolute URLs by joining against baseURL. Join against "/" and you get strings that still start with /. Internal navigation never noticed because Blowfish builds its links relatively. The breakage was confined to exactly the outputs I never looked at: canonical tags, Open Graph metadata, the RSS feed’s self link, and every <loc> in the sitemap.

Digging further turned up a second, related fossil: a hand-written static/robots.txt pointing crawlers at https://nickboy.github.io/sitemap.xml. Blowfish ships a robots.txt template that derives the sitemap URL from baseURL, but in this repo the static file is what ended up in the build output, hardcoded domain and all.

And it was hardcoded to the wrong domain, because this site answers on two.

Root cause: two domains, both claiming to be canonical

#

The primary deployment is Cloudflare Pages behind nick-liu.com. A GitHub Actions workflow also publishes the same content to GitHub Pages at nickboy.github.io as a backup. That workflow built with its own override:

hugo \
  --gc \
  --minify \
  --baseURL "${{ steps.pages.outputs.base_url }}/"

So the mirror’s pages carried canonicals pointing at the mirror. Two hostnames serving identical content, each declaring itself the original. Google’s guidance on duplicate content is direct about this setup: pick one canonical URL per piece of content and make every duplicate point to it. A backup that self-canonicalizes competes with the primary for ranking instead of backing it up.

The fix

#

Three changes, all small:

# config/_default/hugo.toml
baseURL = "https://nick-liu.com/"

Then delete static/robots.txt entirely. With the real domain in baseURL, the theme’s template generates the correct file on its own:

User-agent: *
Allow: /
Sitemap: https://nick-liu.com/sitemap.xml

Finally, drop the --baseURL override from the GitHub Pages workflow. The mirror now builds with the same config as the primary, so its canonical, og:image, RSS, and sitemap URLs all point at nick-liu.com. Navigation on the mirror still works because internal links are relative. The only absolute URLs are the machine-facing ones, and those now agree about who the real site is.

One loose end I checked before shipping: with an absolute baseURL, Cloudflare Pages preview deployments also emit nick-liu.com canonicals. That is fine. Cloudflare serves previews with an X-Robots-Tag: noindex header, so they never enter the index in the first place.

Lessons

#

• baseURL = "/" breaks exactly the tags you never look at: canonical, og:image, RSS, sitemap. The browser hides the damage; crawlers see all of it.
• A mirror that sets its own canonical is not a backup. It is a competitor.
• A file in static/ can silently shadow a smarter template your theme already ships. Check what actually landed in public/ before writing your own.
• Verify metadata from the consumer’s side. One paste into a social share debugger would have caught this on day one.

References

#

• The Open Graph protocol (og:image expects a full URL)
• Hugo configuration: baseURL
• Google Search Central: consolidate duplicate URLs
• Cloudflare Pages: preview deployments