What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
For a site with many pages, a single dynamic image route can generate social cards from the same page registry that supplies page content. Nakodo’s author, Daniel Pertu, reports using that approach for 75 of the site’s 76 public URLs, while the homepage uses Next.js’s opengraph-image file convention. The split is a project-specific design choice, not a framework requirement; check the behavior against the Next.js version in your app.
How Nakodo divides its social-card routes
In an article published October 5, 2026, Daniel Pertu reports that Nakodo’s sitemap has 76 public URLs: 63 content entries and 12 hand-built pages, plus the homepage. He says the homepage is the exception to the shared route: the other 75 cards are served through a project-owned catch-all route. These are figures reported by the author, not an independent audit. Pertu’s article
The homepage uses the route-level opengraph-image convention. For other pages, a URL such as /pricing gets its card from /og/pricing. The approach separates a one-off homepage image from a reusable image endpoint for many known pages.
When to use a file convention or a shared route
| Consideration | Route-segment image convention | Centralized catch-all route |
|---|---|---|
| Useful fit in this case | A site-wide, one-off homepage image | Cards for many pages, such as Nakodo’s reported 75 |
| Content source | Route metadata and image implementation | Can reuse an existing page registry |
| Rendering code | Convenient when only one image is needed | One renderer can serve multiple page paths |
| Allowed paths | Handled through the route-segment convention | Can be restricted to paths enumerated at build time |
| Route-specific logic | Generated images can receive route params | Must map each requested path to the appropriate card data |
Next.js documents both metadata image conventions and generated images that can use route params, so the choice is architectural rather than a framework prohibition. Its documentation says the opengraph-image convention associates an image with a route segment and connects it to the route’s head metadata. Next.js metadata file conventions
#1 Best Overall
How the shared route can reuse page data
Pertu’s implementation enumerates known page paths with generateStaticParams, then looks up the card title in the same registry used for page content. It prefers ogTitle when present, falls back to h1, and then uses a static-card fallback. This avoids maintaining a second slug list solely for image generation.
The route constructs the card from that page data. A defensive missing-title check returns a 404 when a path has no usable title. The article gives /og/pricing and /og/how-it-works as examples returning 200 image/png, and /og/nonsense-page as an example returning 404; these are the author’s reported examples, not independently reproduced results.
Restrict generation to known pages
The article sets dynamic = "force-static" and dynamicParams = false. Current Next.js documentation says generateStaticParams can generate paths at build time; with dynamicParams = false, a dynamic path not returned by that function responds with 404. Together, these settings make the registry the boundary for which card routes are valid. Verify the exact route-segment behavior in the documentation for your installed version.
- Enumerate the pages. Return the known route params from
generateStaticParams, using the page registry as the source of truth. - Disable unlisted dynamic paths. Set
dynamicParams = falsewhen paths outside the generated list should not resolve. - Render from registry data. Resolve each route to its title and section label, and return 404 if the page cannot produce a valid card.
Next.js generateStaticParams documentation
Fit long titles and keep the section visible
Variable-length titles create a layout problem: a fixed large font can overflow the image, while making every title small wastes space on short headings. Pertu’s solution steps the title size down as character count grows:
| Title length | Font size in the author’s implementation |
|---|---|
| 36 characters or fewer | 76 pixels |
| More than 36 and up to 60 characters | 64 pixels |
| More than 60 characters | 54 pixels |
The cards show the top-level section rather than a long route path. For example, the section label can come from the first segment of a path such as /guides/something. That keeps the label legible without asking the image to display the full URL.
Account for renderer-specific constraints
Card generation depends on the image renderer, not only on Next.js routing. Pertu says the renderer used for this project could not read WOFF2 fonts, so the repository includes local TTF files for Besley, Archivo, and IBM Plex Mono. He also found that the layout engine required explicit display: flex. Treat both details as observations about that renderer and implementation—not universal rules for Next.js or every image-generation library.
Using local font files also avoids relying on a remote font request during builds in this setup. If you use a different renderer, confirm its supported font formats and layout behavior rather than copying these constraints blindly.
Quick Recap
What to verify before adopting the pattern
- Check the metadata image convention, dynamic route behavior, and static parameter handling against the Next.js version installed in your project. The current documentation cited here was last updated February 27, 2026.
- Confirm that each public page appears in the registry and resolves to an intentional card title; decide explicitly how missing titles should be handled.
- Test representative short, medium, and long titles, along with nested paths, using the renderer and fonts that will run in your build.
- Validate the generated image response for both known routes and paths that should be rejected.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
