A WordPress site built with Bricks can use several tools that touch search engine optimization. Bricks itself has page settings. An SEO plugin may add titles, descriptions, canonical URLs, robots directives, and structured data. A theme or another plugin can also contribute markup.
That flexibility is useful until two tools try to publish the same thing. The page source may contain two title tags, multiple meta descriptions, more than one canonical URL, or overlapping schema graphs. Sometimes the duplicates are visible in the HTML source but not obvious in the page design, so the issue can go unnoticed until a crawler or a site audit reports it.
The fix is usually not to turn everything off at once. First identify what is being output and by which tool. Then decide which system owns each part of SEO, preserve existing settings, and verify the rendered page after making changes.
This guide walks through that process for Bricks-based WordPress sites, including plugin migrations, fallback settings, schema, and a practical quality check.
What “duplicate SEO output” means
The phrase “duplicate metadata” can refer to several different problems. It helps to name the type before changing settings.
Duplicate title tags occur when the HTML has more than one
element. Search engines may choose how to interpret multiple titles, but the page has sent an unclear signal.</p>
<p>Duplicate descriptions occur when multiple meta name="description" tags are present. These are not always identical, but having several competing versions makes it harder to know which description is intended.</p>
<p>Conflicting canonicals happen when two or more canonical tags point to different URLs. This is especially important to investigate because each tag is trying to identify the preferred URL.</p>
<p>Conflicting robots directives can occur when one output says index, follow and another says noindex, nofollow, or when settings are repeated inconsistently.</p>
<p>Duplicate structured data may mean two separate JSON-LD graphs describe the same entity or page. Not every page with multiple schema nodes is wrong—graphs often contain related nodes—but duplicate or contradictory entities can create confusion.</p>
<p>A site audit may label all of these broadly as “duplicate SEO tags.” Treat that label as a prompt to inspect the page source rather than a diagnosis by itself. First determine exactly which tags are repeated and whether their values conflict.<br>
Why Bricks sites can have overlapping output<br>
Bricks is a visual site builder that works within WordPress. Page settings may store values for individual pages, while an SEO plugin may have its own fields and templates. The theme may also output WordPress’s document title or site identity. Plugins for social sharing, schema, WooCommerce, or redirects may add their own markup.</p>
<p>This does not automatically mean there is a problem. Several systems can be installed as long as their responsibilities are understood. The issue occurs when more than one system is configured to publish the same frontend signal.</p>
<p>Common situations include:</p>
<ul>
<li>A site has an existing SEO plugin and another plugin is activated without reviewing output ownership.</li>
<li>A migration imports titles and descriptions but leaves both plugins active and publishing.</li>
<li>Bricks page settings contain metadata while an SEO plugin also outputs its own values.</li>
<li>A theme setting and a plugin setting both generate social tags.</li>
<li>A schema plugin and an SEO plugin each output organization or article data.</li>
<li>A staging site was copied from production with settings that were not intended to coexist.
A useful first step is to think in terms of ownership. For each type of output—title, description, canonical, robots, social metadata, schema, sitemap, and redirects—identify which tool is responsible. There can be one tool for metadata and another for redirects, but each output type should have a clear owner.
Inspect the rendered page before changing settings
Start with a representative page and inspect its actual output. Do not rely only on what appears in the WordPress editor, plugin settings, or Bricks canvas. The frontend HTML is what crawlers receive.</li>
</ul>
<p>You can use “View Page Source” in a browser and search for:</p>
<ul>
<li><title></li>
<li>name="description"</li>
<li>rel="canonical"</li>
<li>name="robots"</li>
<li>property="og:title"</li>
<li>application/ld+json
Record what you find and note the values. If a tag appears twice, check whether both copies are identical or whether they conflict. For JSON-LD, inspect the full graph rather than counting script blocks alone. Multiple JSON-LD scripts can be valid when they describe different entities, but duplicate entities with conflicting values are worth investigating.</li>
</ul>
<p>Choose sample pages that cover different settings paths:</p>
<ol>
<li>A page with custom SEO fields</li>
<li>A page relying on a template or default</li>
<li>A blog post</li>
<li>An archive such as a category or author page</li>
<li>A product page if WooCommerce is active
A single homepage check may miss a problem limited to a particular template or content type. If the duplicate appears on every page, start with global settings and shared templates. If it appears only on certain pages, inspect their page-level fields and template conditions.
Make a simple output ownership map
Before changing plugin settings, write down which system currently handles each task. A small table is enough:
Output Current owner Intended owner
SEO title and description Plugin or Bricks settings Choose one
Canonical and robots tags Plugin or page settings Choose one
Open Graph and X/Twitter tags Plugin or social plugin Choose one
Schema SEO plugin, theme, or schema plugin Choose one primary graph source
Sitemap SEO plugin or WordPress core Choose one
Redirects Redirect plugin, server, or SEO plugin Define responsibility</li>
</ol>
<p>The goal is not necessarily to use a single plugin for everything. The goal is to prevent two different tools from doing the same job without coordination.</p>
<p>For example, one plugin could manage titles, descriptions, and schema, while a separate redirect tool manages URL changes. That can be perfectly reasonable. But if two plugins both generate canonical tags, you need to change the configuration so that only the intended system publishes the canonical.</p>
<p>Some SEO plugins can detect competitors and switch into an analysis-only mode. That can help during evaluation because the plugin may let you review content without taking over frontend output. Still, verify the behavior on your actual site. A label in settings is not a substitute for checking the HTML response.<br>
Decide which system should own SEO output<br>
Choose the owner based on the site’s actual workflow and needs. Consider:</p>
<ul>
<li>Where editors need to manage fields</li>
<li>Whether the tool understands Bricks pages and templates</li>
<li>Whether it supports the site’s content types and archives</li>
<li>How it handles existing metadata</li>
<li>Whether it can avoid duplicate output from other plugins</li>
<li>How easy it is to inspect and maintain settings over time
If your team edits primarily in Bricks, having page-level SEO controls near the builder may make the workflow smoother. If the team already relies on another SEO plugin and its configuration works, you may prefer to keep it as the output owner while using other tools only for analysis or specific tasks.</li>
</ul>
<p>The important thing is to avoid changing ownership casually. Before switching, list the metadata values that already exist and confirm how they will be preserved. Then test the new setup on representative pages and templates.</p>
<p>For <a href="https://bricksseo.com">Bricks SEO</a>, the SEO tab guide describes page-level titles, descriptions, and crawling directives. Its setup documentation provides an overview of installation and settings. Review these alongside the configuration of any SEO tools already active on your site.<br>
Preserve existing metadata during a migration<br>
A plugin migration has two distinct parts: moving saved data and changing which system outputs it. Treating these as one action can lead to missing metadata or duplicated tags.</p>
<p>Start by making a backup and collecting a snapshot of important values. You do not need to export every setting manually if your migration tool supports a safe import, but you should know which data it will touch and whether existing values will be overwritten.</p>
<p>A cautious migration sequence looks like this:</p>
<ol>
<li>Inventory current fields. Identify the SEO titles, descriptions, canonicals, robots values, social settings, and schema sources you rely on.</li>
<li>Check the importer’s behavior. Confirm whether it is additive, overwrites values, or keeps source data untouched.</li>
<li>Run the import on a staging copy if possible. Compare a sample of pages before and after.</li>
<li>Confirm values in the destination fields. Do not assume an import succeeded because the process completed.</li>
<li>Switch output ownership. Enable the new output source and disable overlapping frontend output from the old source.</li>
<li>Inspect the rendered HTML. Check individual pages, archives, and other relevant templates.</li>
<li>Keep the old data until you have verified the migration. Avoid deleting the previous plugin or its data before you know the new setup is complete.
A migration can preserve the text of a title and still change the resulting output if templates resolve differently. A page that used to inherit from a content-type template may now inherit from a site-wide default. Review both explicit overrides and fallback values.
Understand fallback values and overrides
SEO fields do not always come from the field visible on the page you are currently editing. A title can be set directly on a post, inherited from Bricks page settings, generated by a post-type template, pulled from a site-wide template, or fall back to WordPress.</li>
</ol>
<p>That makes fallback behavior important during both setup and migration. If you change a global template, every page relying on that template may change. If a page has a custom value, it may continue to display its override.</p>
<p>Bricks SEO documents this in its five-tier fallback chain guide. The general principle is useful regardless of the tool: identify the source of a value before trying to fix it. If the HTML contains an unexpected title, ask which tier supplied it instead of adding a second competing title field somewhere else.</p>
<p>Templates can also introduce duplicated wording. For example, a page title may already contain the brand name, and a template may append the brand again. Review real outputs for short titles, long titles, and pages with custom overrides.</p>
<p>A clean fallback strategy gives each field a predictable path. It should be clear what happens when a page-level field is empty, how a custom value takes precedence, and where the final default comes from.<br>
Check canonical and robots tags separately<br>
Canonical URLs and robots directives deserve special attention because conflicting values can affect how a page is crawled or indexed.</p>
<p>For a canonical, confirm that the page has one preferred URL and that the tag points to it. If two canonical tags exist, determine which plugin or theme is generating each. Do not simply remove one without checking whether the remaining source is configured correctly.</p>
<p>For robots directives, look for both HTML meta tags and HTTP headers. A page could have an index directive in its HTML and a noindex header from the server or a security tool. These need to be reconciled.</p>
<p>Also review the distinction between noindex and blocking crawling. If a URL is blocked before the crawler can fetch it, the crawler may not see the page-level noindex directive. Ensure your settings reflect the desired behavior rather than using multiple controls that contradict each other.</p>
<p>If a page should be indexed, verify that no stale noindex value remains from development or a previous plugin. If it should not be indexed, confirm the correct tool owns the setting and inspect the published response.<br>
Review schema as a graph, not a count<br>
Schema output can be more complex than a single script. A page may legitimately describe a website, organization, web page, article, breadcrumb, or product as related entities. The presence of multiple nodes does not automatically mean there is duplicate schema.</p>
<p>Look for repeated representations of the same entity. Two organization nodes with different names or logos may conflict. Two article nodes with different dates or authors could be inconsistent. On a product page, schema generated by an SEO plugin and WooCommerce may overlap or describe different prices and availability.</p>
<p>To audit schema:</p>
<ul>
<li>Identify each @type in the JSON-LD graph.</li>
<li>Check entity identifiers such as <a class="mentioned-user" href="https://dev.to/id">@id</a> and how nodes refer to each other.</li>
<li>Compare organization names, logos, URLs, article dates, and product data.</li>
<li>Confirm that the information matches the visible page.</li>
<li>Check whether the theme or another plugin outputs an additional graph.
Schema should describe real content. It should not be added just to increase the number of markup types. Bricks SEO’s schema type documentation describes the structured data it generates and how its graph is organized. Use it as a reference for that product, and inspect the output on your own pages.
Check social tags and other output too
Duplicate metadata discussions often focus on titles and descriptions, but social tags can overlap as well. Open Graph and X/Twitter tags may be generated by an SEO plugin, social sharing plugin, theme, or custom code.</li>
</ul>
<p>Check for repeated tags such as:</p>
<ul>
<li>og:title</li>
<li>og:description</li>
<li>og:url</li>
<li>og:image</li>
<li>twitter:card</li>
<li>twitter:title</li>
<li>twitter:description</li>
<li>twitter:image
If the values differ, decide which system should control them. A search result title and a social title do not have to be the same, but the page should have a consistent, intentional preview for each channel.</li>
</ul>
<p>Custom code is another possible source of duplicates. Search theme files, child theme functions, snippets plugins, and Bricks custom code for manually inserted title, canonical, or schema markup. If the same tag is generated both by code and a plugin, choose one place to maintain it.<br>
Verify sitemaps and redirects after changing plugins<br>
Changing SEO plugins can also affect technical features beyond the <head>. Check which system generates the sitemap and whether the sitemap contains the right pages. Confirm that noindex pages are handled as intended and that important content types are included.</p>
<p>The Bricks SEO sitemap guide describes its sitemap index and how pages marked noindex are excluded. After changing sitemap ownership, open the sitemap URL and inspect a few sub-sitemaps rather than assuming the switch worked.</p>
<p>Redirects need their own review. Some SEO plugins include redirect management; others do not. If you disable a plugin that owns redirects, confirm that the rules are preserved elsewhere before removing it. Test important old URLs and verify they reach the intended destination without unnecessary hops.</p>
<p>A 404 monitor can help identify broken URLs after a migration or content restructure. The redirects and 404 guide explains the Bricks SEO tools for these tasks. Whether you use that plugin or another system, document which tool owns redirects so future maintainers know where to look.<br>
Test a representative set of pages<br>
After a configuration change, do not test only the homepage. Create a short verification set that covers the site’s different output paths:</p>
<ul>
<li>Homepage</li>
<li>A page with a custom SEO title and description</li>
<li>A page relying on a template</li>
<li>A blog post</li>
<li>A category or author archive</li>
<li>A product page, if applicable</li>
<li>A page that should be noindex</li>
<li>A URL that should redirect
For each page, inspect the final HTML and check the expected tags. Use a crawler or a browser extension if you need to check many URLs, but confirm unexpected findings manually.</li>
</ul>
<p>Also test the editor workflow. Ensure the values are still visible and editable where the team expects them. A clean page source is useful, but a migration that leaves editors unable to find or manage metadata is not a sustainable fix.</p>
<p>Run tests on staging when possible. If you must change a live site, take a backup, make one set of related changes at a time, and verify after each set. That makes it easier to identify which change introduced a new issue.<br>
Common mistakes to avoid<br>
Turning off plugins without checking their responsibilities. A plugin may own redirects, sitemaps, or schema even if you are replacing it for metadata. Map functions before deactivation.</p>
<p>Assuming matching duplicate tags are harmless. Identical values may appear less urgent than conflicting ones, but duplicate output still indicates unclear ownership and can become inconsistent later.</p>
<p>Deleting old metadata too early. Keep source data until you have confirmed that the destination system has the values and is publishing them correctly.</p>
<p>Trying to solve every output issue with custom code. Custom tags can create another source of truth. Use code only when you know how it fits into the site’s output architecture.</p>
<p>Checking only plugin settings. The rendered page is the evidence of what crawlers and browsers receive. Inspect the HTML and, where relevant, response headers.</p>
<p>Treating every audit warning as proof of damage. Audit tools can find repeated tags but may not understand why a page has multiple valid schema nodes. Review the specific markup before acting.<br>
A clean SEO ownership checklist<br>
Use this short checklist when configuring or migrating a Bricks site:</p>
<ol>
<li>List the tools that can output SEO tags or schema.</li>
<li>Inspect representative pages to find what is actually being published.</li>
<li>Assign one owner for each output type.</li>
<li>Preserve existing metadata before migration.</li>
<li>Confirm fallback and template behavior.</li>
<li>Check titles, descriptions, canonicals, robots, and social tags.</li>
<li>Review schema entities and identifiers for conflicts.</li>
<li>Verify sitemap ownership and redirect continuity.</li>
<li>Test pages, archives, products, and noindex cases.</li>
<li>Recheck the editor workflow and document the final setup.
Make the output intentional
Duplicate SEO output is usually a sign that multiple systems overlap or that a migration was only partly completed. The solution is to identify the source of each tag, assign clear ownership, preserve the values that matter, and verify the final page output.</li>
</ol>
<p>For a Bricks site, include Bricks page settings and templates in that audit, alongside SEO plugins, theme features, and custom code. If you are evaluating an in-builder workflow, Bricks SEO and its documentation explain how its settings and fallback behavior work.</p>
<p>The aim is not to remove every SEO tool or force every setting into one screen. It is to make the published output consistent and the editing process understandable. When each piece has a clear owner, the site becomes easier to migrate, troubleshoot, and maintain as it grows.</p>
Top comments (0)