# **🧭 Overview**

When OTTO deploys canonical tag optimizations, it works reliably on most page types. However, **paginated archive pages** — such as `/blog/2/`, `/blog/3/`, and beyond — can sometimes display incorrect or missing canonical tags after deployment. This article explains why this happens and what you can do about it.  
​

# **🔎 What Is the Issue?**

After OTTO deploys a canonical optimization, you may notice that paginated versions of your archive or blog index pages do not reflect the correct canonical URL. For example:

- The canonical on `/blog/2/` points to the first post in the loop instead of the paginated archive page itself.
- The `og:url` tag also inherits the wrong URL from the first post in the loop.
- The canonical appears correct on page 1 (`/blog/`) but breaks on subsequent pages.

This is a known limitation related to how WordPress outputs canonical and Open Graph tags on archive, category, and search result pages. In some environments, the existing theme or plugin emits a canonical pointing to the first post in the loop rather than the archive URL — and OTTO's deployment cannot always override this in a persistent way.  
​

# **⚙️ Why Does This Happen?**

OTTO applies canonical changes by modifying the page's DOM at deployment time. On most pages, this works as expected. On paginated archive pages, two compounding factors can interfere:

- **WordPress loop behavior:** Certain WordPress themes and SEO plugins emit the canonical tag using the first post returned in the query loop, which means archive pages receive the wrong canonical by default before OTTO can intervene. The Search Atlas WordPress plugin previously had this same behavior on archive, category, and search pages — this has been resolved (WP-418).
- **DOM-only replacement limitation:** In some configurations, OTTO's canonical update is applied only at the DOM level and does not fall back to a string-level replacement. If the page regenerates or the canonical is written late in the render cycle, the OTTO update may not persist across all paginated URLs (WP-536).
- **Canonical metabox write-only issue:** An additional edge case exists where a canonical value saved via the canonical metabox is stored correctly but never emitted as the actual canonical URL on the front end. This issue (WP-544) is currently **in release** and affects environments where metabox-level canonical overrides are expected to take effect.

This is not a configuration error on your end — it is a technical constraint that the Search Atlas engineering team has identified and is actively working to resolve.  
​

# **✅ What You Can Do Right Now**

While the platform-level fix is being finalized, the following steps can help reduce or eliminate incorrect canonicals on your paginated archive pages:

1. **Check your WordPress SEO plugin settings.** If you are using a plugin such as Yoast SEO, Rank Math, or All in One SEO, navigate to its settings and confirm that canonicals for archive and category pages are set to the archive URL — not inherited from the first post. Disable any option that auto-generates canonical tags based on loop content.
2. **Re-deploy the canonical optimization via OTTO.** In the Search Atlas platform, go to **Left sidebar → OTTO SEO → All Sites (SEO Automation)**. Locate the affected project, open the canonical issue type, and re-deploy. You can now use the **Deploy All by Issue Type** feature to deploy across all paginated URLs at once without pagination restrictions. In some environments, a second deployment resolves the persistence issue.
3. **Verify with a live crawl after deployment.** After redeploying, use **Left sidebar → Site Metrics → Pages** to inspect the affected paginated URLs and confirm the canonical tag is now correct.
4. **Avoid conflicting canonical sources.** If your theme outputs its own canonical tag independently of your SEO plugin, the conflicting sources can override OTTO's changes. Remove or disable any hardcoded canonical output in your theme's `header.php` or equivalent template file.

# **📋 How to Confirm the Canonical Is Correct**

To verify whether the canonical tag is rendering correctly on a paginated archive page, follow these steps:

1. Open the paginated URL in your browser (for example, `https://yourdomain.com/blog/2/`).
2. Right-click the page and select **View Page Source**.
3. Search for `canonical` using Ctrl+F or Cmd+F.
4. Confirm the `href` value matches the paginated URL exactly — for example, `https://yourdomain.com/blog/2/` — and not the URL of any individual post.

If the canonical still points to a post URL after following the steps above, the issue may require a deeper configuration review.  
​

# **🛠️ Engineering Status**

The Search Atlas engineering team has already shipped fixes for the most common variants of this issue, including:

- Correcting the canonical and `og:url` tags emitted by the Search Atlas plugin on archive, category, and search pages (WP-418 — **Done**).
- Ensuring OTTO canonical deployment applies consistently across all paginated URLs without restriction, including a UI update supporting mass deployment by issue type (OTTO-996, OTTO-997 — **Done**).

Two remaining fixes are currently in progress:

- **String-level fallback for DOM-only replacement failures** (WP-536) — currently **in release**. This update will improve reliability for environments where the canonical is written late in the render cycle and the DOM-level update does not persist.
- **Canonical metabox emission fix** (WP-544) — also currently **in release**. This resolves cases where a canonical value is saved via the metabox but never output as the canonical URL on the front end.

# **💬 Still Seeing the Problem?**

If you have followed the steps above and the canonical tag is still incorrect on your paginated archive pages, our team can review your specific site configuration and deployment logs. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type **human teammate** to be connected with a member of our team.