How We Use Dynamic SEO on Our Own Marketing Site

There is a simple test for any developer tool: does the team behind it actually use it? If the answer is no, or if the answer comes with qualifications, that tells you something important about the product.

We built Dynamic SEO to solve the problem of managing SEO metadata at scale without tying every change to a code deployment. Our marketing site — the one you are probably reading this on — runs on Next.js App Router. It has landing pages, feature deep-dives, integration guides, and a growing blog. It needs SEO management. So we use our own product to provide it.

This post is an honest account of that implementation. What we set up, what worked immediately, what surprised us, and what the experience taught us about our own product's design.

Note: Dynamic SEO is currently in early access. The features described in this post reflect our internal usage and may evolve as we work toward general availability. Join the waitlist to be among the first to try it.

Why Dogfooding Matters

The term "dogfooding" comes from the idea of eating your own dog food — using the product you sell. It is overused in tech, but the underlying principle is sound. When you use your own tool daily, you encounter the same friction your customers encounter. You cannot hand-wave away rough edges when you hit them yourself every time you update a blog post's title tag.

For Dynamic SEO specifically, dogfooding serves three purposes:

1. Validation. If our integration does not work cleanly on a standard Next.js App Router site, we need to know that before customers find out.
2. Empathy. The setup experience, the dashboard workflow, the time-to-first-result — we experience all of it firsthand.
3. Credibility. When we tell customers that Dynamic SEO works with Next.js, we can point to our own site as a live example.

We do not treat this as a demo environment. Our marketing site runs the same integration package, the same middleware, and the same dashboard that every customer uses. There is no special internal version.

Our Site: What We Are Working With

The Dynamic SEO marketing site is a Next.js App Router application. It is not a trivial single-page site, but it is not an enormous e-commerce catalog either. It sits in the range that many SaaS marketing sites occupy: meaningful enough to need real SEO management, small enough that every page matters.

As of this writing, the site includes roughly 18 pages:

• Home page — the primary landing page with product positioning
• Product overview — detailed explanation of what Dynamic SEO does
• Features hub — summary of all platform capabilities
• 5 feature deep-dives — individual pages for URL management, meta tag control, structured data, analytics, and integrations
• Integrations page — install-path overview (WordPress plugin, Node middleware, REST API)
• About and Contact pages
• Blog — a growing collection of articles (you are reading one now)

Each of these pages needs a unique title tag, meta description, Open Graph tags for social sharing, and in some cases structured data markup. The blog posts additionally need Article-type structured data and proper canonical URLs to avoid duplicate content issues.

Before Dynamic SEO, all of this was managed through generateMetadata functions scattered across the codebase. Updating a single meta description meant changing a TypeScript file, opening a pull request, waiting for CI, and deploying. It worked, but it was exactly the kind of workflow we built Dynamic SEO to eliminate.

The Implementation

Setting up Dynamic SEO on our own site followed the same three-step process we document for customers. We did not take shortcuts or use internal APIs. The entire implementation touches three files.

Adding Dynamic SEO to our Next.js site required three changes: installing the package, adding a single middleware line, and placing one component in our layout. No per-page modifications were needed.

The integration ensures the correct URL context is available for metadata resolution. The layout-level component handles all metadata rendering for every page in the marketing section — title tags, meta descriptions, Open Graph tags, and structured data. Because it runs as a Server Component, everything is included in the initial HTML response.

We configured the integration to only apply to marketing pages, skipping application routes and API endpoints. Two environment variables in our hosting platform settings completed the setup.

That was the entire implementation. No per-page modifications. No changes to existing generateMetadata functions. The layout handles everything.

What We Manage Through Dynamic SEO

With the integration in place, we manage the following through the Dynamic SEO dashboard — the same dashboard our customers use:

Title Tags and Meta Descriptions

Every marketing page has a title and description managed through the dashboard. When we run an A/B test on positioning language, we update titles without touching code. When we realize a meta description is too long for mobile SERPs, we trim it in the dashboard and the change is live within an hour.

Open Graph and Twitter Card Metadata

Social sharing metadata is configured per-URL. Each page has a tailored OG title, description, and image reference. Blog posts use a template that automatically generates OG metadata from the post title and description, so new articles get proper social cards without manual configuration.

Structured Data

We use Dynamic SEO to manage two types of structured data:

• Organization markup on the home page and about page, providing search engines with our company details, logo, and social profiles.
• Article markup on every blog post, including author, publication date, and modified date. This is handled through a blog template — when we publish a new article, the structured data is generated automatically based on the template rules.

Canonical URLs

Every page has an explicit canonical URL set through Dynamic SEO. This is particularly important for our blog, where posts are accessible in both English and Swedish. The canonical URL plus hreflang tags ensure search engines understand the relationship between language variants.

Blog Metadata at Scale

This is where the template system proves its value. Rather than configuring SEO metadata for each blog post individually, we defined a template pattern for /blog/* URLs. The template pulls the post title into the meta title (with our brand suffix), uses the post description as the meta description, and generates Article structured data with the correct dates.

When we publish a new blog post, its SEO metadata is ready immediately. No dashboard visit required for routine posts — the template handles it.

What We Learned

Using Dynamic SEO on our own site over the past months revealed several things about our product that we might not have discovered through customer feedback alone.

1. The Layout-Only Approach Was the Right API Design

Early prototypes of the Next.js integration required a getDynamicSEO() call in each page's generateMetadata function. When we tried to implement that on our own site, the friction was immediately obvious. We had 18 pages. Each one needed a modification. Adding a new page meant remembering to include the call.

The layout-only approach — where DynamicSEOHead in the marketing layout handles all pages beneath it — was born directly from this experience. One change, complete coverage. This is the kind of API design insight that only comes from being your own customer.

2. Cache Timing Matters More Than You Think

We configured caching to balance freshness with performance. Changes propagate within the configured cache window. Initially we set an aggressive refresh interval, but in practice we almost never need metadata changes to propagate instantly. What we did need was for the cache to stay warm for performance.

We settled on a longer cache window as the right balance. Metadata changes take at most an hour to appear. In exchange, the vast majority of page loads hit the cache and add zero latency for the SEO metadata fetch. For a marketing site where metadata changes happen a few times per week, this is the right trade-off.

3. Path Exclusions Are Not Optional

We configured the integration to only apply to marketing pages, skipping application routes and API endpoints. Without this configuration, the integration would attempt to look up SEO data for routes that would never have metadata.

It did not break anything — the integration handles missing data gracefully — but it added unnecessary work on every request to the authenticated portion of the app. Configuring path exclusions eliminated this entirely. We now recommend path exclusions as a required part of the setup, not an optional optimization.

4. URL Validation Caught Real Issues

Our isSafeUrl validation rejected several URLs during initial setup. Some test URLs in our system had protocol-relative paths (//example.com/page) rather than absolute URLs. Others had trailing whitespace that was invisible in the dashboard but caused mismatches during URL resolution.

These were not security issues — they were data quality issues that would have caused silent metadata mismatches. The validation surfaced them immediately, and we fixed them in the dashboard. This experience led us to add more detailed validation error messages in the dashboard UI for all customers.

5. The Fallback Pattern Is Essential

We deliberately kept the existing generateMetadata functions in our page files. When Dynamic SEO has metadata for a URL, DynamicSEOHead renders it and Next.js uses those tags. When it does not (for example, for a brand-new page we haven't configured yet), the page's own generateMetadata provides the default.

This fallback pattern means the integration is purely additive. Installing Dynamic SEO cannot make your SEO worse — at worst, it changes nothing for pages that are not configured. This turned out to be important for our own confidence during rollout, and we suspect it matters even more for customers evaluating the product.

Results

After running Dynamic SEO on our marketing site for several months, the practical outcomes are straightforward:

• 100% metadata coverage across all marketing pages, managed from the dashboard rather than code.
• Zero-deploy metadata updates. Title tag changes, description adjustments, and structured data modifications go live without pull requests or CI pipelines.
• Template-driven blog SEO. New blog posts get complete metadata automatically. We publish an article and its SEO configuration already exists.
• Validated structured data. Our Organization and Article markup passes Google's Rich Results Test, and we have seen Article rich results appearing in search.
• No performance regression. With caching configured appropriately, the metadata fetch adds no measurable latency to page loads.

Advice for Teams Implementing Dynamic SEO

Based on our own experience, here is what we would tell teams starting with Dynamic SEO:

Start With the Marketing Site

If your application has both a public marketing site and an authenticated app (as ours does), start with the marketing site. It has the pages that need SEO the most, the metadata changes most frequently, and the team managing it (marketing) benefits the most from not needing engineering for every update.

Configure Path Exclusions From Day One

Define which path prefixes should be excluded from Dynamic SEO processing before you deploy. At minimum, skip your authenticated app routes, API routes, and framework-internal paths. This is not premature optimization — it is correct configuration.

Match Cache Timing to Your Actual Cadence

If you change metadata once a week, a one-hour cache window is generous. If you are actively A/B testing titles daily, you might want 15 minutes. Do not default to the shortest interval just because you can. Caching is your friend.

Keep generateMetadata as a Fallback

Do not remove your existing metadata configuration when you install Dynamic SEO. Let both systems coexist. Dynamic SEO takes precedence when it has data for a URL, and your existing metadata serves as the safety net. This makes rollout risk-free and rollback trivial.

Use Templates for Repetitive Patterns

If you have a blog, a help center, or any section with many pages following the same URL pattern, set up a template rather than configuring each URL individually. Templates are the difference between "this scales" and "this creates a new task for every page we publish."

Closing Thoughts

Dogfooding is not a marketing exercise. It is a quality control mechanism. By using Dynamic SEO on our own site, we found API design issues that led to better integration patterns, default configurations that needed adjustment, and edge cases that our test suite had not covered.

The product is better because we use it. Our marketing site's SEO is better because we manage it through a purpose-built tool instead of scattered generateMetadata functions. Both of those outcomes matter, and both required us to be honest about what worked and what needed to change.

Dogfooding revealed three things we did not expect: caching needs to match your content update frequency, fallback patterns are essential for resilient rendering, and path exclusion rules prevent the SEO layer from interfering with application routes. If you are evaluating a server-side SEO platform, test these three areas first.