fix(seo): restore the homepage OpenGraph image - #12593
Open
jd wants to merge 1 commit into
Open
Conversation
Member
Author
|
This pull request is part of a Mergify stack:
|
This was referenced Aug 28, 2026
Contributor
Merge Protections🔴 3 of 6 protections blocking · waiting on 👀 reviews, 🤖 CI and 🙋 you
🔴 👀 Review RequirementsWaiting for
This rule is failing.
🔴 🔎 ReviewsWaiting for
This rule is failing.
🟠 🤖 Continuous IntegrationWaiting for any of
Waiting checks:
|
There was a problem hiding this comment.
Pull request overview
This PR fixes missing OpenGraph metadata on the docs homepage by ensuring the OG image lookup resolves correctly when the pathname is /.
Changes:
- Add a homepage-specific fallback so an empty slug resolves to the
indexOpenGraph image. - Refactor the OG image filename construction to use a
slugvariable for clarity.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
jd
marked this pull request as ready for review
August 28, 2026 14:04
jd
force-pushed
the
devs/jd/agentic-readiness/restore-homepage-opengraph-image--fb9a23ea
branch
from
August 28, 2026 14:37
eb3dabd to
a98ca32
Compare
Member
Author
Revision history
|
`getOgImageUrl` strips the leading and trailing slashes off the pathname to build the image filename. For the homepage that pathname is `/`, so stripping left an empty string and the lookup missed — every docs page had an OpenGraph image and the homepage shipped `<meta property="og:image">` with no content. The homepage's collection id is `index`, which is what `getStaticPaths` names its image, so fall back to that when the slug comes out empty. Covered by a regression test that fails against the old expression. The generated-image set comes from the content collection and needs the Astro build pipeline, so the test stubs it and exercises the derivation, which is the half that was wrong. Change-Id: Ifb9a23ea2caa20d28489a4f21363d85ed5e3342c
jd
force-pushed
the
devs/jd/agentic-readiness/restore-homepage-opengraph-image--fb9a23ea
branch
from
August 28, 2026 15:09
a98ca32 to
b9a20ed
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
getOgImageUrlstrips the leading and trailing slashes off the pathname tobuild the image filename. For the homepage that pathname is
/, so strippingleft an empty string and the lookup missed — every docs page had an OpenGraph
image and the homepage shipped
<meta property="og:image">with no content.The homepage's collection id is
index, which is whatgetStaticPathsnamesits image, so fall back to that when the slug comes out empty.
Covered by a regression test that fails against the old expression. The
generated-image set comes from the content collection and needs the Astro build
pipeline, so the test stubs it and exercises the derivation, which is the half
that was wrong.