🛠️ Troubleshooting

🛠️ WordPress Plugin Troubleshooting Guide

The Search Atlas WordPress Plugin automatically handles API key configuration, plugin authentication, OTTO Pixel UUID injection, Server-Side Rendering (SSR), and OTTO communication with your site. If auto-configuration fails, use this guide to manually configure credentials and resolve common OTTO status errors. ⚠️ When to Use This Guide Use this guide only if you have installed the Search Atlas WordPress Plugin and see one of the errors below. Match the message to where it appears in the UI. In your OTTO dashboard: - "OTTO Not Detected" - "OTTO is disengaged" — only follow this guide if OTTO disengaged on its own without user action. If your team disengaged it intentionally, re-engage from the OTTO dashboard and monitor for re-deployment. - Missing deployed fixes or no crawl data In the WordPress plugin panel: - "Your script is using an incorrect UUID" - "Incorrect site token" - "API key could not be verified" In OTTO diagnostics / scan results: - "Duplicate Installation Detected" — if OTTO shows as installed but project UUIDs do not match, this may be a known platform bug (WP-343) rather than a true duplicate. Open a support ticket with your project UUID and site URL for engineering review (see Section 2). - Pixel Not Detected Note: Do not use this guide if your installation method is manual script, GTM, Shopify, GHL, Cloudflare Worker, or any other non-WordPress method. 🛠️ 1. Confirm the Plugin Is Installed Correctly ✔ Step 1 — Activate the Plugin Go to WordPress → Plugins. Search for Search Atlas SEO – Premier SEO Plugin. Confirm the status shows Active. If not, click Activate. ✔ Step 2 — Verify Authentication Go to WordPress → Search Atlas → Settings. Confirm all four of the following are present: - Green banner: Authentication Successful - Search Atlas API Key: auto-filled - Plugin Auth Token: auto-filled - OTTO Pixel UUID: auto-filled If any field is blank, click Connect to Search Atlas and complete authentication again. ⚠️ Known issue (AIAGENT-1905 — awaiting release): If Atlas Brain shows authentication status as PENDING but the WordPress plugin panel shows Authenticated, this is a known display mismatch. Do not re-enter or reset your credentials — re-authenticating repeatedly can break a working setup. Contact support and reference AIAGENT-1905 (include screenshots of both the plugin panel and the OTTO dashboard / Atlas Brain status) to confirm your actual authentication state. ⚠️ "API key could not be verified" error — Two separate values are required, and they are not interchangeable: - SearchAtlas API Key — a 32-character alphanumeric code found under Settings → API Keys in your Search Atlas dashboard. - Site Token — found in OTTO → Settings. Paste each value into its respective field in the WordPress plugin panel. Entering the wrong value in either field (for example, a license key, account password, or swapping the API Key and Site Token) triggers this error. ⚠️ If credentials are confirmed correct and the error persists, this may be a known platform-level bug (ref: WP-331). Open a support ticket with your site URL, the last 4 characters of your API Key, and your Site Token so engineering can investigate. When both credentials are confirmed, the green Authentication Successful banner appears and all fields auto-fill. 🗺️ 2. Verify OTTO Pixel Settings (Critical) Go to WordPress Admin → Search Atlas → Settings. ✔ Confirm the OTTO Pixel UUID Is Populated If the UUID field is blank, click Connect to Search Atlas again to re-authenticate and populate it automatically. ⚠️ Known issue (WP-343 — awaiting release): A platform bug can cause OTTO to display as Installed even when the project UUID does not match the UUID detected on the site. If you have confirmed the UUID values are mismatched but OTTO still shows as Installed, this is a bug — contact support rather than continuing to troubleshoot locally. ✔ Disable "OTTO for Logged-in Users" Toggle Disable OTTO for Logged-in Users to OFF during troubleshooting. If this is ON, OTTO will not load while you are logged in, producing false negatives in your tests. ✔ Disable Schema Markup (Optional) ✔ Enable Meta Description (Optional) Important: Do not add any OTTO Pixel script manually to your theme, header.php, or GTM. When the plugin is active, no manual pixel injection is needed — the plugin handles it automatically. ⚠️ If OTTO is adding unexpected content to your site (e.g., unwanted heading text or other injected content), go to OTTO → Deployed Fixes, identify the responsible fix by name (e.g., Heading Length), and click Undeploy. The injected content will be removed immediately. When all required settings are confirmed, OTTO can deploy fixes and the pixel UUID will match your OTTO project. ✅ 3. Confirm the Pixel Actually Loads (No Cache Interference) ✔ Step 1 — Log Out of WordPress The pixel does not load for logged-in users when the Disable OTTO for Logged-in Users toggle is enabled. Log out before testing to avoid a false negative. ✔ Step 2 — Inspect the Page Source Open your homepage, then right-click and select View Page Source. Press Ctrl+F (Windows) or Cmd+F (Mac) and search for: sa-dynamic-optimization - Found: The pixel is loading correctly. No further action needed in this section. - Not found: Proceed to Sections 4 and 5 to resolve firewall blocks and cache interference. ⚠️ 4. Whitelist the Search Atlas Crawler If your firewall or bot-protection plugin blocks the Search Atlas crawler, OTTO will show "Not Installed" even when the plugin is configured correctly. Whitelist the crawler in each active security tool below. Cloudflare Go to Dashboard → Security → Bots and turn OFF: - Bot Fight Mode - Super Bot Fight Mode WordFence Go to WordPress Admin → WordFence → Firewall → Options. Set Web Application Firewall Status to Disabled (temporary). Stop Bad Bots Go to WP Admin → Block Bad Bots → Settings. Disable Block All Bots, or add the following to the whitelist: Search Atlas Bot (https://www.searchatlas.com/) Blackhole for Bad Bots Add the following to the whitelist: Search Atlas Bot (https://www.searchatlas.com/) Shield Security Go to WP Admin → Shield → IP Rules → User Agent Rules and add to the whitelist: Search Atlas Bot (https://www.searchatlas.com/) After whitelisting the crawler in all active security tools, trigger a new OTTO scan to confirm the crawler can now reach your site. 🔵 5. Clear ALL WordPress Caches Caching is the most common cause of pixel dete 🎯 Once authentication is confirmed, the OTTO pixel is detected, and your crawler is whitelisted, OTTO should be fully operational and deploying fixes to your site. If errors persist after completing every section, contact Search Atlas support with your site URL, project UUID, and screenshots of all error messages for engineering review.

🔧 Troubleshooting Plugin Conflicts: WP Rocket, Sucuri, LiteSpeed Cache, W3 Total Cache, and Divi Compatibility with Search Atlas

Some WordPress users — especially agencies, developers, and SEOs — use advanced performance or security plugins such as WP Rocket, Sucuri WAF/CDN, LiteSpeed Cache, or page builders like Divi. While powerful, these tools can sometimes conflict with Search Atlas's plugin or JavaScript snippet integration. This guide summarizes common issues and workarounds for advanced setups. If you're experiencing problems with Search Atlas not displaying, not injecting properly, or behaving inconsistently, this article is for you. ⚠️ Important — Do not use both integration methods at the same time: Do not use both the Search Atlas WordPress plugin and the JS snippet simultaneously. Duplicate installations have been reported to generate hundreds of duplicate form entries in Website Studio. Choose one integration method only. Note: Search Atlas can be integrated in two ways — via the official WordPress plugin or via the JavaScript snippet (pixel/manual script). Some of the conflicts below apply only to one integration path, so each entry indicates whether it affects the plugin, the JS snippet, or both. 🔍 Common Compatibility Issues and Fixes Tool Common Conflict Suggested Fix Applies To WP Rocket JS snippet is delayed or blocked Use Delay JS execution and exclude Search Atlas script JS snippet Sucuri WAF/CDN Cached version blocks dynamic JS Bypass cache for admin and plugin routes; clear cache after install. In the Sucuri dashboard, navigate to Firewall → Cache → Cache Exceptions and add your site's admin and plugin asset paths. Alternatively, enable Development Mode temporarily during initial setup. Both LiteSpeed Cache Can block plugin rendering Disable cache for logged-in users or plugin-specific URLs Plugin W3 Total Cache Object cache prevents plugin load Temporarily disable object caching during setup Plugin 🎨 Divi-Specific Notes Applies to: JS snippet integration. Issue: When inserting the Search Atlas JS snippet via Divi's Theme Options or Page Settings, the script may be sanitized or ignored. Solution: Use a plugin like Insert Headers and Footers or WPCode to inject the script at the site-wide <head> level. These plugins are generally more reliable for inserting custom code than theme options, but if OTTO changes still do not appear after correct injection, contact support — some builder configurations require backend intervention. 🧩 Using the Official Search Atlas WordPress Plugin Applies to: Plugin integration. We recommend using the native Search Atlas plugin provided by Search Atlas for a more stable and optimized experience. When to prefer the plugin over the JS snippet: - You want a managed integration that handles CMS connector syncing and updates automatically. - You are publishing content from Search Atlas into WordPress. - Your theme or page builder (such as Divi) sanitizes custom scripts inserted via theme options. Installation steps: 1. In WordPress, go to Plugins → Add New → Upload Plugin and upload the Search Atlas plugin .zip file provided by Search Atlas. 2. Install and activate the plugin. 3. Connect the plugin to your Search Atlas account using the API key from your dashboard. 4. Clear all caching layers (WordPress, CDN such as Sucuri, and browser) after activation. Tips: - Disable caching and minification during plugin activation. - After setup, clear all layers of cache: WordPress, CDN (Sucuri), and browser. - Avoid using both the JS snippet and the plugin at the same time unless advised by support. ⚠️ Known issue: Duplicate form entries when both integrations are active If both the Search Atlas plugin and the JS snippet are installed simultaneously, the integration may register the same form repeatedly, producing hundreds of duplicate entries in Website Studio → Forms. To avoid this, choose only one integration method. If you have already encountered duplicates, deactivate one of the integrations and contact support to help clean up the duplicate records. 🧭 Known issue: Site navigation menu fully expanded after plugin activation In some themes, activating the Search Atlas WordPress plugin may cause the public-facing site's navigation menu to render fully expanded. While our engineering team works on a permanent fix, you can apply a CSS override via Appearance → Customizer → Additional CSS to restore the intended menu behavior. When filing a support ticket, please include your active theme name so we can reproduce and track the issue. 🔌 Known issue: Atlas Brain shows CMS connector as disconnected despite active plugin If the CMS Connectors dashboard or Atlas Brain displays a "+" or disconnected state even though the plugin is installed and WordPress publishing works correctly, this may be a display bug. Before reinstalling the plugin, contact support to verify the backend connection status — in most reported cases the connection is healthy and only the UI indicator is stale. 📌 Note on JS Snippet Deprecation Applies to: JS snippet / pixel / manual script integration. Some users have asked whether the JavaScript snippet will be deprecated in the future. As of now, there is no official deprecation notice, but the plugin is the preferred integration method going forward. OTTO crawler and pixel/manual script installs: If you are using the pixel/manual script installation and see that Site Audit still reports original page titles rather than OTTO-deployed titles, this may indicate a known crawling issue. Ensure JS rendering is enabled in your project settings and contact support if titles remain stale after a recrawl. 🛠️ Still Need Help? If you're running a custom setup or using advanced server-level tools, we'd love to hear from you. Our team is actively collecting edge cases like this to improve both documentation and product compatibility. 💡 This article is part of our advanced user documentation. If you're an agency or technical user with performance tools, caching layers, or custom themes, this guide will help ensure Search Atlas works optimally in your stack. We'll continue updating this article based on new cases and user contributions.

⚙️ WordPress Plugin Timeout Behind Cloudflare (Manual Installation Fix)

If you're getting a timeout error while installing the Search Atlas WordPress plugin behind Cloudflare, this guide walks you through the working fix. 🚨 The Problem A user attempting to install the Search Atlas plugin experienced a timeout error, even though the server was behind Cloudflare, external calls were allowed, no IP restrictions were configured, all other WordPress plugins were disabled, and cache had been cleared. Despite standard troubleshooting, the timeout persisted. 🧠 Why This Happens When your WordPress server is behind Cloudflare (or another CDN, WAF, or security layer), automated API calls during plugin setup may fail because the inbound callback the plugin relies on to complete authentication gets silently blocked — by a Cloudflare WAF rule, "I'm under attack" mode, an IP allowlist, or a "coming soon" page. Even with no explicit IP restrictions visible to you, the automated setup can still fail silently this way. ✅ The Working Solution: Manual Plugin Connection Instead of relying on automatic setup, manually connect the plugin using your API credentials. Step 1 — Open the Search Atlas Plugin in WordPress. In your WordPress dashboard, go to WordPress Admin → Search Atlas Plugin → Settings. Step 2 — Paste Your API Key. In the API Key field, paste your assigned API key and save. Step 3 — Add the OTTO Pixel UUID. Below the API Key field, paste the provided UUID into the OTTO Pixel UUID field and save. Step 4 — Purge All Caches. This is critical: clear your WordPress cache, server cache, Cloudflare cache, and any object caching layers, then wait 30–60 seconds. Step 5 — Click Sync. After clearing cache, click Sync Plugin. If successful, the plugin will connect and your dashboard will load normally. 🔑 Where to Find Your UUID and API Key in Search Atlas Your UUID is embedded inside your OTTO Pixel script. Navigate to Left Sidebar → OTTO SEO → All Sites, select your project, then open its Installation Guide → Custom Installation. Under Step 1: Copy Your Pixel Script, you'll see a script block with your OTTO pixel — inside the script tag, look for a data-uuid attribute set to a value such as 87a7de3c-6f0e-4269-8518-df74976bb97c. That value is your UUID. It's unique per project, used to identify your OTTO installation, and automatically generated. Custom Installation page showing the OTTO Pixel script Your API Key is located in account-level settings. Navigate to Top Right → Click your Profile Name → Settings → API Keys. You'll see a section titled Search Atlas API Key with a long alphanumeric key. That is your API Key. It's account-level (not project-specific), used for integrations and external connections, and sensitive — do not share it publicly. API Keys panel in account settings ⚠️ Important Difference The UUID is found in the OTTO Installation Guide, is project-specific, and is used for pixel installation — it appears inside a script tag. The API Key is found in Account Settings, is account-level, and is used for API integrations — it's listed under the API Keys panel. 🎉 Expected Result You should now see your Search Atlas dashboard, confirm the plugin shows as connected, and no longer receive timeout errors. 🛠 If It Still Doesn't Work Check PHP memory limits, max_execution_time, firewall or WAF rules, and CDN request timeout settings. If needed, escalate to support with a short screen recording, server environment details, and hosting provider information. If you're running WordPress behind Cloudflare or another CDN and seeing timeouts, manual setup is the fastest resolution path. 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.

🛠️ How to Clear Cache in WordPress for the Search Atlas Plugin

If the OTTO Pixel isn't showing as detected after installing the Search Atlas plugin, caching is the most common cause. On most sites, clearing the WordPress cache is enough — but if you're on a CDN-backed host (such as Cloudflare or Pressable), you'll also need to purge your CDN cache to ensure OTTO detects the pixel correctly. ⚙️ Confirm Your Search Atlas Plugin Settings First Before clearing any cache, verify the plugin is configured correctly: 1. Go to the Search Atlas plugin settings in your WordPress dashboard. 2. Confirm your API keys and UUID are correctly filled in. 3. Click Save to apply the settings. Your configuration is saved and ready for the cache-clearing steps below. 🗑️ Clear Your WordPress Cache 1. Go to the frontend of your WordPress site. 2. In the top admin bar (top-right corner), click Clear Caches. 3. From the dropdown menu, select Clear All Caches. This clears outdated content from WordPress's caching layer and helps OTTO register the plugin correctly. ☁️ Clear Your CDN Cache (Non-WP-Rocket Sites) If your site runs on a CDN-backed host — such as Cloudflare, Pressable, or a similar edge-caching service — you also need to purge your CDN cache separately. Why this matters: A bug (WP-329) caused the OTTO plugin to send Cache-Control: public, max-age=3600 headers on non-WP-Rocket sites. This instructed CDNs and edge servers to aggressively cache pages, so a WordPress-level cache clear was immediately overridden — your CDN would re-serve stale content right away. Affected sites could also see broken forms and exposed nonces as side effects. This issue is fully resolved in the WP-329 plugin update. If you installed the Search Atlas plugin before this fix was released, perform a one-time CDN purge: - Cloudflare: In your Cloudflare dashboard, go to Caching → Configuration, then click Purge Everything. - Pressable: In your Pressable dashboard, go to Sites → [Your Site], then click Clear Cache. - Other CDN or host: Refer to your host's documentation for a full edge-cache purge. After purging, your CDN will serve fresh content and OTTO can detect the pixel on the next scan. 🔍 Verify OTTO Pixel Detection 1. Return to your OTTO dashboard. 2. Click Scan. OTTO should now detect the pixel and display a confirmation message. 🛠️ Troubleshoot If the OTTO Pixel Still Isn't Detected If OTTO still can't detect the pixel after completing all steps above, try the following: - Repeat both the WordPress cache clear and the CDN cache purge. - Confirm the Search Atlas plugin is updated to the latest version, which includes the WP-329 fix. - Check that no other plugin or server rule is overriding Cache-Control headers on your site. - Contact Search Atlas Support — we can verify your configuration and walk you through any remaining steps. 🎯 You now know how to clear both WordPress and CDN caches to get the OTTO Pixel detected correctly — including the extra CDN purge step needed on non-WP-Rocket hosts. If you're setting up the Search Atlas plugin for the first time, see our Search Atlas WordPress Plugin Installation Guide for full setup instructions.

🔌 CMS Integration (WordPress, Shopify, Contentful)

This article covers: - WordPress publishing - Shopify blog publishing - Contentful integrations - image synchronization - authentication failures - content type mismatches - CMS API permissions - encoding issues - and publish synchronization delays. CMS publishing workflows depend on: - external CMS APIs - OAuth or application passwords - media accessibility - correct permissions - active content models - and stable synchronization between SearchAtlas and third-party platforms. Because these workflows involve external systems, temporary delays and authorization issues are common. ⚠️ Error 1: WordPress content push failing — posts not appearing in WordPress What's happening The most common cause is an expired, revoked, or invalid WordPress Application Password. Additional causes include: - security plugins blocking API access - REST API restrictions - incorrect user permissions - or WordPress caching conflicts. Steps to try 1. Go to: WordPress → Settings 2. Generate a new Application Password in WordPress: Users → Your Profile → Application Passwords 3. Update the password in Search Atlas. 4. Confirm the connected WordPress user has Editor or Administrator permissions. 5. Verify the WordPress REST API is publicly accessible. 6. Disable security plugins temporarily to test connectivity. 7. Confirm your domain uses the correct HTTPS protocol. 8. Retry publishing a smaller test article first. 9. Check whether WordPress caching plugins delay post visibility. 10. Contact support if publishing still fails after reconnecting credentials. Important Notes - Application Passwords can become invalid after password resets or security changes. - Many WordPress security plugins block external publishing by default. ⚠️ Error 2: Shopify publish rejected — "requires merchant approval for write_content scope" What's happening Shopify requires explicit merchant approval before apps can publish blog content. This error appears when: - write_content permissions were never approved - permissions changed - or the Shopify app authorization became outdated. Steps to try 1. Open Shopify Admin. 2. Go to: Apps → SearchAtlas App → Permissions 3. Approve the write_content scope. 4. Disconnect and reconnect Shopify inside SearchAtlas. 5. Confirm you are logged in as the Shopify store owner. 6. Verify the app still appears under active installed apps. 7. Retry publishing after reauthorization. 8. Test with a small draft article first. 9. Confirm the target Shopify blog exists and is active. 10. Contact support if permissions appear approved but publishing still fails. Important Notes - Shopify permission scopes are controlled entirely by Shopify security policies. - Reauthorization often refreshes missing scopes automatically. ⚠️ Error 3: Article image fails Shopify validation — "image is invalid" What's happening Shopify rejects images when: - files exceed size limits - unsupported formats are used - images are corrupted - or source URLs are inaccessible. Steps to try 1. Convert images to JPG or PNG format. 2. Keep image size under 20MB. 3. Avoid unsupported WebP formats on older Shopify stores. 4. Confirm image URLs load publicly in-browser. 5. Replace externally blocked image URLs. 6. Re-upload the image directly into SearchAtlas. 7. Compress oversized images before publishing. 8. Avoid hotlinking from restricted domains. 9. Test publishing with a single image first. 10. Contact support if valid images continue failing Shopify validation. Important Notes - Shopify validates image accessibility before importing. - Publicly accessible URLs are required. ⚠️ Error 4: Contentful connection fails — "Space endpoint not found" What's happening This error occurs when: - the Space ID is incorrect - the API token is invalid - the wrong API token type is used - or the Contentful space no longer exists. Steps to try 1. Go to: Settings → CMS Connectors (Contentful) 2. Re-enter the correct Space ID. 3. Generate a new Content Management API token. 4. Confirm you are using the Management API token — not the Delivery API token. 5. Verify the Contentful space still exists. 6. Confirm your account has access to that space. 7. Disconnect and reconnect Contentful integration. 8. Retry publishing after reconnection. 9. Test the connection with a simple content entry first. 10. Contact support if endpoint validation still fails. Important Notes - Delivery tokens cannot publish content. - Management tokens are required for write operations. ⚠️ Error 5: Contentful content type not found — publish fails What's happening Search Atlas can only publish into active Contentful content types. Publishing fails when: - the content type is still draft - the API ID is incorrect - or the selected content type does not exist. Steps to try 1. Open Contentful → Content Model. 2. Confirm the content type is activated and published. 3. Verify the API ID matches exactly. 4. Re-select the content type inside SearchAtlas. 5. Confirm required fields exist inside the model. 6. Ensure field validations are not blocking publishing. 7. Test publishing a minimal content entry. 8. Republish the content type after edits. 9. Refresh the Contentful integration connection. 10. Contact support if valid content types still fail recognition. Important Notes - Display names and API IDs are different. - SearchAtlas uses the API ID internally. ⚠️ Error 6: CMS database connection refused (UCMSI service unavailable) What's happening The CMS Integration service occasionally restarts or temporarily loses connectivity. This can interrupt: - publishing - synchronization - and API communication. Steps to try 1. Wait 5–10 minutes and retry. 2. Refresh the CMS Integration dashboard. 3. Retry publishing a small draft article. 4. Confirm your CMS credentials are still valid. 5. Check whether all CMS integrations are affected or only one. 6. Disconnect and reconnect the CMS integration. 7. Retry during off-peak hours. 8. Save/export your content locally before retrying. 9. Check whether the CMS itself is operational. 10. Contact support if the service remains unavailable longer than 15 minutes. Important Notes - Most UCMSI outages self-recover automatically. - Content is usually preserved even when publishing fails. ⚠️ Error 7: Published article contains garbled special characters What's happening Character encoding mismatches between: - SearchAtlas (UTF-8) - databases - CMS rendering engines - or imported legacy content can corrupt: - bullets - apostrophes - em dashes - smart quotes - and accented characters. Steps to try 1. Confirm your CMS database uses UTF-8MB4 encoding. 2. Verify your WordPress installation uses UTF-8MB4. 3. Re-save the affected article manually. 4. Avoid copy-pasting from Word documents directly. 5. Remove malformed hidden characters before publishing. 6. Test publishing a short clean-text article first. 7. Disable problematic legacy plugins temporarily. 8. Check whether the issue only affects imported content. 9. Compare the rendered article source code. 10. Contact support with examples of broken characters if the issue persists. Important Notes - Shopify and Contentful usually handle encoding automatically. - Legacy WordPress databases are more prone to encoding mismatches. ⚠️ Error 8: Content pushed to CMS but images are missing What's happening Images referenced by inaccessible or broken URLs cannot be fetched by the CMS during publishing. This commonly occurs when: - images are private - temporary URLs expire - media libraries are disconnected - or hotlinked assets are blocked. Steps to try 1. Open every image URL directly in-browser. 2. Confirm each image loads publicly without authentication. 3. Replace broken URLs before publishing. 4. Upload missing images directly into your CMS media library. 5. Avoid temporary CDN URLs. 6. Re-upload images inside SearchAtlas. 7. Publish a test article containing one image first. 8. Check whether image-hosting firewalls block external requests. 9. Verify media permissions inside Shopify or WordPress. 10. Contact support if images consistently fail despite being publicly accessible. Important Notes - CMS platforms must be able to fetch media externally. - Private or expiring URLs are the most common cause of missing images. They are usually related to: - expired credentials - missing API permissions - CMS security restrictions - inaccessible media assets - encoding mismatches - or external CMS validation rules. In many cases, the publishing system is functioning correctly — the external CMS environment is preventing synchronization from completing successfully. 👉 Stable CMS publishing workflows depend heavily on: - valid API credentials - publicly accessible media - correct permission scopes - UTF-8-compatible environments - active content models - and reliable synchronization between Search Atlas and the connected CMS platform.

🛠️ Troubleshooting Shopify Connector Failures in Search Atlas

Fix the most common Search Atlas Shopify connector failures — loading glitches, page-load timing issues, 410 Gone errors, WordPress plugin confusion, and custom app problems — using the matching fix for each. Start with a hard-refresh and re-add, which resolves most cases. 📋 Overview of Shopify Connector Failures The Search Atlas Shopify connector can fail during initial setup or after a store is already connected. This article covers the most common failure modes — temporary loading issues, page-load timing problems, 410 Gone errors, WordPress plugin confusion, and custom app failures — and gives you a clear fix for each. 🔄 First Fix: Hard-Refresh and Re-Add the Shopify Connector If you can't connect your store through the plugin or custom app, or you're seeing chat disconnections and other glitches, you're likely hitting a temporary loading issue. Chat disconnections and similar glitches are usually symptoms of this same temporary loading state — not a separate problem — because the page holds a stale session that a hard-refresh clears. This fix resolves it most of the time, so try it first. If the disconnections continue even after a hard-refresh and re-add, escalate to Search Atlas support. 1. Hard-refresh the page to clear the temporary loading state: press Ctrl+Shift+R on Windows, or Cmd+Shift+R on Mac. 2. Go to Settings → Add Connector. 3. On Step 1, select New domain and manually type your domain name instead of selecting it from the existing list. 4. Enter your Shopify credentials and click Submit to create the connector. The connector creates successfully and your Shopify store appears in your connected integrations. ⚠️ Connection Won't Establish (Page-Load Timing Issue) If the Shopify connection fails immediately after you start it, a timing problem during the authorization flow may be stopping the OAuth handshake from completing. OAuth is the secure sign-in process Shopify uses to authorize the connection. How to fix it 1. Go to Coworker → Connectors (Shopify) in the left sidebar of Search Atlas. 2. Click Connect and wait for the Shopify authorization page to fully load before clicking anything. 3. Stay on the authorization page until it completes — keep the tab open and let the flow finish. 4. Approve all requested permissions on the Shopify side. 5. If the connection still fails, hard-refresh the page (see the First Fix section), then re-add the connector using the New domain option, or retry in an incognito or private window. Once the handshake completes, Search Atlas confirms the store is connected. ⚠️ 410 Gone Error on a Previously Connected Store A 410 Gone error on a store that was already connected usually means the Shopify app install was removed or the OAuth token was revoked from the Shopify admin side. How to fix it 1. In your Shopify admin, go to Apps → Installed Apps and confirm the Search Atlas app is still listed. 2. If it was removed, reinstall the Search Atlas app from the Shopify App Store. 3. Return to Search Atlas and reconnect via the left sidebar → Coworker → Connectors (Shopify). After reinstalling and reconnecting, the 410 error clears and data syncing resumes. 🔌 WordPress Plugin Method Not Working for Shopify The Search Atlas WordPress plugin is built for WordPress-based websites, not Shopify storefronts. Shopify does not run WordPress, so the WordPress plugin cannot connect a Shopify store. How to fix it 1. Use the native Shopify connector in Search Atlas instead. 2. Go to Settings → Integrations → Shopify and follow the OAuth connection flow described above. The native connector is the supported path for Shopify and connects your store directly. 🔑 Custom App (API Key) Method Failing If you're connecting with a Shopify Custom App (API key and secret) and the integration won't complete, a misconfigured domain, mismatched credentials, an app that isn't fully installed, a missing access scope, or an expired token is the usual cause. How to fix it 1. In your Shopify admin, go to Settings → Apps and sales channels → Develop apps. 2. Confirm your Shop Domain uses the .myshopify.com subdomain format (for example, your-store.myshopify.com), not your custom storefront domain. 3. Verify that the Client ID and Client Secret entered in Search Atlas exactly match the API credentials shown in your custom app's settings — a mismatch will block the connection. 4. Confirm the app is both installed and released in your Shopify admin. An app that is created but not installed and released will not authorize. 5. Check the app URL in your custom app configuration and set it if it is blank or incorrect (for example, https://shopify.dev/apps/default-app-home). 6. Open your custom app and confirm all required Admin API access scopes are enabled. 7. Verify the exact scope list against your Search Atlas connector documentation before publishing, as requirements may vary. Commonly required scopes include read_products, write_products, read_content, write_content, read_metafields, and write_metafields. 8. If any required scope is missing, add it and save the app configuration. 9. Regenerate your Admin API access token if it has expired or been revoked. Copy the new token immediately, as Shopify displays it only once. 10. Re-enter the new token in Search Atlas under the left sidebar → Coworker → Connectors (Shopify → Custom App). With the correct domain format, matching credentials, a fully installed app, the correct scopes, and a valid token, the custom app connection completes and your store syncs. 🚫 404 Token Exchange Error A 404 token exchange error during a custom app connection usually means Shopify can't complete the token handshake — typically because the app isn't fully installed, the app URL is wrong, or the Client ID/Secret don't match. How to fix it 1. Confirm the custom app is both installed and released in your Shopify admin under Settings → Apps and sales channels → Develop apps. 2. Verify the app URL is configured correctly (for example, https://shopify.dev/apps/default-app-home) — a missing or incorrect app URL will break the token exchange. 3. Double-check that the Client ID and Client Secret in Search Atlas exactly match the values in your custom app's API credentials. 4. Re-enter the credentials and retry the connection under the left sidebar → Coworker → Connectors (Shopify → Custom App). Once the app is installed and released, the app URL is correct, and the credentials match, the token exchange completes successfully. 🔔 Known Platform-Level Issue Search Atlas is aware of changes Shopify has made to its API token system that can affect some store connections. If you hit a connection or token error, run the First Fix steps above, and contact Search Atlas support if the issue continues. 🎯 You now have a fix for every common Shopify connector failure — start with the hard-refresh and re-add steps, then work through the matching failure mode if needed. If a connection still won't establish after trying these, reach out to Search Atlas support so the team can investigate token-level issues.

📘 GSC Property Verified but Not Showing in Search Atlas

📘 Overview If your website is verified in Google Search Console, connected to your Google account in Search Atlas, but still not visible inside the platform, this usually means the property hasn't been fully activated inside GSC Performance settings. This is not a verification issue, it's typically a location activation step that hasn't been completed yet. 🧭 Navigation Path Search Atlas → Site Metrics → Site Explorer → Your connected GSC Accounts → Manage Sites. 👣 Step-by-Step Fix 1. Open Site Explorer: go to Left Sidebar → Site Metrics → Site Explorer. 2. Click "Manage Sites": on the GSC Sites List screen, click Manage Sites. 3. Click "Manage Sites": on the Your connected GSC Accounts page, click Manage Sites to open the property management panel. 4. Select Location (Country): find your domain, use the Location dropdown to select your target country, and toggle the site to Active if needed. Without selecting a location, the property may not appear in dashboards. 5. Refresh your dashboard: after saving, refresh the dashboard and the property should appear correctly. 🔴 Why This Happens Even after verifying ownership in Google Search Console and connecting your Google account in Search Atlas, the property will not display in performance views until a location is selected and the site is activated in the GSC management panel. This is expected behavior. ❓ FAQs - Why can't I see my verified property? Because it hasn't been activated under Site Metrics → Site Explorer → Your connected GSC Accounts → Manage Sites. - Is this a Google issue? No, it's a configuration step inside Search Atlas. - Do I need support to fix this? No, selecting the location and refreshing resolves the issue. 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.

🔌 Search Atlas — MCP Server (AI Tools) Issues

This article covers: - MCP Server connectivity - Claude Desktop integration - Cursor IDE integration - MCP tool execution - SSE transport - Redis/session interruptions - tool manifest loading - API authentication - tool timeouts - and Search Atlas AI tool orchestration workflows. The Search Atlas MCP Server exposes: - 673+ tools - AI orchestration capabilities - OTTO automation - Keyword Research - Website Studio - QUEST - and AI-powered SEO workflows through a distributed MCP infrastructure. Because MCP systems depend on: - SSE connections - distributed queues - Redis - Celery workers - and upstream services …temporary interruptions, tool instability, or connection resets can occur during heavy platform activity. ⚠️ Error 1: MCP server returns "CELERY_QUEUE_NAMES not found" What's happening This is currently the most common MCP infrastructure error. The MCP deployment environment failed to load the expected Celery queue configuration during startup. When this happens: - tools may not respond - task execution may fail - or the MCP server may appear partially online. This is a server-side deployment issue. Steps to try 1. Disconnect your MCP client completely 2. Restart: - Claude Desktop - Cursor - or your MCP host application 3. Reconnect the Search Atlas MCP server 4. Wait several minutes before retrying tools 5. Refresh your MCP configuration 6. Verify your API token is still active 7. Test the connection using a lightweight tool first 8. Avoid repeatedly reconnecting every few seconds 9. Monitor whether partial tool functionality returns 10. Contact support if: - the issue persists for several hours - or ALL MCP tools remain unavailable Important Notes - this is a server-side infrastructure issue - no client-side configuration change will fully resolve it - partial recovery may occur automatically during redeployment ⚠️ Error 2: MCP connection drops — "ClosedResourceError" What's happening Search Atlas MCP uses: - SSE (Server-Sent Events) - not persistent WebSockets. Idle or long-lived SSE connections may close automatically when: - inactive too long - network conditions change - or the client sleeps/restarts. Steps to try 1. Restart your MCP client 2. Reconnect the MCP server 3. Refresh your IDE or AI application 4. Confirm your internet connection is stable 5. Avoid leaving idle MCP sessions open for long periods 6. Enable auto-reconnect behavior in your MCP client if supported 7. Verify your MCP config includes: ​"transport": "sse" 8. Update Claude Desktop or Cursor to the latest version 9. Retry the tool call after reconnecting 10. Contact support if: - SSE connections disconnect immediately - or reconnection never succeeds Important Notes - SSE disconnections are expected occasionally - well-designed MCP clients should auto-reconnect automatically ⚠️ Error 3: Redis connection error when calling MCP tools What's happening The MCP rate-limiting and session middleware temporarily lost Redis connectivity. This affects: - authentication - throttling - tool execution - and session coordination. Steps to try 1. Wait 1–2 minutes before retrying 2. Retry the SAME tool call 3. Avoid launching multiple simultaneous MCP workflows 4. Refresh your MCP session 5. Restart the MCP client if errors continue 6. Test a lightweight tool call first 7. Verify whether dashboard features still work normally 8. Monitor whether failures occur across ALL tools or only one 9. Retry during off-peak hours if instability continues 10. Contact support if: - Redis errors persist for extended periods - or all tool calls fail repeatedly Important Notes - Redis outages are usually temporary - many Redis-related failures self-recover automatically ⚠️ Error 4: "ClientDisconnect" during MCP tool execution What's happening Your MCP client disconnected before the tool response completed. This commonly affects: - full site crawls - large keyword research jobs - AI content generation - or multi-step workflows. Steps to try 1. Increase timeout settings in your MCP client 2. Break large requests into smaller operations 3. Avoid extremely large multi-tool workflows 4. Retry the failed task individually 5. Use smaller keyword batches 6. Run site audits separately from content workflows 7. Keep your MCP client window active during execution 8. Avoid sleep/hibernation while tasks are running 9. Retry during lower traffic periods 10. Contact support if: - even small tool calls disconnect consistently - or timeouts occur immediately Important Notes - long-running SEO workflows naturally require longer timeout windows - staged workflows are more reliable than massive single-pass requests ⚠️ Error 5: OTTO tool returns 500 — "An unexpected error occurred" What's happening The MCP OTTO tool could not access a valid connected project. This usually happens when: - the project is disconnected - authentication expired - or the MCP token no longer matches the account state. Steps to try 1. Go to: Left Sidebar → OTTO SEO → All Sites 2. Confirm the project is active 3. Verify OTTO is connected correctly 4. Open the project directly in the dashboard 5. Confirm the OTTO module works outside MCP 6. Go to: mcp.searchatlas.com → Settings 7. Click Regenerate Token 8. Update your MCP client configuration with the new token 9. Restart the MCP client completely 10. Contact support if: - OTTO tools fail repeatedly across all projects - or token regeneration does not restore access Important Notes - MCP tokens can become stale after account or project changes - dashboard validation is the fastest way to isolate MCP-vs-project issues ⚠️ Error 6: Keyword Research tool returns 500 from Site Explorer What's happening The MCP keyword research tools depend on upstream Site Explorer and SEO intelligence services. Temporary upstream failures may interrupt: - keyword retrieval - backlink lookups - competitor analysis - or SERP aggregation. Steps to try 1. Retry the same tool call once 2. Wait 5–10 minutes before retrying again 3. Reduce: - keyword count - countries - or competitor scope 4. Run smaller queries first 5. Test Site Explorer directly in the dashboard 6. Avoid very broad bulk requests temporarily 7. Check whether only specific regions fail 8. Refresh your MCP session 9. Retry during off-peak usage windows 10. Contact support if: - all keyword tools consistently fail - or Site Explorer itself becomes unavailable Important Notes - upstream SEO data providers occasionally throttle requests - smaller scoped queries are more reliable during high-load periods ⚠️ Error 7: Website Studio tool returns "Internal server error" What's happening The Website Studio MCP tools depend on the underlying: - Landing Page Studio - generation queues - and deployment services. If the Website Studio infrastructure is unstable, MCP tools may fail even when the connection itself remains active. Steps to try 1. Wait 10 minutes before retrying 2. Test Website Studio directly inside the dashboard 3. Confirm page generation works manually 4. Retry the MCP tool after dashboard validation 5. Reduce generation complexity 6. Break full-site requests into smaller page-level tasks 7. Refresh your MCP session 8. Restart Claude Desktop or Cursor if needed 9. Retry with smaller prompts 10. Contact support if: - Website Studio MCP fails consistently - or dashboard generation is also broken Important Notes - MCP Website Studio failures usually reflect upstream generation instability - staged generation workflows are more stable than full-site generation ⚠️ Error 8: MCP tool list is incomplete — tools are missing What's happening The MCP manifest loaded partially or failed during initialization. This can cause: - missing tools - incomplete categories - or partially registered capabilities. Steps to try 1. Disconnect your MCP client completely 2. Restart: - Claude Desktop - Cursor - or your IDE 3. Force a full manifest reload 4. In Claude Desktop: - remove the Search Atlas MCP entry - from claude_desktop_config.json 5. Re-add the MCP server configuration 6. Confirm your plan includes the missing tools 7. Wait for the manifest to finish loading fully 8. Refresh the tool list manually if supported 9. Test whether only specific categories are missing 10. Contact support if: - major tool groups never appear - or manifests repeatedly load partially Important Notes - Search Atlas exposes 673+ MCP tools - large manifests may load progressively depending on client behavior Most MCP Server and AI Tool integration issues are not caused by broken AI models. They are usually related to: - distributed queue infrastructure - SSE streaming behavior - Redis connectivity - manifest loading - upstream service instability - authentication synchronization - or long-running workflow orchestration. Because MCP systems coordinate hundreds of tools across asynchronous infrastructure, temporary instability and reconnection behavior are expected during large-scale operations. 👉 The most stable MCP workflows come from: - smaller staged tool calls - proper timeout configuration - SSE-aware clients - moderate batching - async workflow design - and responsible API usage patterns

🔌 Search Atlas — CMS Integration Issues (WordPress, Shopify, Drupal, Contentful)

🔌 Search Atlas — CMS Integration Issues This article covers content sync, authentication, image handling, and field mapping for WordPress, Shopify, Drupal, and Contentful integrations. ⚠️ Error 1: Content isn't syncing to my CMS What's happening: The CMS connection may have lapsed or the connected user account lacks publishing permissions. Steps to try: 1. Check connection status: Top-right Corner Avatar → Settings → CMS Connectors → [Your CMS Domain] → Connection Status. Reconnect if it shows Disconnected. 2. Confirm the connected account has the right role: - WordPress: Administrator (Editor and Author accounts cannot connect the plugin) - Shopify: App must have write_content permission — reinstall the app if needed - Drupal: User must have content creation and publishing permissions - Contentful: Management API Token must have content management (read/write) scope on the target space and environment 3. Test a single article manual sync before attempting bulk sync. 4. After reconnecting, wait 5 minutes before syncing. 5. Contact support with the CMS type, error message, and article title. 🖼️ Error 2: Images appear broken in the CMS after syncing What's happening: Image URLs are relative or in a format the target CMS doesn't support. Steps to try: 1. Ensure all images in your Search Atlas content use full absolute URLs starting with https://. 2. Shopify: Convert WebP images to JPEG or PNG — older Shopify themes don't support WebP. 3. WordPress: Resize images over 8MB before syncing — that's the WordPress default upload limit. 4. Upload images directly to the Search Atlas media library first, then reference them from there. 5. Contact support with the image URL and CMS type, plus a screenshot of the broken image. 🚫 Error 3: Shopify sync returns 'Forbidden' or 'Permission Denied' What's happening: The Search Atlas Shopify app needs to be reinstalled to refresh permissions. Steps to try: 1. Reinstall the Search Atlas Shopify app from the Shopify App Store — this is the most reliable fix. 2. After reinstalling, go to Top-right Corner Avatar → Settings → CMS Connectors → [Your CMS] → Shopify → Reconnect. 3. In Shopify Admin → Apps → [Search Atlas App] → Permissions, confirm write_content is listed. 4. Wait 5 minutes after reinstalling before attempting a sync. 5. Contact support with your Shopify store URL and the exact error from the sync log. 🔄 Error 4: Direct CMS edits are being overwritten by Search Atlas syncs What's happening: Search Atlas is configured as the primary editor — syncs overwrite CMS versions. Steps to try: 1. Make all edits in Search Atlas Content Assistant, then sync — treat Search Atlas as your primary editor. 2. Look for a Sync Lock or Exclude from Sync option in the article settings to protect specific articles. 3. Pause auto-sync while editing in the CMS: Top-right Corner Avatar → Settings → CMS Connectors → [Your CMS Domain] → Disconnect. 4. Contact support to ask about enabling 'CMS as source of truth' mode if you primarily edit in your CMS. 📝 Error 5: Formatting (headings, bold, lists) is stripped after syncing in WordPress What's happening: The content format setting may be set to Plain Text instead of HTML. Steps to try: 1. For WordPress Gutenberg: try enabling 'Classic Block' format in sync settings. 2. Verify the content format is set to HTML, not Plain Text. 3. Re-sync the affected article and inspect the output in the WordPress block editor. 🔑 Error 6: Contentful connector fails with 'Invalid or expired Management API Token' What's happening: Previously, a backend bug (internal ref: CG-1641) caused the Contentful connector to reject valid Management API Tokens with an 'Invalid or expired Management API Token' error during setup. This bug has been resolved by the engineering team and the connector is now working as expected. Steps to try: 1. Retry connecting Contentful: Top-right Corner Avatar → Settings → CMS Connectors → Contentful → Connect. If you previously created a failed connection, remove it first and start fresh. 2. Generate (or reuse) a Contentful Management API Token from Contentful → Settings → API keys → Content management tokens. Personal Access Tokens or Content Delivery API keys will not work. 3. Ensure the token has access to the correct Space and Environment you intend to sync to, and that the token has not been revoked. 4. Paste the token into Search Atlas and complete the Space/Environment selection. 5. Run a single-article test sync before attempting bulk syncs. 6. If you still see 'Invalid or expired Management API Token' after the fix, contact support with: your Contentful Space ID, Environment, the timestamp of the failed attempt, and confirmation that the token was generated as a Content Management token. Note: If you opened a ticket about this error prior to the fix, please retry the connection — no further action is required from the Search Atlas side.

📘 Troubleshooting MCP Connection Issues

If you are unable to connect the Search Atlas MCP or your connection is not working correctly, this guide covers the most common causes and how to resolve them. The MCP connection relies on a working login session, valid plan access, and an active authentication token. When any of these fail, the connection may not complete or tools may not work after connecting. ⚙️ Step-by-Step: Fix MCP Connection Issues Follow these checks in order to resolve the most common causes of failure. 🔍 Issue 1 — You Are Not Logged Into Search Atlas What happens When the browser window opens during connection, the login flow fails or does not complete properly. How to fix Step 1 Open: 👉 https://dashboard.searchatlas.com Step 2 Sign in to your Search Atlas account Step 3 Return to your MCP client Step 4 Retry the connection process from within your MCP client. The exact steps to retry or reconnect vary by client (for example, Claude Code, Cursor, and other MCP-compatible tools each have their own reconnection UI) — refer to your client's documentation or our connection guide for client-specific instructions. 🔍 Issue 2 — Your Plan Does Not Include MCP Access What happens - The connection may complete - But MCP tools fail when executed This is because MCP access is controlled at the plan level. How to fix Step 1 Check your Search Atlas plan in the billing area of your dashboard: 👉 https://dashboard.searchatlas.com/billing Step 2 Confirm that MCP access is included on your current plan. MCP access is available on eligible paid Search Atlas plans — if you are unsure whether your tier qualifies, review the plan details on the billing page or visit the Search Atlas pricing page. Step 3 If MCP is not included, contact your account team or upgrade your plan 🔍 Issue 3 — Session Is Expired or Stale What happens - Authentication fails - Connection stops working after setup - Tool calls return errors This occurs when the authentication token is no longer valid. How to fix Step 1 Open your MCP client Step 2 Disconnect the Search Atlas MCP Step 3 Reconnect the MCP using the current Search Atlas endpoint: https://mcp.searchatlas.com/mcp/. The Search Atlas MCP server now uses the Streamable HTTP transport (it previously used SSE), so if you have an older SSE-based URL saved in your client configuration, replace it with the Streamable HTTP endpoint above before reconnecting. The exact reconnection steps differ by MCP client (Claude Code, Cursor, and others each handle this in their own UI) — see your client's documentation if you are unsure where to update the endpoint. Step 4 Complete the login flow again This triggers a fresh authentication session. 🔍 Issue 4 — “Invalid Token” Errors What happens The client reports an invalid token even after login. Why this happens The server rejects tokens that are close to expiration instead of allowing them to fail mid-request. How to fix Step 1 Disconnect the MCP Step 2 Reconnect the MCP Step 3 Complete a fresh login 🔍 Issue 5 — Connection Works but Tools Fail What happens - MCP connects successfully - But actions fail or return errors Possible causes - Plan does not include required product area - Quota is exhausted - Permissions are restricted How to fix Step 1 Check your plan entitlements Step 2 Check your quota usage Step 3 Retry the action after confirming access 🔍 Issue 6 — MCP Tool Fails When Deploying Domain-Level Schema What happens When attempting to deploy schema at the domain level through the MCP, the tool call fails with an HTTP 400 response containing the message otto_urls not found. Why this happens This is a known platform-side issue with domain-level schema deployment via MCP. It is not caused by a misconfiguration on your side, and the fix requires a platform update. How to fix Contact Search Atlas support to confirm your account is tracked against this issue, and watch for a platform update that addresses it. In the meantime, deploy schema through the Search Atlas dashboard instead of through the MCP where possible. 🔍 Issue 7 — Platform Outage or Backend Error What happens The MCP or Atlas Brain consistently fails even after you have verified your login, plan access, and reconnected with a fresh session. This can indicate a platform-wide outage or a backend error rather than a local configuration problem. How to identify a server-side issue - The same error occurs across multiple devices - The same error occurs in an incognito or private browser window - Other Search Atlas surfaces (dashboard, API) also return errors or load slowly - The error message references a 5xx status code or a generic backend failure How to fix Check for any reported platform issues, then contact Search Atlas support with the error message, the affected tool, and the approximate time of the failure. If you have already worked through Issues 1–3 above without success, this is the recommended next step. ⚠️ Additional Notes 1. The MCP uses the same authentication and rate limits as the Search Atlas API 2. A failed tool call may return a structured error with details 3. Reconnecting the MCP resolves most session-related issues Most MCP connection issues are caused by login state, plan access, or expired sessions. By checking these in order and reconnecting when needed, you can restore full access and continue using Search Atlas through your AI assistant.

📘 Understanding MCP Errors & How to Fix Them

These errors are not random — they follow predictable patterns based on quota, authentication, permissions, rate limits, or external system behavior. This article explains the most common MCP errors, what they mean, and exactly how to fix them step by step. 🧠 How MCP Errors Work Every MCP action goes through multiple checks before execution: authentication, permissions, quota, rate limits, and tool execution. 👉 If any of these checks fail, the MCP returns an error instead of executing the action. ⚙️ Step-by-Step: How to Diagnose Any MCP Error Step 1. Read the error message carefully. Step 2. Identify the error type: quota error, authentication error, permission error, rate limit error, or execution error. Step 3. Follow the fix for that specific error category. 🔍 Common MCP Errors & Fixes ❌ Error Type 1 — Quota Exhausted What happens: The action does not run, and the assistant reports insufficient credits. Why this happens: Your Search Atlas quota is fully used. How to fix: 1. Ask: "Check my quota." 2. Confirm usage is at limit. 3. Add credits or upgrade your plan. 4. Retry the action. ❌ Error Type 2 — Invalid or Expired Token What happens: You see an "Invalid token" error and authentication fails. Why this happens: Your session is expired or near expiration. How to fix: 1. Disconnect MCP in your client. 2. Reconnect MCP. 3. Complete login again. ❌ Error Type 3 — Permission / Access Denied What happens: The action fails immediately and the tool cannot execute. Why this happens: Your plan does not include the requested feature. How to fix: 1. Check your Search Atlas plan. 2. Confirm feature access. 3. Upgrade or enable the feature. 4. Retry the action. ❌ Error Type 4 — Rate Limit (429 Error) What happens: The request is rejected and the error message includes "429." Why this happens: Too many requests were sent in a short time. How to fix: 1. Stop sending requests. 2. Wait briefly. 3. Retry the request. 4. Reduce request frequency. ❌ Error Type 5 — Action Requires Approval What happens: The action does not run immediately and the system waits. Why this happens: The action is marked as requiring approval before it can run. How to fix: 1. Look for the approval prompt. 2. Review the action. 3. Approve it to proceed. ❌ Error Type 6 — External System Failure What happens: An integration action fails, with partial execution or no result. Why this happens: The external system isn't connected, an API failure occurred, or credentials are invalid. How to fix: 1. Check the integration connection. 2. Verify account access. 3. Retry the action. ❌ Error Type 7 — Tool Execution Failure What happens: The action starts but fails mid-execution. Why this happens: Invalid input, an incomplete request, or an upstream processing issue. How to fix: 1. Review your request. 2. Make it more specific. 3. Retry with clearer instructions. 🔁 Universal Debugging Workflow If you are unsure what failed, follow this exact sequence: 1. Check quota. 2. Check authentication. 3. Check permissions. 4. Check for an approval prompt. 5. Retry the action. ⚠️ Important Notes 1. MCP errors are predictable and structured. 2. Most issues fall into 4 categories: quota, authentication, permissions, and rate limits. 3. Approval and integration issues are secondary causes. 🧠 Best Practices to Avoid Errors Check before executing: Ask "Will this consume credits?" Use read-only first: Analyze before executing. Keep sessions active: Avoid token expiration. Be specific in requests: Clear input reduces failures. MCP errors are not random — they are signals that one part of the execution pipeline needs attention. By identifying the error type and following the correct fix, you can quickly resolve issues and continue working efficiently through your AI assistant, using the same Search Atlas capabilities, permissions, and quotas tied to your account. 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.

🛠️ GHL Bulk URL Analyzer: Valid URL Formats, Validation Rules & Error Troubleshooting

The GHL Bulk URL Analyzer processes multiple URLs at once to surface SEO insights at scale. Submitting URLs in the correct format prevents validation errors and ensures every URL in your list returns accurate results. ✅ Accepted URL Formats Every URL you submit must meet the following requirements: - Full protocol required: URLs must begin with https:// or http:// — for example, https://example.com/page - Valid domain and TLD: The domain must include a recognized top-level domain (TLD) such as .com, .org, .net, or .io - One URL per line: Enter each URL on a separate line with no commas or semicolons between entries - Full paths accepted: You may include subpaths, slugs, and query parameters — for example, https://example.com/blog/post-title - Mixed URL types supported: You can submit domains, subdomains, and target page URLs together in a single list — the analyzer automatically classifies each URL by type, so no manual pre-sorting or mode selection is required - Query strings with multiple parameters: URLs containing & in query strings (such as UTM parameters like ?utm_source=newsletter&utm_medium=email) are accepted. If you encounter validation errors on a multi-parameter URL, please report it to support so we can verify the validator behavior for your case When formatted correctly, the analyzer accepts your list and queues it for processing — results will appear in your list once complete, which may take a few moments depending on the number of URLs submitted. 🆕 What's New: Automatic URL Classification The analyzer now automatically detects whether each submitted URL is a domain, subdomain, or page-level URL. The previous manual mode-selection step has been removed, so you can paste any combination of URL types into a single batch without sorting them first. Each URL is classified individually and processed according to its detected type. ❌ URL Formats That Fail Validation The following formats are invalid and will cause the analyzer to reject your submission or return an error: - Missing protocol: www.example.com — every URL must include https:// or http:// - No recognized TLD: www.hp — a domain without a valid, recognized TLD will not be accepted - Subdomain typos: https://wwww.example.com (four w's instead of three) is treated as a malformed URL - Plain text or keywords: Entering a brand name or keyword phrase instead of a full URL will fail validation Remove or correct any invalid URLs before resubmitting your list. 🧾 How Invalid URLs Are Handled in a Batch When a list contains a mix of valid and invalid URLs, the analyzer flags the invalid entries and processes the valid ones rather than rejecting the entire batch. Invalid URLs are surfaced with an error indicator in the results view so you can identify exactly which entries need to be corrected. To resubmit, copy the flagged URLs, fix the formatting issue (missing protocol, invalid TLD, typo, etc.), and submit them as a new batch — there is no need to re-run URLs that already processed successfully. ⚠️ Understanding the "Request Failed with Status Code 500" Error You may see a "Request failed with status code 500" error when both of the following conditions are true: - Your previously analyzed URLs list is empty — no prior analyses exist in the tool yet - One or more URLs in your current submission are malformed, missing a protocol, or have an unrecognized TLD A 500 error is most often triggered by invalid input rather than a system outage, but it can also occur in the following situations: - Malformed batch: A single malformed URL in the list can cause the entire submission to fail when no prior analyses exist - Server-side processing failure: Occasional backend issues during bulk processing - Network timeout: Very large batches may exceed processing limits and time out - Special characters: Unencoded special characters in URLs can break validation To resolve it: 1. Review each URL in your list and confirm it starts with https:// or http:// 2. Check that every domain includes a recognized TLD such as .com or .net 3. Remove any partial domains, plain-text entries, or URLs with misspelled subdomains 4. Reduce the batch size if you submitted a very large list, and try again in smaller groups 5. Check for and remove any unencoded special characters 6. Resubmit the corrected list After resubmitting a valid list, the analyzer processes your URLs without the 500 error. If the error persists after confirming all URLs are valid and reducing batch size, contact support with a sample of the URLs you're submitting so the team can investigate. 🔍 Don't See Your Results Yet? If you submitted URLs successfully but don't see them in the results list right away, the submission likely did go through. Newly processed URLs may appear further down the list rather than at the top. To find them: - Scroll down through the existing results list - Use the Prev / Next Page buttons at the bottom of the list to navigate through additional entries - Refresh the tab if results still aren't visible — processing may still be completing in the background Avoid resubmitting the same URLs multiple times while waiting, as this can create duplicate analyses. 💡 Tips for Preparing a Clean URL List Follow these practices before pasting URLs into the Bulk URL Analyzer: - Copy URLs directly from your browser address bar — this guarantees the protocol is included - If exporting from a spreadsheet, verify that https:// is concatenated with the domain column before pasting - Check for leading or trailing spaces around each URL — extra whitespace can cause individual entries to fail - Prefer https:// over http:// for accuracy on SSL-enabled pages A clean URL list reduces submission errors and ensures the analyzer returns results for every URL in your batch. 🎯 You now know which URL formats the GHL Bulk URL Analyzer accepts and how to correct the most common validation errors. For analyzing your full site's pages in bulk at the domain level, see the Site Audit article in this Help Center.

🛠️ Cloudflare API Token Connected but OTTO Not Detected by Diagnostic Scan

A connected Cloudflare API token confirms authentication only — it does not confirm that the OTTO Worker script is deployed and routed to your domain. Work through the steps below to verify token permissions, Worker deployment, route configuration, and Cloudflare cache so the diagnostic scan at OTTO Settings → Diagnostics → Run Scan detects OTTO correctly. 📋 Recent Backend Fix — OTTO-1850 Detection Improvement A backend fix (OTTO-1850) was released to improve detection of the Cloudflare Worker installation method. For most new deployments, the diagnostic scan now correctly identifies an active OTTO Worker without manual intervention. If your site was affected before this fix shipped: - Re-run the diagnostic scan from OTTO Settings → Diagnostics → Run Scan to confirm the issue is resolved. - If the scan still reports OTTO as not found, continue with the manual verification steps below — token permissions, Worker deployment, route configuration, and cache may still need to be checked individually. ⚠️ Why a Connected Token Does Not Guarantee OTTO Detection Saving and validating a Cloudflare API token in OTTO settings confirms that OTTO can authenticate with your Cloudflare account. It does not confirm that the OTTO Worker script has been deployed and routed to your domain. The diagnostic scan checks for the OTTO Worker script on your live site — if the Worker was never published, is misrouted, or is blocked by a cache layer, the scan reports OTTO as not found even though the token shows as connected. Common causes of this mismatch: - The Cloudflare Worker script was not published after the token was saved in OTTO - The Worker route does not match your domain or subdomain - The API token is missing the Workers Scripts: Edit permission needed to deploy the Worker - Cloudflare's edge cache is serving a version of your site that predates the Worker deployment - DNS records are set to DNS-only (grey cloud) instead of proxied (orange cloud), bypassing Workers entirely 🔑 Step 1 — Verify the API Token Has the Correct Permissions A token with read-only access can validate successfully in OTTO but cannot deploy the Worker script. Confirm your token includes every required permission before moving on. 1. Log in to your Cloudflare dashboard and go to Profile → API Tokens. 2. Find the token you connected to OTTO and click Edit. 3. Confirm the token includes all of the following permissions: - Account: Workers Scripts — Edit - Account: Account Settings — Read - Zone: Workers Routes — Edit - Zone: Zone — Read 4. If any permission is missing, add it and click Continue to summary → Update token. 5. Return to OTTO settings and click Re-validate to refresh the connection with the updated token. After re-validating, you must manually retry the Worker deployment (or reconnect the integration) — OTTO does not automatically re-attempt deployment after a token permission error. 🛠️ Step 2 — Confirm the OTTO Worker Is Deployed in Cloudflare Validating the token in OTTO does not automatically publish the Worker. Verify that the Worker script exists and is active inside your Cloudflare account. 1. Log in to dash.cloudflare.com and go to Workers & Pages. 2. Verify that an OTTO Worker script appears in the list — look for a Worker named otto-worker (or the Worker name shown in your OTTO settings). 3. If the Worker is listed, click it and confirm its status shows as Active. 4. If the Worker is absent from the list, re-initiate deployment from OTTO settings: disconnect the Cloudflare integration, confirm the token permissions from Step 1, wait 30 seconds, then reconnect to trigger a fresh Worker deployment. Once the Worker appears as Active in Cloudflare, proceed to Step 3 to verify its route assignment. 🔗 Step 3 — Confirm the Worker Route Matches Your Domain A Worker that is deployed but not routed to your domain is invisible to the OTTO diagnostic scan. Verify the route covers your exact domain. 1. In the Cloudflare dashboard, select your domain from the home screen to open its zone. 2. Navigate to Workers Routes under the Workers & Pages section of your zone. 3. Confirm there is a route matching your full domain — for example, example.com/* or *.example.com/*. 4. If the route is missing or points to the wrong domain, click Add route, enter the correct pattern, and assign the OTTO Worker to it. Ensure the route covers both the www and non-www versions of your domain if your site uses both. A missing or mismatched Worker route is the most frequent cause of OTTO diagnostic scan failures on sites with a valid connected token. 🗑️ Step 4 — Purge the Cloudflare Cache and Re-run the Diagnostic Scan Cloudflare may be serving a cached version of your site that predates the Worker deployment. Purging the cache forces Cloudflare to serve the current live version so the OTTO Worker can respond correctly. 1. In the Cloudflare dashboard, select your domain. 2. Go to Caching → Configuration. 3. Click Purge Everything and confirm the action. 4. Return to Search Atlas and open OTTO settings for your site. 5. Click Run Diagnostic Scan to re-check the installation status. Important — WordPress sites without WP Rocket: OTTO sets a Cache-Control: public, max-age=3600 header on processed pages when WP Rocket is not active. This can cause Cloudflare (and other CDNs/edge servers) to aggressively cache pages — sometimes capturing a non-Worker-served version of your site before the OTTO Worker is fully registered. - Confirm whether WP Rocket or another caching plugin is active on your WordPress site. - If neither is active, the WP-329 fix corrected the header behavior on new responses — but previously cached responses at the Cloudflare edge persist until you purge them. - Always run Purge Everything in Cloudflare after deploying or re-deploying the OTTO Worker on a non-WP-Rocket WordPress site to clear stale, pre-Worker cached pages. If OTTO is now detected, the status in your OTTO dashboard will update to Active. No further action is needed. ⚠️ If the Diagnostic Scan Still Reports OTTO as Not Found If you have completed Steps 1–4 and the scan still fails, check these additional edge cases: - DNS proxy status: In your Cloudflare DNS settings, confirm the record for your domain shows an orange cloud (proxied). A grey cloud (DNS-only) routes traffic around Cloudflare entirely, so Workers never run. - Multiple Cloudflare accounts or zones: Confirm the API token belongs to the Cloudflare account that controls your domain's DNS. A token from a different account will validate in OTTO but cannot deploy to the correct zone. - Firewall rules or Page Rules: Check that no active Cloudflare firewall rule or Page Rule is set to bypass or block the Worker from running on your domain's routes. - Force a full reconnect: In OTTO settings, disconnect the Cloudflare integration, purge the Cloudflare cache again, wait 60 seconds, then reconnect to force OTTO to redeploy the Worker from scratch. If the issue persists after all of the above, contact Search Atlas support. Include your domain name, the name of your API token (not the token value itself), and a screenshot of your Cloudflare Workers Routes page so the team can diagnose the configuration quickly. 🎯 You have now verified the three layers required for OTTO detection: a correctly permissioned API token, an active deployed Worker, and a matching Worker route. For a complete walkthrough of the initial setup, see the OTTO Installation via Cloudflare guide.

🛠️ WP Plugin: Troubleshooting the "API Key Could Not Be Verified" Error

If the Search Atlas WordPress plugin displays "The API key could not be verified," follow the fixes below to identify the cause and restore your connection — most cases are resolved in under five minutes. ⚠️ Common Causes of This Error Verification fails when the plugin cannot authenticate your API key with Search Atlas. The most frequent causes are: - Incorrect or incomplete API key — a typo, extra space, or truncated string. - Expired or rotated key — the key was regenerated in the dashboard but the plugin still holds the old one. - Server blocking outbound HTTPS requests — a firewall, security plugin, or hosting restriction prevents your site from reaching api.searchatlas.com. - Invalid SSL certificate — the plugin communicates over HTTPS; a broken certificate blocks the verification request. - Outdated plugin or stale cache — an older plugin build or cached response interferes with authentication. 🔑 Fix 1 — Confirm and Re-enter Your API Key A typo or extra whitespace is the most common cause. Copy the key directly from your dashboard to eliminate manual-entry errors. 1. Log in to your Search Atlas dashboard. 2. Go to Settings → API Keys and click the copy icon next to your key — paste the value rather than typing it. 3. In WordPress admin, go to Search Atlas → Settings and clear the current value from the API Key field. 4. Paste the copied key and click Save Settings. You'll see a green "API key verified" confirmation when the key is accepted. If the error persists, continue to Fix 2. 🔄 Fix 2 — Regenerate Your API Key If the key looks correct but still fails, it may have been invalidated — for example, after a recent rotation or an account plan change. 1. In your Search Atlas dashboard, go to Settings → API Keys. 2. Click Regenerate Key to issue a new API key. 3. Copy the new key immediately — it is displayed only once. 4. In WordPress admin, go to Search Atlas → Settings, replace the old key with the new one, and click Save Settings. The plugin confirms a successful connection once the regenerated key is accepted. 🛡️ Fix 3 — Check Server Connectivity and Outbound Access Your WordPress server must be able to make outbound HTTPS requests to api.searchatlas.com. Firewalls, security plugins, or restrictive hosting environments can silently block these requests. Disable security plugins temporarily 1. Deactivate security plugins such as Wordfence or iThemes Security. 2. Retry the API key verification in Search Atlas → Settings. 3. If the key verifies, add api.searchatlas.com to that plugin's allowlist, then re-enable it. Confirm outbound HTTPS with your hosting provider - Contact your host and ask whether outbound connections to external APIs on port 443 (HTTPS) are permitted from your server. - Request that they whitelist api.searchatlas.com if outbound traffic is restricted at the server level. Verify that PHP cURL is enabled cURL is the PHP extension the plugin uses to make API requests. Confirm it is active before retrying verification. 1. In WordPress admin, go to Tools → Site Health → Info → Server. 2. Confirm cURL appears in the extensions list with a status of enabled. 3. If cURL is missing or disabled, contact your hosting provider to enable it. Once connectivity is restored, retry saving your API key in Search Atlas → Settings. The plugin will connect as soon as your server can reach Search Atlas. 🔁 Fix 4 — Clear Caches and Update the Plugin Stale cached responses or an outdated plugin build can prevent the verification request from completing correctly. 1. In WordPress admin, go to Plugins → Installed Plugins and check for a pending update to the Search Atlas plugin. Install any available update. 2. Deactivate your caching plugin (e.g., WP Rocket, W3 Total Cache, LiteSpeed Cache) and purge all cached files. 3. Go to Search Atlas → Settings, re-enter your API key, and click Save Settings. 4. Re-enable your caching plugin only after the key is successfully verified. Running the latest plugin version with a clean cache ensures the verification request reaches Search Atlas without interference. ⚙️ Fix 5 — Resolve SSL Certificate Issues The Search Atlas plugin sends all API requests over HTTPS. If your site's SSL certificate is invalid, expired, or missing, the verification handshake will fail before it reaches Search Atlas. - Open your site in a browser and confirm the padlock icon appears in the address bar. A warning triangle means the certificate is broken or untrusted. - If your certificate is expired or misconfigured, contact your hosting provider to renew or reinstall it. - If your WordPress site still runs on HTTP, update both URL fields to HTTPS at Settings → General → WordPress Address (URL) and Site Address (URL). Once your site has a valid SSL certificate, the plugin can establish a secure connection to Search Atlas and complete verification. 📞 Contact Search Atlas Support If you have worked through all five fixes and the error still appears, contact the Search Atlas support team. We can inspect your account status and API key configuration directly. Include the following details in your message to speed up resolution: - Your Search Atlas account email address. - Your WordPress site URL. - The exact error message shown in the plugin. - Which fixes from this article you have already tried. - Your hosting provider's name. 🎯 You now have a clear path to resolve the "API key could not be verified" error in the Search Atlas WordPress plugin. Once connected, see the Search Atlas Plugin Setup Guide to configure your first project and start tracking your SEO performance.

⚠️ OTTO Cache-Control Header Breaking WordPress Forms and Nonces on Non-WP-Rocket Sites

If OTTO is enabled on your WordPress site without WP Rocket active, a misconfigured Cache-Control header causes CDNs to cache pages containing WordPress security tokens (nonces), silently breaking forms, checkout flows, and login pages. A fix is now released — follow the steps below to purge affected cache and restore full form functionality. 🔍 What Is Causing the Problem When OTTO processes pages for non-logged-in visitors and WP Rocket is not active, it sets this HTTP response header on every processed page: Cache-Control: public, max-age=3600 This instructs CDNs and edge servers — including Cloudflare and Pressable, plus any reverse-proxy or server-side cache that respects Cache-Control: public (for example, Nginx FastCGI cache) — to cache the complete HTML of each page and serve that identical copy to every visitor for up to one hour. WordPress pages typically contain nonces — short-lived security tokens embedded directly in form HTML that WordPress generates uniquely per user session. When a CDN caches a page with a nonce baked in, every subsequent visitor receives that same stale token. WordPress rejects it on submission, causing the form to fail — usually without displaying an error to the visitor. Any visitor who received a cached page can also read the nonce value directly from the HTML source and replay it to submit authenticated requests on behalf of the form owner before it expires (up to one hour). For WooCommerce and enterprise sites, this is a non-trivial security risk. Operations broken by stale nonces include: - Contact and lead-capture forms (Contact Form 7, Gravity Forms, WPForms, etc.) - WooCommerce add-to-cart and checkout flows - Login and password-reset forms - Any WordPress AJAX action that uses a nonce for verification 🖥️ Configurations Affected by This Issue You are affected if all three of the following are true for your site: - OTTO is enabled and actively processing your WordPress site - WP Rocket is not installed or is inactive - Your site sits behind a CDN or edge cache — Cloudflare and Pressable are the confirmed affected providers, plus any reverse-proxy or server-side cache that respects Cache-Control: public (for example, Nginx FastCGI cache) When WP Rocket is active, it manages its own cache-control headers and OTTO defers to WP Rocket's configuration, preventing the conflicting public header from being set — your site is not affected by this issue. 🚨 Symptoms of CDN-Cached Nonces Look for these signs that stale nonces are breaking your site: - Form submissions silently fail — the page reloads or nothing happens after clicking Submit - WooCommerce cart or checkout throws a security error or session warning - Login or password-reset forms return an "Invalid token" or similar nonce error - Forms work correctly immediately after purging your CDN cache, then begin failing again within an hour - Browser developer tools show form POST requests returning 403 errors or a -1 nonce-verification failure in the response body 🔬 How to Check If Your Site Is Currently Affected Self-diagnose in under a minute using your browser's developer tools: 1. Open your site in Chrome, Edge, or Firefox and press F12 to launch developer tools. 2. Select the Network tab, then reload a page that contains a form. 3. Click the top-level page request in the Network list and open the Headers panel. 4. Under Response Headers, look for Cache-Control: public, max-age=3600. If you see that exact header and WP Rocket is not active on your site, your site was affected before the fix was deployed — complete the remediation steps below. 🛠️ Remediation Steps After the Fix The incorrect Cache-Control: public, max-age=3600 header has been corrected in the latest OTTO WordPress plugin release. Confirm your site is running the patched version before purging caches — without the update, newly generated pages will continue to receive the bad header. Complete all steps below to fully restore form functionality. 1. Confirm OTTO is updated to the patched release. In your Search Atlas dashboard, open OTTO and verify you are running the latest version of the OTTO WordPress plugin. Apply any available update before continuing. 2. Purge your CDN cache in full. Stale cached pages containing old nonces will continue causing failures until removed: - Cloudflare: Log in → select your domain → go to Caching → Configuration → click Purge Everything. - Pressable: Log in to the Pressable dashboard → select your site → click Clear Cache. - Other CDNs: Use the full-site purge option in your provider's control panel or API. 3. Purge your WordPress server-side cache (if applicable). In your WordPress admin panel, use your caching plugin's Delete All Cache or equivalent option to remove any locally cached copies as well. 4. Test all affected forms. Submit a test entry on each form type — contact, checkout, and login. Successful submissions confirm the fix is active. Once the CDN cache is cleared, newly generated pages will carry the corrected headers and WordPress nonces will remain fresh for every visitor. ✅ How to Verify the Corrected Cache-Control Header To confirm OTTO is no longer setting the problematic header on your pages: 1. Open your browser's developer tools (press F12) and select the Network tab. 2. Load a page on your site that contains a form. 3. Click the page request in the Network tab and open the Headers panel. 4. Under Response Headers, confirm that Cache-Control: public, max-age=3600 is no longer present. If the header is still present after completing the remediation steps, confirm the OTTO update was applied successfully and repeat the full CDN cache purge before re-testing. 📌 Related Cloudflare Issue (OTTO-1931) If you use the OTTO Cloudflare DNS integration and notice OTTO-deployed changes reverting shortly after being applied, that is a separate, already-resolved issue tracked as OTTO-1931 — not a return of the cache-control bug described in this article. After updating OTTO to the latest WordPress plugin release, both issues should be resolved. If you continue to see Cloudflare DNS changes reverting after the update, contact Search Atlas Support so the team can investigate your specific deployment. 🎯 You now understand why OTTO's public Cache-Control header caused CDNs to serve stale WordPress nonces and silently break form submissions — and after updating OTTO and performing a full CDN cache purge, your forms should be fully operational. If you continue to see form failures after completing all steps, contact Search Atlas Support for hands-on assistance.

🔗 Syncing WordPress to Publish Content

Seeing WordPress marked as connected in your Brand Vault and OTTO, yet still unable to publish a blog post directly to your client's site? This is usually caused by a missing or incomplete sync between your Search Atlas project and the WordPress destination. This guide walks you through checking the connection and publishing successfully. 🧩 Why the Connection Shows But Publishing Fails A WordPress site can appear connected in your Brand Vault and in OTTO while the Content tab still lacks an active publishing link. The Brand Vault and OTTO connections handle site-level integrations, but publishing a blog post requires the WordPress destination to be selected and synced within the Content tab itself. If this final step is missing, the publish button will not push your post to the live site. ✅ Confirm Your WordPress Prerequisites Before publishing, make sure the following are in place: - Plugin installed: The Search Atlas (or OTTO) WordPress plugin must be installed and activated on the client's site. - Correct site URL: The connected domain must match the exact URL of the site you want to publish to, including the correct www or non-www version. - User permissions: The connected WordPress account must have Administrator rights so it can create and publish posts. - Active API key: Confirm the API key or connection token has not expired or been regenerated on the WordPress side. 🔄 Sync WordPress in the Content Tab Follow these steps to link and sync your site for publishing: 1. Open your project and go to the Content tab. 2. Select the article or blog post you want to publish. 3. Click the Publish or Publishing Settings option. 4. Under the destination or integration menu, choose WordPress. 5. Select the correct WordPress site from the dropdown. If it is not listed, click Refresh or Reconnect to pull the latest connections. 6. Once the site appears, confirm it shows a Connected or Synced status inside the Content tab. 7. Click Publish to send the post directly to WordPress. 🛠️ Troubleshooting a Failed Publish If publishing still does not work after syncing, try these steps in order: - Reconnect the site: Go back to the Brand Vault, disconnect WordPress, then reconnect it and repeat the sync in the Content tab. - Update the plugin: An outdated plugin can block publishing. Ask the client to update it to the latest version. - Check the post status: Ensure the post is not stuck in draft or missing a required field such as a title or slug. - Clear the destination cache: Refresh the destination dropdown so it loads current site data instead of a cached entry. - Verify a single connection: Duplicate WordPress connections can cause conflicts. Remove any extra or outdated links so only the correct site remains. 🚀 Confirm the Post Went Live After publishing, verify success by doing the following: 1. Return to the Content tab and check that the post status changed to Published. 2. Open the client's WordPress dashboard and confirm the post appears under Posts. 3. Visit the live URL to make sure the content displays correctly. If the status remains stuck or shows an error, note the exact message displayed, as this helps identify the cause quickly. 💬 Still Need Help? If you have completed these steps and still cannot publish to your client's WordPress site, we are happy to help. 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.

🛠️ Pub Media Articles Publishing as Drafts in WordPress MetaSync

A confirmed bug in the WordPress MetaSync plugin (WP-277) silently saved Pub Media articles as Drafts instead of publishing them live. Update the patched plugin release, then use the steps below to identify and republish any affected posts. 🐛 Why Pub Media Articles Published as Drafts A confirmed bug in the WordPress MetaSync plugin caused articles sent from Pub Media to default to Draft status in WordPress — even when the publish payload was correctly configured on the Pub Media side. No error message appeared in either Pub Media or MetaSync, making this a silent failure detectable only by checking WordPress post status directly. ⚠️ Scope: This issue affects only the Pub Media → MetaSync publishing flow. Content Genius users publishing to WordPress via MetaSync are not impacted. - 📋 Affected workflow: Pub Media publishing via the WordPress MetaSync plugin - 🔴 Symptom: Articles appear as Drafts in WordPress instead of Published - 🔇 Failure type: Silent — no error or warning surfaces in Pub Media or MetaSync - 🔍 SEO metadata: Expected to be preserved — verify title, description, and schema fields on each affected post before republishing 🔍 How to Confirm You Are Affected Check whether your Pub Media articles were silently saved as drafts: 1. Log in to your WordPress dashboard. 2. Navigate to Posts → All Posts. 3. Click the Drafts filter at the top of the list. 4. Look for articles you intended to publish from Pub Media. If they appear here instead of under Published, you are affected. ✅ You are affected when Pub Media articles appear as Drafts in WordPress with no corresponding error in Pub Media or MetaSync. 🔧 How to Fix Articles Stuck as Drafts ✅ This bug has been fixed (tracked as WP-277) — follow the steps below to update your plugin and restore affected posts. ⬆️ Step 1 — Update the MetaSync Plugin 1. In your WordPress dashboard, go to Plugins → Installed Plugins. 2. Find WordPress MetaSync and check the version number shown below the plugin name. 3. Click Update if an update is available to install the patched release containing the WP-277 fix. If you are unsure which version contains the fix, check the MetaSync WP-277 release notes or contact Search Atlas support to confirm. ⚠️ Do not skip this step. Manually publishing existing drafts without updating the plugin means new articles sent from Pub Media may still land as drafts. 📝 Step 2 — Publish Affected Draft Posts After updating the plugin, go to Posts → All Posts and click the Drafts filter. Choose one of the following methods: - ✏️ Individual publish: Open each affected post and click Publish. - ⚡ Bulk publish: Select all affected posts using the checkbox at the top of the list, choose Edit from the Bulk Actions dropdown, set the status to Published, and click Update. 🔄 Step 3 — Re-send from Pub Media (Optional) If you prefer posts to go live through the original Pub Media publish flow, trigger a new publish from Pub Media after updating the plugin — the updated plugin will now correctly honor the publish status in the payload. ⚠️ Important: Re-sending will overwrite any manual edits made to the draft in WordPress. If you have edited the draft directly, publish it from WordPress first rather than re-sending. 🆘 When to Contact Support Contact the Search Atlas support team if any of the following apply: - ❌ Articles still publish as drafts after updating the MetaSync plugin - 🔒 You cannot update the plugin independently (for example, in a managed or agency-managed WordPress environment) - ⚠️ You notice other silent status mismatches in the Pub Media → MetaSync workflow - 📦 You have a large volume of affected drafts and need assistance with bulk remediation When reaching out, include your MetaSync plugin version number and a screenshot of the Drafts list in WordPress to help the team diagnose quickly. ❓ Frequently Asked Questions 🤔 Why did no error appear when my articles published as drafts? The bug caused MetaSync to silently override the publish status in the payload received from Pub Media. Because nothing failed visibly, the issue was only detectable by checking WordPress post status directly. 🏷️ Is my SEO metadata still intact on the draft posts? SEO metadata — including title tags, meta descriptions, and any custom fields set in Pub Media — is expected to be preserved on the draft. Verify title, description, and schema fields on each affected post before republishing to confirm everything is in place. 👥 Are all Pub Media users affected? Only customers publishing via the WordPress MetaSync plugin are affected. Other Pub Media publishing integrations are not impacted. Content Genius users publishing to WordPress via MetaSync are also not affected. 🔁 What if I already resent articles from Pub Media before updating the plugin? Re-sent articles may also be saved as drafts if the plugin was not yet updated. After updating, check your Drafts list for both the original and any re-sent versions. Remove duplicates before publishing to avoid duplicate content issues on your site. 🏗️ What if my WordPress host manages plugin updates and I cannot update myself? Contact your hosting provider or WordPress administrator and request an update to the latest version of the MetaSync plugin (the release containing the WP-277 fix). If you need help communicating the issue to your host, reach out to the Search Atlas support team and we can provide the technical details needed. 🔮 Will this happen again after I update the plugin? No. The bug is resolved in the patched release of MetaSync (WP-277). Once updated, new articles sent from Pub Media will publish live as expected — no further action is needed for future posts. 🎯 Update the WordPress MetaSync plugin to the patched release (WP-277), then publish any affected drafts from your WordPress dashboard — individually or via Bulk Actions. If articles still land as drafts after updating, contact our support team with your plugin version number and a screenshot of the Drafts list.

🛠️ WordPress Plugin: API Key Verification Fails When Your Home URL Uses www

If the Search Atlas WordPress plugin reports connected: false even though your API key is valid, and your WordPress Home URL starts with www. (or your server redirects non-www traffic to www), a now-fixed bug triggered a false verification failure. Update the plugin to resolve this immediately. ⚠️ Confirm This Is Your Issue This article applies when all of the following are true: - The Search Atlas plugin displays connected: false or an API key verification error. - Your API key is valid — it appears correctly in your Search Atlas dashboard. - Either your WordPress Home URL (Settings → General → Site Address) starts with www. — for example, www.yoursite.com — or your server automatically redirects non-www URLs to the www version. Before you continue — confirm you are using the correct credential: Ensure you are using the Search Atlas API Key found under Settings → API Keys (a 32-character code) — not the OTTO UUID (the data-uuid attribute shown in the Installation Guide). These are different values, and using the OTTO UUID in place of the API Key will also cause verification to fail. 🔍 Why the www Prefix Causes Verification to Fail There are two related scenarios that trigger this failure, both resolved by the latest plugin version: - Scenario 1 — Home URL mismatch: The plugin's connection check reads your WordPress Home URL and extracts the hostname to send to the Search Atlas verification endpoint. When the Home URL includes www. but the domain associated with your Search Atlas workspace (visible in Settings → General or your OTTO project settings) is registered without it, the hostnames do not match and the endpoint returns a failed status — even though your API key is correct. - Scenario 2 — Server-level non-www → www redirect: If your server automatically redirects non-www URLs to www (for example, via .htaccess, nginx config, or a CDN rule), the redirect can intercept the SSO connect callback and heartbeat POST requests, causing them to fail before the plugin completes verification. Both scenarios are resolved in the latest version of the Search Atlas WordPress plugin. 🛠️ Fix: Update the Search Atlas WordPress Plugin Updating to the latest plugin version applies the fix automatically. No changes to your API key or WordPress URL settings are required. 1. In your WordPress admin, go to Plugins → Installed Plugins. 2. Locate Search Atlas in the plugin list and note the installed version number. 3. If an update is available, click Update Now. The fix is included in the most recent release. If you are unsure which version contains the fix, contact Search Atlas support to confirm. 4. After the update completes, open the Search Atlas plugin settings, re-enter your API key if prompted, and confirm the plugin now shows connected: true. The plugin will now correctly verify your API key whether or not your Home URL includes www., and regardless of server-level non-www → www redirects. ⚙️ Temporary Workaround (If You Cannot Update Immediately) If you need to connect the plugin before updating, temporarily remove the www. prefix from your WordPress Site Address: 1. In WordPress admin, go to Settings → General. 2. In both the WordPress Address (URL) and Site Address (URL) fields, remove www. so the value reads yoursite.com. 3. Click Save Changes. 4. Open Search Atlas plugin settings, enter your API key, and click Connect. Verification should succeed. 5. Update the plugin as soon as possible, then restore your www. prefix in Settings → General if needed. Important: Changing your Site Address can affect site redirects and internal links. Apply this workaround only if you are comfortable managing WordPress URL settings. ✅ Verify the Connection Is Active After updating (or applying the workaround), confirm the plugin is connected: - In WordPress admin, go to Search Atlas → Settings. - The status should display connected: true or show a green confirmation indicator. - If the error persists after updating, confirm the API key matches exactly what appears in your Search Atlas dashboard under Settings → API Keys. 🧰 If the Error Persists After Updating In some cases, updating alone may not immediately resolve the problem. If you still see connected: false after updating, work through these steps in order: 1. Deactivate and reactivate the Search Atlas plugin from Plugins → Installed Plugins. 2. Clear your browser cache (or try an incognito/private window) and reload the plugin settings page. 3. Re-copy the API key directly from Settings → API Keys in your Search Atlas dashboard and re-enter it in the plugin — making sure you are not pasting the OTTO UUID by mistake. 4. Contact Search Atlas support with your site URL, the installed plugin version, and a screenshot of the error. 🌀 Updating the Search Atlas WordPress plugin resolves the false API key verification error triggered by a www Home URL or a server-level non-www → www redirect. If connection errors continue after updating, contact Search Atlas support for further assistance.

⚠️ WordPress Plugin Header Incorrectly Shows "Not Connected" on Idle Pages

If your Search Atlas WordPress plugin header shows a red "Not Connected" badge after the page has been idle, refresh the page — your API key and connection remain intact. This is a known display glitch caused by temporary background-check failures during idle sessions. 🔴 What the "Not Connected" Status Badge Means The badge in the Search Atlas plugin header reflects the result of the most recent background check between your WordPress site and the Search Atlas API. A green dot means the last check succeeded; a red "Not Connected" dot means the most recent check failed. The badge updates automatically while any plugin page is open. After several minutes of inactivity, those background checks can fail for temporary reasons unrelated to your API key or account status. 💡 Why Idle Pages Trigger a False "Not Connected" Badge The plugin runs a background process that sends periodic requests to the Search Atlas API to sync your connection status. On idle pages, these requests can be blocked or dropped due to: - Temporary rate limiting on the server side — no action needed; the next check will succeed on its own - Transient network errors — a brief hiccup returns an empty or null API response - Request timeouts — the request times out before the Search Atlas API responds When any of these temporary failures occur, the badge flips to "Not Connected." This is a known display issue currently under engineering review. A permanent fix is targeted for an upcoming plugin release, and we will update this article once it is deployed. The badge does not accurately reflect your actual connection state when triggered by idle-session check failures. 🔍 How to Confirm the "Not Connected" Badge Is a False Alarm Before changing your API key or reinstalling the plugin, run these checks to confirm you are looking at a false alarm: 1. Refresh the page. If the badge returns to green immediately after a refresh, the disconnect was caused by an idle-session check failure — not a real connection problem. 2. Check how long the page was idle. If you stepped away for several minutes before noticing the red badge, idle-session failure is the most likely cause. 3. Navigate away and return. Go to a different Search Atlas plugin page and come back — a green badge on the fresh page load confirms your connection is intact. If the badge turns green after any of these steps, your connection is working correctly and no further action is needed. 🔄 How to Restore the Correct Connection Status After an Idle Session To clear the false "Not Connected" badge, follow these steps: 1. Press F5 (Windows / Linux) or Cmd + R (Mac) to refresh the current plugin page, or click your browser's Reload button. 2. Wait for the page to finish loading — the header badge updates within a few seconds. 3. Confirm the badge now shows a green dot and reads "Connected." All Search Atlas features — rank tracking, site audits, and keyword research — are fully accessible immediately after the refresh. No re-authentication or settings change is required. 🛠️ What to Do If the Badge Still Shows "Not Connected" After Refreshing If the badge remains red after a full page refresh, you may have a genuine connection problem. Work through these steps in order: 1. Verify your API key. Go to Search Atlas → Settings → API Key and confirm the key is entered correctly with no extra spaces or missing characters. 2. Check your account status. Log in at app.searchatlas.com and confirm your subscription is active. 3. Deactivate conflicting plugins. Security or caching plugins can block outgoing API requests. Temporarily deactivate them one at a time to isolate any conflict. 4. Check server firewall rules. Ask your hosting provider to confirm that outbound HTTPS requests to api.searchatlas.com are permitted. 5. Re-save your API key. In Search Atlas → Settings, clear the API key field, re-enter your key, and click Save Changes. If none of these steps resolve the issue, contact Search Atlas support and include your WordPress version, plugin version, and any error messages shown in your browser console (press F12 to open it). 🌀 A red "Not Connected" badge on an idle plugin page is almost always a temporary display glitch — a single page refresh is all it takes to recover. To review your full plugin setup, see Connecting the Search Atlas WordPress Plugin.

🛠️ Fix WordPress CMS Sync Failures

🔍 What This Article Covers If you have connected WordPress to Search Atlas and your content is not publishing or syncing correctly, this guide will walk you through the most common causes and the exact steps to resolve them. We will also explain how to escalate to our engineering team if standard troubleshooting does not fix the problem. ⚙️ How WordPress CMS Sync Works Search Atlas connects to your WordPress site through the Search Atlas plugin. When you publish or update content from Content Genius (Left sidebar → Content → Content Genius), Search Atlas sends that content to WordPress using an authenticated connection. If that connection breaks or WordPress rejects the request, the sync fails and your changes will not appear on your site. ⚠️ Common Reasons Sync Fails WordPress sync issues typically fall into one of these categories: - Plugin authentication failure — The connection token between Search Atlas and your WordPress site has expired or was revoked. - WordPress plugin outdated — You are running an older version of the Search Atlas plugin that is no longer compatible. - Security plugin blocking requests — A firewall, security plugin, or server-level rule is blocking Search Atlas API requests. - Missing or changed credentials — Your WordPress admin password, application password, or site URL has changed since the initial connection. - Server timeout or resource limits — Your WordPress server is rejecting long-running requests, which can happen with large articles or bulk publishing. 🚀 Step-by-Step Troubleshooting Follow these steps in order. After each step, try syncing a single article to see if the issue is resolved. 1. Verify your WordPress site URL — In Search Atlas, go to your CMS connection settings and confirm the site URL matches exactly what you see in your browser, including https:// and no trailing slash. 2. Update the Search Atlas plugin — Log in to your WordPress admin dashboard, navigate to Plugins, and make sure the Search Atlas plugin is updated to the latest version. If an update is available, install it and reconnect. 3. Re-authenticate the connection — Disconnect WordPress from within Search Atlas, then reconnect it fresh. This generates a new authentication token and resolves most stale-credential issues. 4. Check for security plugin interference — Temporarily disable any WordPress security or firewall plugins (such as Wordfence, Sucuri, or Cloudflare WAF), then attempt a sync. If it succeeds, whitelist the Search Atlas plugin or API endpoints in your security tool. 5. Test with a simple article — Create a short test article in Content Genius and try publishing it. If a simple article publishes but a larger one does not, the issue is likely a server timeout. Contact your hosting provider to increase PHP max_execution_time and memory_limit. 6. Check WordPress permalinks — In WordPress admin, go to Settings → Permalinks and click Save Changes even if you have not modified anything. This refreshes WordPress rewrite rules and can resolve hidden routing issues. 📊 How to Confirm Sync Is Actually Working After completing the troubleshooting steps, do not rely solely on the success message inside Search Atlas. Open your WordPress site in a new browser tab and verify that: - The article appears in your WordPress Posts or Pages list. - The title, body content, and meta description match what you published. - The published date and author are correct. - Any images or media included in the article uploaded successfully. If Search Atlas shows a success message but the content is missing or incomplete in WordPress, the sync is partially failing. Proceed to the escalation steps below. 💡 What We Fixed Recently Our engineering team has resolved several known issues related to WordPress sync. If you experienced problems in the past and were told they were fixed but the issue persists, it is possible that a different root cause is now in play. Recent fixes include: - Plugin authentication failures that prevented Content Genius and Content Sync from connecting to WordPress independently of OTTO. - Silent sync failures — the system previously did not always surface errors when a sync failed. It now reports failures clearly so you and our team can act on them. - Brand Vault errors — some sync attempts failed with "No brand vault found" due to a data configuration issue. This has been corrected. Because multiple issues shared similar error messages, it was possible for one fix to resolve your case while a separate, underlying issue remained. If you are still seeing problems, the fastest path to resolution is the escalation process below. 🛠️ Escalating to Engineering If you have completed every troubleshooting step above and WordPress sync is still not working, our engineering team needs specific information to investigate efficiently. When you contact support, provide the following: - Your WordPress site URL. - The version of the Search Atlas plugin installed on your WordPress site. - The exact name of the article or articles that failed to sync. - The date and time (including your timezone) of the most recent failed sync attempt. - A screenshot of any error message you see, either in Search Atlas or in WordPress. - The name of any security plugins running on your WordPress site. With this information, our team can trace the exact request, identify where it is failing, and push a fix or configuration change. 💬 Still Need Help? 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.

🛠️ Fix OTTO Pixel Wrong Domain Error on GoHighLevel

🔍 What This Error Means The wrong domain error appears when the OTTO Pixel installed on your GoHighLevel site does not match the project domain registered in OTTO. When the domains do not match, OTTO cannot verify the connection, and Atlas Brain is blocked from deploying your SEO fixes. The most common cause on GoHighLevel is using a White Label (WL) pixel when your OTTO project expects a Search Atlas (SA) pixel, or the reverse. 💡 WL Pixel vs SA Pixel OTTO offers two versions of the Pixel, and they are not interchangeable. Installing the wrong one is the leading cause of this error. - SA Pixel (Search Atlas): The standard pixel issued to accounts that use Search Atlas branding. - WL Pixel (White Label): The pixel issued to accounts running on a White Label or agency-branded domain. Your OTTO project will only validate the pixel type that matches your account configuration. If your project is set up as White Label, you must deploy the WL pixel; if it is a standard Search Atlas project, you must deploy the SA pixel. ⚙️ Why the Error Happens on GoHighLevel GoHighLevel lets you add custom code through site or funnel settings, so it is easy to paste a pixel that belongs to a different domain or a different pixel type. The error is usually triggered by one of these issues: - The WL pixel was installed on a project expecting the SA pixel, or the SA pixel was installed on a White Label project. - The pixel was copied from a different OTTO project or domain. When the pixel actually belongs to a different OTTO account or project, OTTO may report it as a wrong_uuid / account mismatch rather than a simple domain mismatch—in that case the fix is to copy the pixel from the correct project under the correct account. - The domain in OTTO includes www or https:// while the live GoHighLevel site uses a different format. - The pixel was added to a staging or preview URL instead of the published domain. 🛠️ How to Fix It Step by Step 1. Open OTTO and select the affected project. 2. Confirm the exact domain listed in the project settings. Note whether it uses www and the correct protocol. 3. Identify whether your project is a Search Atlas or White Label project. This determines which pixel you need. 4. Copy the correct pixel code directly from your OTTO project. Always copy a fresh version rather than reusing an older snippet. 5. In GoHighLevel, go to Sites, then open the relevant funnel or website, and navigate to the settings where custom code or tracking code is added. 6. Remove any existing OTTO pixel to avoid duplicate or conflicting installs. 7. Paste the correct pixel into the header or tracking code section, then save and publish. 8. Make sure the published domain matches the domain registered in OTTO exactly. ✅ Verify the Fix After publishing, return to OTTO to confirm the connection is healthy. 1. Open your OTTO project and check the pixel status. 2. Wait a few minutes for OTTO to re-scan the live site. 3. Confirm the wrong domain error has cleared and the pixel shows as verified. 4. Check that Atlas Brain can resume deploying your SEO fixes. If the status does not update right away, clear your cache or open the live domain in a private browser window to ensure the published pixel is loading. In rare cases the pixel can show as detected and verified while the project still does not move out of an unactivated state. If the wrong domain error has cleared and the pixel is verified but your project stays unactivated, this is a separate condition from the domain mismatch—start a live chat so our team can review and activate the project on their end. 🚀 Tips to Prevent Future Errors - Always copy the pixel from the specific OTTO project it belongs to. - Match the pixel type to your account: WL pixel for White Label projects, SA pixel for Search Atlas projects. - Keep the domain format in OTTO identical to your live GoHighLevel domain. - Install the pixel on the published site, not a preview or staging URL. - Remove old pixels before adding a new one. ⚠️ Known Issues to Be Aware Of - GoHighLevel detected as “Custom CMS”: OTTO can sometimes label a GoHighLevel site as a Custom CMS instead of GHL during detection. This is a known issue that has been logged with our engineering team and is currently scheduled for development, so if you see this label, follow the manual pixel steps above rather than relying on automatic CMS detection. - WL pixel blocked by antivirus: On some white-label domains, the OTTO pixel script was previously flagged as phishing by tools such as Avast and VirusTotal, which could stop the pixel from loading. This issue has been resolved—make sure your security software and definitions are up to date if a WL pixel still appears blocked. - Pixel/UUID not detected behind Cloudflare: If your GoHighLevel domain is proxied through Cloudflare, the pixel or UUID may fail to be detected even after a successful deployment. This was a known issue that has since been resolved—if you still encounter it, copy a fresh pixel from your OTTO project, republish, and allow a few minutes for OTTO to re-scan. - WL pixel on White Label domain aliases: For White Label domains that use domain aliases, our engineering team is currently working on routing the OTTO pixel traffic through a CDN to improve detection reliability. This work is in development, so if a WL pixel on an aliased domain still fails to validate, copy a fresh pixel, republish, and contact support if the error persists. 💬 Still Need Help? If you have confirmed the correct pixel type and matching domain but the error continues, our team can review your specific setup. If you need further assistance, click the chat icon in the bottom-right corner of the platform to start a live chat with a member of our team.

🔧 Fixing the "unexpected_error" When Syncing Content to WordPress

📋 Overview When you push or repost content from Search Atlas to your WordPress site, you may occasionally see an "unexpected_error" message during the sync. When this happens, your changes are not saved to the live page, even though the edit looks complete on your end. This error almost always points to a connection or permissions issue between Search Atlas and WordPress. The good news: it is usually quick to fix. This guide walks you through the most common causes and how to resolve each one. 🔍 Common Causes - The WordPress connection (integration) has expired or been disconnected. - The connected user account no longer has permission to edit or publish the page. - A WordPress security plugin or firewall is blocking the request. - The page or post was deleted, moved to a draft, or had its URL changed in WordPress. - A temporary server timeout caused by very large content or slow hosting. ⚡ Quick Fixes to Try First 1. Wait one to two minutes and retry the sync. Many "unexpected_error" messages are temporary timeouts. 2. If you just triggered a sync from the Search Atlas dashboard (Left sidebar → Content → Content Genius (What are we writing today?) — using the CMS SYNC column), you may instead see a "Request Throttled — Please make another request after 5 minute(s)" notice. This is a normal cooldown — wait the full five minutes before trying again. 3. Confirm the page still exists in WordPress and is published (not in Draft or Trash). 4. Make a small edit again in Search Atlas and resync to confirm the issue repeats. If the error continues, work through the steps below. 🔌 Step 1: Reconnect Your WordPress Integration An expired connection is the most frequent cause of this error. 1. In Search Atlas, go to Settings > Integrations (or the WordPress connection panel for your project). 2. Locate your WordPress site and select Disconnect. 3. Select Connect and sign in to WordPress again, approving the requested permissions. 4. Return to your content and retry the sync. 🔑 Step 2: Check User Permissions in WordPress The WordPress account used for the connection must be allowed to edit and publish content. 1. Log in to your WordPress admin dashboard. 2. Go to Users and open the account connected to Search Atlas. 3. Confirm the role is Administrator or Editor. Author and Contributor roles often cannot update published pages. 4. If the role was recently changed, update it, then reconnect the integration (see Step 1). 🛡️ Step 3: Review Security Plugins and Firewalls Security tools can block automated updates from outside services. 1. Check whether you use plugins such as Wordfence, Sucuri, iThemes Security, or a Cloudflare firewall. 2. Temporarily disable the plugin, or add Search Atlas to its allowlist. 3. Retry the sync. If it succeeds, ask your developer to permanently allowlist Search Atlas so you can re-enable full protection. 🔗 REST API Access Search Atlas updates content through the WordPress REST API. If a plugin or hosting setting disables the REST API, syncs will fail. Confirm the REST API is enabled, or ask your host to enable it. 📄 Step 4: Confirm the Page Still Matches If the page was renamed, moved, or its URL (slug) changed in WordPress after you first connected it, the sync can no longer find it. 1. Open the page in WordPress and copy its current URL. 2. Compare it to the URL shown in Search Atlas. 3. If they differ, reconnect or re-import the page in Search Atlas so it points to the correct destination. 🐢 Step 5: Handle Large or Slow Pages Very large pages, or sites on slower hosting, can time out mid-sync. - Try syncing during off-peak hours. - Split unusually large updates into smaller edits where possible. - Ask your host whether PHP timeout or memory limits can be increased. 💬 Related Sync Messages Not every failed sync returns "unexpected_error." If you see one of the messages below, use the matching guidance. "Article is still being generated. Please wait until generation is complete before publishing" Normally this means the article is not finished generating yet — reopen it and wait until the status shows complete, then sync again. If the message keeps appearing on an article that has already finished generating, this is a known issue our engineering team is actively working on. Contact support with the affected article link so we can publish it for you while the fix is rolled out. Bulk Sync Fails but Individual Sync Works If syncing several articles at once with Bulk Sync to WordPress fails while syncing a single article succeeds, sync the affected articles one at a time as a workaround, and let support know the bulk action failed. 🆘 Still Seeing the Error? If you have completed the steps above and the sync still fails, contact our support team and include the details below so we can investigate quickly: - The URL of the page you are trying to update. - The exact date and time of your most recent failed attempt. - A screenshot of the "unexpected_error" message. - The name of any security plugin or firewall on your site. - The WordPress user role connected to Search Atlas. With this information, our team can pinpoint the cause and get your content syncing again.

🛠️ Fixing Blog Post Upload Errors in the Search Atlas WordPress Plugin

📋 Overview If you see an error when publishing or uploading a blog post through the Search Atlas WordPress plugin, the cause is almost always a connection or authentication issue between Search Atlas and your WordPress site. The most common reason is a missing or incorrect Search Atlas API key or a failed one-click authentication. This guide walks you through fixing the error and restoring the plugin connection. ❓ Why This Error Happens The WordPress plugin connects to your site using a Search Atlas API key or one-click authentication rather than a WordPress username and password. If the API key was never generated, was entered incorrectly, or your hosting environment blocks the connection, uploads will fail. Common error messages reported by users include "Could not publish to WP page" and a rest_forbidden error, both of which usually point to the same underlying connection or permission problem. Common triggers include: - No Search Atlas API key has been generated or one-click authentication has not completed. - A security plugin or firewall is blocking the WordPress REST API. - Your WordPress user role does not have permission to publish posts. 🔑 Step 1: Create a WordPress Application Password Application Passwords are built into WordPress 5.6 and later. To create one: 1. Log in to your WordPress admin dashboard. 2. Go to Users > Profile (or Users > All Users and select your account). 3. Scroll down to the Application Passwords section. 4. Enter a name you will recognize, such as Search Atlas, and click Add New Application Password. 5. Copy the generated password exactly as shown, including the spaces. WordPress only displays it once. Paste this password into the Search Atlas plugin connection settings along with your WordPress username and site URL. 🔍 Step 2: If You Cannot Find the Application Password Option If the Application Passwords section does not appear on your profile page, work through the checks below. 🔒 Confirm your site uses HTTPS WordPress hides the Application Passwords feature on sites that are not served over a secure (HTTPS) connection. Make sure your site loads with https:// and has a valid SSL certificate. Once HTTPS is active, refresh your profile page and the section should appear. 🔄 Check your WordPress version Application Passwords require WordPress 5.6 or higher. Go to Dashboard > Updates to confirm your version and update if needed. 🛡️ Look for a security plugin disabling the feature Security plugins such as Wordfence, iThemes Security, or Solid Security can disable Application Passwords or block the REST API. Temporarily review these settings: - Find any option labeled "Disable Application Passwords" and turn it off. - Make sure the WordPress REST API is not blocked or restricted to logged-in users only. 👤 Confirm your user role You must be logged in as an Administrator (or a user with publishing rights) to see and use Application Passwords. Editor and lower roles may not have access. A rest_forbidden error when publishing is a strong sign that the connected user lacks the required permissions or that the REST API is being blocked. 🔌 Step 3: Reconnect the Plugin After creating a valid Application Password, reconnect your site: 1. Open the Search Atlas WordPress integration settings. 2. Re-enter your WordPress site URL, username, and the new Application Password. 3. Save and run a test connection. 4. Try uploading your blog post again. ⚠️ Still Getting an Error? If uploads still fail after completing the steps above, check the following: - Site URL format: Enter the full URL including https:// and no trailing slash. - Hosting firewall: Some managed hosts block external API requests. Ask your host to allow REST API access for trusted services. - Caching: Clear your WordPress and server cache, then try again. - Permalinks: Go to Settings > Permalinks and click Save once to refresh REST API routes. - Existing posts: When updating or re-syncing a post that already exists in WordPress, make sure the article has an assigned author and a selected website, as these are required before an existing post can publish. - Plugin version: Update the Search Atlas WordPress plugin to the latest version. Recent updates improved WordPress REST API error handling and fixed publish failures that occurred when WordPress returned an empty response. 🙋 Need More Help? If the error continues, contact the Search Atlas support team. Please include the exact error message, your WordPress version, the name of any active security plugins, and a screenshot of your plugin connection settings. This information helps us resolve your issue faster.

⚠️ Content Assistant WordPress Plugin: Incorrect Version Detection on v1.10.x and Higher

The Search Atlas Content Assistant WordPress plugin incorrectly detects versions that contain double-digit segments — such as v1.10.x, v1.12.x, or v2.10.x — which can cause version-gated features to behave unexpectedly. Engineering has identified the root cause and a fix is in review for deployment; no action is needed on your end right now. 🔍 What's Happening with Content Assistant Version Detection The Content Assistant backend evaluates your installed plugin version to decide which features to enable. When a version contains a double-digit segment, the backend's version-parsing logic misreads the number and applies the wrong feature set to your account. You may be affected if you are running: - Content Assistant WordPress plugin v1.10.x or higher - Any plugin version with a double-digit segment (for example v1.12.x or v2.10.x) Common symptoms include: - Version-gated features failing to activate even though your plugin is up to date - An incorrect "update required" prompt appearing in the Content Assistant interface - Content Assistant functionality behaving unexpectedly or inconsistently If you are seeing one or more of these symptoms on a supported plugin version, you are likely impacted by this known issue. 🛠️ Workaround Steps for the Content Assistant Version Detection Issue There is currently no customer-side workaround available for this issue. The version comparison runs on the Search Atlas backend and can only be corrected by a server-side engineering deployment. Reinstalling, downgrading, or reconfiguring the Content Assistant WordPress plugin on your site will not resolve it. You do not need to take any action on your WordPress installation while the fix is being deployed. 📡 Engineering Status for the Content Assistant Fix Our team is aware of this issue and is actively working on a resolution. - Root cause: Identified — the backend version-parsing logic mishandles double-digit version segments. - Current status: A fix is in engineering review. - Next step: Deployment to production once the fix is approved. Once deployed, Content Assistant will detect your plugin version correctly and version-gated features will activate as expected — no further action required on your end. 📞 When to Contact Search Atlas Support Reach out to Search Atlas Support if any of the following apply: - You want your account flagged so the support team can notify you the moment the fix goes live - You are blocked on a specific Content Assistant workflow and need help confirming whether this issue is the cause - You continue to see version detection issues after the fix has been announced as deployed When you contact support, include your Content Assistant WordPress plugin version and a short description of the behavior you are seeing. This helps the team confirm the match to this known issue and monitor your account through resolution. 🌀 Our engineering team has identified the root cause and the fix is under review for deployment. Your support team is monitoring affected accounts and will follow up as soon as the fix is live — thank you for your patience.

🔄 Fix WordPress CMS Sync & PR Distribution Errors

🔍 Overview Some customers have reported two related issues when working with OTTO: a false error stating that no WordPress site was detected during CMS sync, and a PR Distribution job that stalls at 50% progress. This article explains why these issues occur and how to resolve them. ⚠️ What You May Be Experiencing - OTTO's CMS sync fails with a message like "No WordPress site detected" even though your WordPress site is connected. - Your PR Distribution job is stuck at 50% and does not complete. - Your WordPress Connector appears disconnected in the dashboard after a sync attempt that seemed successful. 🛠️ Why This Happens These issues are caused by a known bug in OTTO's CMS sync process. The system incorrectly triggers a WordPress detection check during sync, which can return a false negative — meaning it reports no WordPress site even when one is properly connected. This false error can interrupt the sync task and cause downstream jobs, such as PR Distribution, to stall mid-progress. Our engineering team has identified the root cause and a fix is currently in release. Once deployed, the false detection error will be resolved and sync tasks will complete reliably. ✅ Steps to Try Right Now While the fix is being rolled out, the following steps resolve the issue for most customers: 1. Reconnect your WordPress site. Go to Settings → CMS Connectors (or Settings → Integrations) and disconnect your site, then reconnect it using your credentials. 2. Re-run the CMS sync. After reconnecting, trigger a new CMS sync from the OTTO dashboard. Wait for the sync to complete fully before proceeding. 3. Restart the PR Distribution job. Once the sync completes successfully, cancel the stuck PR Distribution job and create a new one. It should now progress past 50% without issue. 4. Verify your connector status. After the sync, confirm that your WordPress Connector shows as Connected in the Connectors panel. If it still shows as disconnected, repeat step 1. 📋 Additional Things to Check - Make sure your WordPress site is live and accessible — OTTO cannot connect to sites that are in maintenance mode or behind a login wall. - Confirm that the Search Atlas WordPress plugin is installed, activated, and up to date on your site. - Check that your WordPress credentials (username and application password) have not expired or been changed recently. - If you are publishing content, note that articles with a workflow status of Needs Review will not be included in published content lists — only fully approved content is synced. 🚀 What Our Team Is Doing Our engineering team is actively working on this. Here is the current status of related fixes: - False WordPress detection error during CMS sync — fix is in release and will be deployed shortly. - CMS sync failures now surface proper error messages — improved error handling is in progress so you will see clear, actionable feedback if a sync fails in the future. - WordPress Connector disconnecting after sync — this bug has been resolved in a recent update. You do not need to take any action to receive these updates — they will be applied automatically to your account. 💬 Still Need Help? If you have followed the steps above and are still experiencing issues, 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.

🛠️ Fixing Backlinks Sync and Atlas Agent Project Visibility Issues

If your backlinks report is empty, your project is missing from the Atlas Agent dropdown, or premium features appear locked even though you have an active plan, these symptoms are usually connected. They typically point to a project that has not finished syncing, a verification gap, or a plan that has not fully applied to the workspace. This guide walks you through fixing each issue in order. ✅ Before You Start Most of these problems share the same root causes, so work through the checklist below first. Many cases resolve at this stage. - Confirm you are logged into the correct workspace (not a second account with the same email). - Confirm the project domain is entered correctly, including or excluding www exactly as your site resolves. - Confirm your plan shows as Active under Avatar (top-right) → Billing → Plans & Top-ups (Billing). - Clear your browser cache or try an incognito window to rule out stale data. 🔗 Issue 1: Backlinks Report Is Not Populating New backlink data is not instant. After a project is created, the initial crawl and index can take time to surface results, especially for smaller or newer domains. 🔧 Steps to Resolve 1. Open the project and go to the Backlinks report. 2. Check the date the project was created. Initial backlink data can take up to 72 hours to appear for the first time. 3. Verify the domain is entered as a root domain (for example, lfsolutions.us) rather than a full URL with a path. 4. Use the report's refresh or re-sync option if available. 5. If the report is still empty after 72 hours, the project may need a manual re-index from our side. Note the exact domain and move to the escalation steps below. A genuinely empty report can also mean the domain currently has very few or no detectable backlinks. Cross-check the domain in another report to confirm whether data exists at all. 🤖 Issue 2: Project Missing From the Atlas Agent Dropdown Atlas Agent only lists projects that are fully created, verified, and associated with your current workspace. If a project is still processing or sits in a different workspace, it will not appear. (Atlas Agent was previously named Atlas Brain; older links and saved bookmarks to /atlas-brain/ now redirect to /atlas-agent/, so both names refer to the same tool.) 🔧 Steps to Resolve 1. Return to your main project list under OTTO SEO → All Sites (SEO Automation) and confirm the project exists and shows a setup status of Active, not Deep Frozen. 2. Confirm the project lives in the same workspace you are using for Atlas Agent. Switch workspaces from the top menu if you manage more than one. 3. Complete any outstanding setup steps, such as connecting Google Search Console or verifying domain ownership. Unverified projects are often hidden from the dropdown. 4. Refresh the Atlas Agent page after setup is complete so the dropdown reloads. 5. Log out and back in to force the project list to re-sync with your account. Projects created outside Atlas Agent — for example through the main project creation flow rather than from within Atlas Agent itself — are now included in the same unified project list. A past bug that hid these externally created projects has been resolved, so logging out and back in (which triggers a fresh sync) should surface any project that belongs to your account, regardless of where it was created. If you have the opposite problem — a project you already removed elsewhere still appears in Atlas Agent and has no working delete option — this was a separate known issue that has since been fixed, and the delete action now works for these stale entries (including older records that were missing an underlying project ID). If such a leftover project still persists, contact support and we can clear the orphaned record directly. A related, now-resolved issue looked different: the project did appear in Atlas Agent, but the agent replied that it “can't access your project,” reported that backend tools weren't connecting, or suggested using another SEO tool instead of completing the task. This pointed to a backend tool-connection or sub-agent delegation failure rather than a problem with your project setup, and it has since been fixed. If you still encounter it, refresh or start a new Atlas Agent session, and report it to support — it is not something you can resolve by changing your project or workspace settings. 🔒 Issue 3: Features Remain Locked on an Active Plan When a plan upgrade does not unlock features, the entitlement usually has not propagated to your session or to the specific workspace. 🔧 Steps to Resolve 1. Go to Avatar (top-right) → Billing → Plans & Top-ups (Billing) and confirm the plan name and status both reflect your current subscription. 2. Confirm the plan is applied to the workspace you are working in. On multi-workspace accounts, an upgrade applies to one workspace at a time. 3. Fully log out, then log back in. Entitlements refresh on a new session. 4. Try an incognito window to bypass cached permission data. 5. If you upgraded very recently, allow up to 30 minutes for billing changes to sync across all tools. 🧩 Why These Issues Often Appear Together A single underlying cause, most commonly an incomplete project setup or a workspace mismatch, can trigger all three symptoms at once. A project that has not finished verifying may show no backlinks, stay hidden in Atlas Agent, and appear to lack premium access. Completing setup and confirming the correct workspace frequently clears every symptom in one pass. 📞 When to Contact Support If you have completed the steps above and the problem continues beyond the stated wait times, reach out to our team. To speed up resolution, please include: - The exact project domain (for example, lfsolutions.us). - The workspace name and your account email. - Which of the three issues you are seeing, and screenshots if possible. - The date you created the project and the date you upgraded your plan. - The troubleshooting steps you have already tried. With these details, support can verify your project status, trigger a manual re-index, confirm your plan entitlements, and clear any orphaned project records directly.

🔄 Fix WordPress Sync Errors Across Multiple Sites

🧭 Overview If you see a "We're unable to sync with your WordPress site" error when publishing articles from Search Atlas, the cause is usually stale cache data, outdated WordPress plugins, or an OTTO task that needs to be redeployed. This guide walks you through the correct resolution steps in order. 🔌 Step 1: Update Your WordPress Plugins Outdated plugins are a common cause of sync failures, especially after Search Atlas releases platform updates. 1. Log in to your WordPress admin dashboard. 2. Go to Plugins → Installed Plugins. 3. Check for any available updates, particularly the Search Atlas or OTTO plugin. 4. Click Update Now for each plugin that has a pending update. 5. Repeat this step for every WordPress site that is showing the sync error. 🗑️ Step 2: Clear Your WordPress Plugin Cache Cache stored by your WordPress caching plugin can block the sync connection even after plugins are updated. 1. Open your caching plugin (for example, WP Rocket, W3 Total Cache, or LiteSpeed Cache) and clear all cached data using the option available in that plugin. 2. Repeat for every site that is experiencing the error. ⚙️ Step 3: Request an OTTO Redeployment After updating plugins and clearing cache, the OTTO task associated with the affected site or article project needs to be redeployed to re-establish a clean connection with your WordPress site. If you are not sure how to trigger an OTTO redeployment for your specific setup, or if the option is not visible in your account, contact our support team directly so they can initiate the redeployment on your behalf. When reaching out, please have the following ready: - The name of the affected WordPress site or project in Search Atlas - The exact error message you are seeing - The approximate date and time the error first occurred - Whether the error is affecting one site or multiple sites ✅ Confirming the Fix After completing all three steps, attempt to publish or sync the affected article again. If the error no longer appears, the issue has been resolved. If you are managing multiple WordPress sites, confirm the fix on each site individually. 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.

🔍 OTTO Pixel Not Detected via Google Tag Manager

Installing the OTTO pixel through Google Tag Manager (GTM) is a common approach, but on proprietary or custom-built CMS platforms it can fail silently — leaving the pixel showing Not Installed even when setup appears complete. This article covers every known cause and guides you through each fix. 🧐 Why GTM Installations Fail on Proprietary CMS Platforms Several factors specific to proprietary CMS environments can prevent the OTTO pixel from being detected: - Unpublished GTM container: Adding a tag in GTM does not make it live until you click Publish. A saved draft never fires on your live site. - Incorrect trigger configuration: If the tag is set to fire only on certain pages or events, it may not load on the pages Search Atlas checks during detection. - Missing GTM code snippets: GTM requires two snippets — one inside the head section and one immediately after the opening body tag. Some proprietary CMS platforms allow only one script injection point, which breaks GTM functionality entirely. - Content Security Policy (CSP) restrictions: Many proprietary CMS platforms enforce strict CSP headers that block third-party scripts, including the OTTO pixel delivered through GTM. - Aggressive page caching: Cached HTML pages may not reflect GTM updates until the cache is fully cleared. - Script stripping or sanitization: Some proprietary CMS platforms automatically remove or modify script tags injected through GTM, preventing the pixel from executing. 🛠️ Troubleshooting Steps Work through the following checks in order until the pixel is detected: 1. Publish your GTM container. Log in to GTM, open your container, and confirm the latest version is Published — not just saved as a draft. Unpublished changes never reach your live site. 2. Check the tag trigger. In GTM, open the OTTO pixel tag and review its trigger settings. Set the trigger to All Pages so the tag fires on every page visit. Custom triggers with narrow URL conditions can cause the tag to miss the pages Search Atlas scans for detection. 3. Verify both GTM snippets are in place. Your CMS template must include the GTM script snippet inside the head section and the GTM noscript snippet immediately after the opening body tag. Open your CMS template or theme editor and confirm both snippets are present and unmodified. 4. Test with GTM Preview Mode. In GTM, click Preview, enter your site URL, and use Tag Assistant to confirm the OTTO pixel tag fires on the expected pages. If it shows as Not Fired, revisit your trigger configuration. 5. Check for CSP errors. Open your browser's developer tools (press F12, then go to the Console or Network tab) and reload your site. Look for messages containing Content Security Policy or script-src. If CSP errors appear, your server is blocking the GTM or Search Atlas script domains. Ask your developer to add those domains to your CSP allowlist. 6. Clear your CMS and CDN cache. After any GTM or template change, clear your CMS's built-in cache and, if applicable, flush your CDN cache as well. This ensures all visitors receive the updated page with the pixel firing correctly. 🔄 Alternative: Install the Pixel Directly in Your CMS If GTM continues to be blocked or restricted by your CMS, bypass GTM entirely and install the OTTO pixel script directly into your site's HTML template. This is the most reliable method for proprietary CMS platforms and removes all GTM-related variables. 1. Go to Left sidebar → OTTO SEO → Installation Guide in Search Atlas. 2. Copy the OTTO pixel code snippet displayed on that page. 3. Paste the snippet inside the head section of your CMS's global page template or theme file. Look for a setting labeled Header Scripts, Custom Code, or Theme Editor in your CMS admin panel — the exact location varies by platform. 4. Save and publish the template change, then clear your CMS cache. ✅ Confirm the Pixel Is Detected in Search Atlas After completing any of the steps above, verify that Search Atlas has picked up the pixel: 1. Go to Left sidebar → OTTO SEO → All Sites. 2. Locate your project card and check the pixel status indicator. 3. If the status still shows Not Installed, wait up to 10 minutes and refresh the page — pixel detection runs on a short delay after the script first loads on your site. 4. For a full installation status overview, go to Left sidebar → OTTO SEO → Installation Guide, which displays real-time detection results for all your connected sites. 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.

🔒 Fix Gmail 'App is Blocked' Error in Campaigns

🧭 Overview When connecting a Gmail account to Search Atlas Authority Campaigns, you may see an 'App is Blocked' error or an SMTP/IMAP authentication failure. This happens because Google blocks direct password sign-ins for third-party apps by default. The fix is to generate a Gmail App Password and use it in place of your regular Google account password. This article walks you through generating an App Password and entering it correctly inside Search Atlas so your campaigns can send and receive emails without interruption. ⚠️ Why This Error Occurs Google's security policy prevents third-party applications from authenticating with your standard Gmail password. When Search Atlas attempts to connect via SMTP or IMAP using a regular password, Google blocks the request and returns an 'App is Blocked' or 'Username and password not accepted' error. An App Password is a unique 16-character code that Google generates specifically for a single app, bypassing this restriction securely. Before you begin, confirm the following requirements are met on your Google account: - 2-Step Verification is enabled on your Google account — App Passwords are only available when 2-Step Verification is active. - You are signed in to the Google account you want to connect to Search Atlas. - The Google account is not a Google Workspace account with App Passwords disabled by an administrator. If it is, contact your Workspace admin to enable App Passwords for your account. 🔑 Step 1 — Enable 2-Step Verification on Google Skip this step if 2-Step Verification is already active on your account. 1. Go to myaccount.google.com and sign in. 2. Click Security in the left navigation panel. 3. Under How you sign in to Google, click 2-Step Verification. 4. Follow the on-screen prompts to complete setup. 🛠️ Step 2 — Generate a Gmail App Password 1. Go to myaccount.google.com/apppasswords while signed in to your Gmail account. If prompted, re-enter your Google password. 2. In the App name field, type a recognisable label such as Search Atlas Campaigns. 3. Click Create. 4. Google will display a 16-character App Password in a yellow box. Copy this code immediately — Google will not show it again. Store it somewhere safe until you have finished the next step. 📧 Step 3 — Connect Gmail to Search Atlas Authority Campaigns 1. In Search Atlas, navigate to Left sidebar → Authority → Campaigns. 2. Open your campaign settings or click Add Email Account (the exact label may vary depending on your campaign setup). 3. When prompted for your email connection details, enter the following SMTP settings: - SMTP Host: smtp.gmail.com - SMTP Port: 465 (SSL) or 587 (TLS) - Username: your full Gmail address (e.g. yourname@gmail.com) - Password: the 16-character App Password you generated in Step 2 — not your regular Gmail password 4. For IMAP (incoming mail), use these settings: - IMAP Host: imap.gmail.com - IMAP Port: 993 (SSL) - Username: your full Gmail address - Password: the same 16-character App Password 5. Save your settings and test the connection. A successful connection will show a green confirmation status. ✅ Verifying the Connection After saving, send a test email from within the Campaigns interface. Navigate to Left sidebar → Authority → Sent to confirm the email appears in your sent log. Check Left sidebar → Authority → Inbox to verify incoming mail is being received correctly. 🔍 Common Issues and Fixes - App Password option not visible: 2-Step Verification is not yet enabled. Complete Step 1 above and then return to the App Passwords page. - Still seeing 'App is Blocked' after entering the App Password: Confirm you copied the full 16 characters and removed any spaces. Re-generate a new App Password and try again. - Google Workspace account errors: Your Workspace administrator may have restricted App Passwords. Ask your admin to enable App Passwords at the domain level in the Google Admin Console. - Connection times out: Confirm the correct SMTP/IMAP ports are entered. Some networks block port 465; switch to port 587 with TLS. 💬 Need More Help? 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.

⚠️ "Clear All Settings" Does Not Reset Media Optimization or Code Minification Settings

A known issue in the Search Atlas WordPress plugin causes Media Optimization and Code Minification settings to remain active after you run "Clear All Settings." Use the steps below to complete the reset manually while a fix is queued for the next plugin update. 🔍 What's Happening When you click Clear All Settings in Advanced Settings → Reset Plugin Settings, the following settings are not cleared and remain in their previous state: - Image Conversion (Media Optimization) - Lazy Loading (Media Optimization) - Dimension Injection (Media Optimization) - All Code Minification settings (Note: the plugin settings do not contain a Code Minification section — available sections are Settings, LLMs.txt, SEO Controls, OTTO cache, Branding, Schema Markup, Search engine verification, Code snippets, and Local SEO.) Both metasync_code_minification and metasync_media_optimization option keys are fully uncleared — not partially — so every sub-setting under each section, not just the master toggle, retains its previous state. Media optimization cache and batch data also remain, leaving the plugin in an inconsistent partial-reset state. Affected versions: all current plugin versions prior to the upcoming fix release. Once the fix is released, the version number will be noted here. 🛠️ Workaround Steps After running Clear All Settings, follow these steps to achieve a complete reset: 1. Click Clear All Settings in Advanced Settings → Reset Plugin Settings to reset all other plugin settings. 2. Navigate to the Media Optimization section in the plugin settings. 3. Disable the Image Conversion, Lazy Loading, and Dimension Injection master toggles. 4. Click Save in the Media Optimization section before navigating away. 5. Navigate to the Code Minification section. 6. Disable or reset every setting in that section. Confirm each toggle and option — including Minify CSS, Minify JS, Minify HTML, and any related sub-toggles — is in its default-off state. 7. Click Save in the Code Minification section. 8. Clear the Media Optimization cache and any pending batch data using the Clear Cache or Reset Batch controls in the Media Optimization section. If no such control is visible in your plugin version, contact Search Atlas Support to clear the cache and batch data on the backend. After saving, your plugin is in the same fully reset state that Clear All Settings is intended to produce. 📡 Engineering Status Our team is aware of this issue and a fix is actively in development. The correction is complete and awaiting release in the next plugin update. This article will be retired once the fix is confirmed live. The tracked fix (WP-357) addresses the uncleared metasync_media_optimization and metasync_code_minification option keys. Cleanup of leftover media optimization cache and batch data is tracked separately — continue to use the cache/batch step in the workaround above until that follow-up is confirmed shipped. 📞 When to Contact Support Contact Search Atlas Support if: - The workaround steps do not fully clear your settings. - You experience unexpected behavior after completing the manual reset. - You need help confirming your plugin is in a clean state before proceeding. 🌀 Our team is actively working on a fix shipping in the next plugin release — the workaround above fully resolves the issue in the meantime, and Search Atlas Support is available anytime if you need hands-on help.

🔌 Fixing MCP Tool Count Differences in Claude Code

🧭 Overview When you connect the Search Atlas MCP (Model Context Protocol) server to Claude Code, you may notice that the number of available tools is lower than the full published count. For example, you might see 475 tools instead of 607, and a specific tool or skill such as /onboard-client may appear to be missing. This is almost always expected behavior caused by client-side limits and configuration, not a fault with your account. This article explains why the difference happens and how to restore access to the tools you need. 🔎 Why the Tool Count Looks Lower The Search Atlas MCP server exposes a large catalog of tools and skills. The number that actually appears in Claude Code can be smaller for several common reasons: - Client tool limits: Claude Code caps how many MCP tools it loads at once to protect performance. When the catalog exceeds that cap, some tools are not registered. - Multiple connected servers: If you have other MCP servers connected, they share the same tool budget, leaving fewer slots for Search Atlas tools. - Permission scope: Your plan, role, or workspace permissions may hide tools you are not entitled to use. - Version mismatch: An outdated Claude Code build or MCP server version may not expose newly added tools. - Filtering or allowlists: Project or user settings can explicitly enable or disable specific tools, which changes the visible count. 💡 Why a Specific Tool Is Missing A tool like /onboard-client disappearing usually points to one of these causes: - It falls outside the loaded tool limit and was dropped when the catalog was truncated. - It is gated behind a permission or feature your current workspace does not have enabled. - It was renamed or grouped under a different skill in a newer release, so an older client no longer recognizes it. 🛠️ How to Restore Missing Tools Work through these steps in order. Most customers regain full access after the first two. 1. Update everything: Make sure Claude Code and the Search Atlas MCP connection are on their latest versions. Restart Claude Code after updating so the tool list reloads. 2. Reduce connected servers: Temporarily disconnect other MCP servers you are not using. This frees space in the tool budget so more Search Atlas tools can load. 3. Raise the tool limit: In your Claude Code configuration, increase the maximum number of MCP tools allowed if your setup permits it, then reconnect. 4. Reconnect the MCP server: Remove and re-add the Search Atlas MCP connection to force a fresh sync of the full catalog. 5. Check your permissions: Confirm your Search Atlas plan and workspace role include the tools you expect. Some tools are only available on specific tiers. 6. Search directly: If a tool is not shown in the list but you know its name, try calling it directly (for example, /onboard-client). Some clients keep tools available even when they are not displayed in the visible count. ✅ Confirming the Fix After making changes, reload Claude Code and review the tool count again. It is normal for the number to still be slightly lower than the full published total because of client limits. What matters is that the specific tools you need — including /onboard-client — are now reachable. Test the tool you were missing to confirm it works end to end. 📌 Good to Know - A tool count that is lower than the maximum is not a bug on its own; it reflects client-side limits. - Keeping only the MCP servers you actively use gives Search Atlas tools the best chance to load fully. - Tool availability can change between releases, so staying updated is the most reliable way to keep the full catalog.

🔄 WordPress Blog Sync Failure Troubleshooting Guide

🔍 What This Error Means When you see the message "We're unable to sync with your WordPress site. Check your configuration or reach out to support", it does not always mean your WordPress setup is misconfigured. In many cases, the issue is caused by a temporary platform-side problem — not something you have done wrong. Past incidents have been traced to an invalid or expired API key on the Search Atlas side, which blocks the publish-to-WordPress process entirely. Our engineering team has resolved multiple occurrences of this and continues to monitor for recurrences. ✅ Step 1: Confirm Your WordPress Connection Is Healthy Before assuming a platform issue, verify that your WordPress environment is set up correctly: - Log in to your WordPress admin dashboard and confirm the MetaSync plugin is installed and active. The current supported version is v2.6.10 or later. - Check that your WordPress REST API is accessible and not blocked by a security plugin or firewall rule. A rest_forbidden error in your browser console or server logs indicates a permissions or plugin conflict on the WordPress side. - Confirm that the user account connected to Search Atlas has sufficient permissions to publish posts via the REST API. 🔄 Step 2: Try a Hard Refresh If your connection looks healthy, perform a hard refresh of the Search Atlas platform in your browser (typically Ctrl + Shift + R on Windows or Cmd + Shift + R on Mac) and attempt the sync again. This rules out a stale browser session as the cause. 📝 Step 3: Retry Publishing From Content Genius Navigate to Left sidebar → Content → Content Genius and attempt to publish or sync your article again. If the error persists after a hard refresh and the MetaSync plugin is confirmed active, the issue is likely on the platform side rather than your configuration. ⚙️ Step 4: Understand Platform-Side Causes Several known platform-side issues can trigger this error message: - Invalid or expired API key — An internal API key used by Search Atlas to communicate with WordPress becomes invalid, blocking all publish requests with a 400 error. This has been the root cause in multiple incidents and is resolved by our engineering team without any action required from you. - Empty response from WordPress — In some cases, WordPress returns an empty response body, causing a processing error on the Search Atlas side. This is also handled internally. - Temporary service disruption — Occasionally, a broader platform issue affects multiple users simultaneously. Our team monitors for these and deploys fixes as quickly as possible. None of these causes require changes to your WordPress site or MetaSync plugin when your configuration is confirmed healthy. 🛠️ Step 5: What To Do If the Error Persists If you have confirmed that your MetaSync plugin is active and your WordPress permissions are correct, and the sync still fails after retrying: 1. Note the exact error message displayed on screen. 2. Record the date and time you experienced the failure. 3. Check whether other team members on your account are experiencing the same issue — this helps confirm whether it is account-specific or platform-wide. 4. Contact our support team using the instructions below so we can investigate your account directly and file an internal ticket if needed. 💡 Key Things To Remember - A sync failure error does not always mean your WordPress or plugin configuration is broken. - Hard-refreshing the platform does not resolve platform-side API key issues — only our engineering team can do that. - The MetaSync plugin must be version v2.6.10 or later for compatibility. - REST API access must be enabled and not blocked by WordPress security settings. 💬 Still Seeing the Error? 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.

🔌 Fix WordPress MetaSync API Key Authentication Timeout

🔍 Overview When connecting the Search Atlas MetaSync plugin to your WordPress site, you may encounter an authentication timeout — typically after 60 seconds — regardless of whether you use the One-Click connection or manual API key entry method. In some cases, you may also see a 500 error or the message "The API key could not be verified." This article walks you through the most effective troubleshooting steps to restore the connection. ⚠️ What Causes This Issue? Authentication timeouts and API key errors during MetaSync setup are usually caused by one or more of the following: - A corrupted or invalidated API key stored in your WordPress database - A server-side timeout on your WordPress host that cuts the connection before authentication completes - A plugin conflict or caching layer interfering with the authentication request - An outdated version of the MetaSync plugin that does not send authentication headers correctly - A firewall or security plugin blocking outbound requests from your WordPress site to Search Atlas servers 🛠️ Step-by-Step Troubleshooting Work through the steps below in order. Most customers resolve the issue by completing steps 1 through 4. 1. Update the MetaSync plugin to the latest version. In your WordPress dashboard, go to Plugins → Installed Plugins, find Search Atlas MetaSync, and click Update if an update is available. Older plugin versions may not send the correct authentication headers required by the Search Atlas API. 2. Regenerate your API key in Search Atlas. Log in to your Search Atlas dashboard, navigate to Settings → API Keys, and generate a new API key. Do not reuse the old key — copy the new one immediately and keep it ready for the next step. 3. Disconnect and reconnect the plugin manually. In your WordPress admin panel, go to the MetaSync plugin settings and disconnect any existing connection. Select the manual entry method and paste your newly generated API key. Save the settings and wait up to 90 seconds for the handshake to complete. 4. Clear all caches before retrying. Clear your WordPress object cache, page cache, and any CDN cache (e.g., Cloudflare, WP Rocket, W3 Total Cache). A stale cache can cause the authentication request to fail silently. 5. Temporarily disable security and firewall plugins. Plugins such as Wordfence, iThemes Security, or All In One WP Security may block outbound API requests. Disable them one at a time, then retry the connection after each deactivation to identify the culprit. Re-enable them once the connection is established. 6. Check your hosting provider's outbound request limits. Some managed WordPress hosts (e.g., WP Engine, Kinsta, Flywheel) restrict or throttle outbound HTTP requests. Contact your host and ask them to whitelist outbound connections to api.searchatlas.com. Also ask them to confirm that your PHP execution timeout is set to at least 120 seconds. 7. Switch to the One-Click connection method if manual entry failed, or vice versa. If manual entry timed out, try the One-Click SSO flow from your Search Atlas dashboard under Avatar Menu (👤) → Settings → CMS Connectors. If One-Click failed first, switch to manual entry with your regenerated key. ✅ How to Confirm the Connection Is Working After completing the steps above, verify that MetaSync is connected successfully: - In your WordPress admin panel, the MetaSync plugin status should show Connected with your Search Atlas account name displayed. - In your Search Atlas dashboard under Avatar Menu (👤) → Settings → CMS Connectors, your WordPress site should appear as an active, linked property. - Run a test sync from the MetaSync plugin settings page and confirm that data flows to your Search Atlas account without errors. 🚫 Common Mistakes to Avoid - Do not reuse a previously generated API key after a failed authentication attempt. Once an error occurs, always regenerate a fresh key. - Do not attempt multiple connection methods simultaneously. Complete one method fully — including clearing caches — before trying the other. - Do not skip the cache-clearing step. This is one of the most overlooked causes of repeated authentication failures. 💬 Still Need Help? If you have followed all the steps above and the MetaSync plugin still cannot authenticate, our team can investigate your specific account and server configuration. 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. When you reach out, please have the following ready to speed up the investigation: - Your WordPress site URL - The exact error message displayed (screenshot if possible) - Your WordPress version and MetaSync plugin version - Your hosting provider name - A list of active security or caching plugins Additional Notes API key type mismatch: The MetaSync plugin currently requires a v1 API key. Using a v2 API key may cause verification to fail. Log in to Search Atlas, go to Settings > API Keys, and generate or copy a v1 key instead.

🛠️ Fix WordPress Connector Errors in Atlas Coworker

🔍 Overview If your WordPress site appears as Active in Atlas Coworker but returns an error such as "The operation wordpress-get-current-user is not available for wordpress" when you attempt to run operations, your connector is in a broken state. This is a known issue affecting WordPress and custom-MCP connectors in Coworker, and it does not automatically resolve on its own. This article explains what causes the error, which sites are affected, and the steps you can take right now to restore functionality. ⚠️ What This Error Means An Active status only confirms that a connection record exists — it does not guarantee the connector is fully functional. The error message indicates that the gateway routing between Coworker and your WordPress site is broken, meaning Coworker cannot execute any WordPress operations through that connector, even though the connection appears healthy on screen. Common symptoms include: - Connection status shows Active but all WordPress operations fail immediately. - Error messages reference operations such as wordpress-get-current-user, wordpress-get-posts, or similar WordPress actions being unavailable. - Bulk publish or content operations do nothing or return instant errors. 🌐 Does This Affect All My WordPress Sites? Not necessarily. Each WordPress connector is independent, so the issue is tied to the specific site where the error appears. However, if you connected multiple WordPress sites around the same time using the same workflow, it is worth checking each one individually, as the underlying routing problem can affect any connector created through the broken setup flow. To check your other sites, navigate to Coworker in the left sidebar and review each WordPress connection. Attempt a test operation on each one to confirm whether it succeeds or returns a similar error. 🛠️ Steps to Resolve the Error 1. Go to Coworker. In the left sidebar, click Coworker. 2. Locate the affected connection. Find the WordPress site that is returning the error (for example, longislandcustomblinds.com). 3. Remove the broken connector. Disconnect or delete the existing WordPress connection for that site. Do not simply reconnect on top of the existing record — the old broken record must be removed first. 4. Reconnect your WordPress site. Use the connector setup flow to add the site again from scratch. Follow all prompts through to completion. Ensure you reach the final confirmation step — an incomplete setup is one of the most common causes of this error. 5. Test the connection immediately after reconnecting. Run a simple operation, such as fetching the current user or retrieving a post, to confirm the connector is working before relying on it for bulk tasks. 💡 Tips to Prevent This Issue - Complete the full setup flow. Do not close the connector window or navigate away before the setup confirms completion. Partial connections can appear Active while being non-functional. - Use the direct connector setup link. If the AI Agent or an in-platform prompt gives you a WordPress connection link that leads to an unexpected page, do not use it — navigate to Coworker manually via the left sidebar instead. - Avoid white-label domain URLs during setup. If your workspace is accessed via a white-label domain, connector setup redirects may fail. Use the primary Search Atlas platform URL when connecting WordPress sites. - Check each site individually. If you manage multiple WordPress sites in one workspace, test each connector separately after any reconnection to confirm all are working. 🔄 Current Status The Search Atlas engineering team has identified the root causes behind broken WordPress connectors in Coworker and fixes are actively in development. These include improvements to the connector setup flow, resolution of gateway routing errors, and cleanup of incomplete connection records. You do not need to wait for the fix to be deployed — following the reconnection steps above will restore functionality for your site now. 🙋 Still Need Help? If you have followed the steps above and your WordPress connector is still returning errors, or if you are unsure whether additional sites in your workspace are affected, our team can investigate your specific connection records directly. 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.

🔧 Fixing the GoHighLevel CMS Connector When It Won't Sync Your Latest Article Version

📋 Overview If you've updated an article in Search Atlas but your GoHighLevel CMS Connector keeps publishing an older version, even after repeated manual syncs, this guide will help you fix it. In most cases, the problem comes from cached content, an unsaved draft, or a connection that needs to be refreshed. The steps below walk you through the most common causes and how to resolve them. 🤔 Why This Happens The CMS Connector syncs the version of your article that it last recognized as "final." When the latest version isn't pulling through, it's usually because of one of these reasons: - The newest changes were not saved or published inside Search Atlas before syncing. - Cached content on the GoHighLevel side is still serving the previous version. - The connector's authorization token has expired or the connection has drifted. - The article is mapped to the wrong page or post in GoHighLevel. - The sync completed, but the GoHighLevel page cache hasn't refreshed yet. ✅ Before You Start Confirm the following so your sync has the correct content to pull: - You are editing the same article that is mapped to the connector. - Your most recent edits are saved and published in Search Atlas, not left in draft. - You have admin access to both your Search Atlas account and your GoHighLevel sub-account. 🛠️ Step-by-Step Fix 1️⃣ Step 1: Confirm the latest version is published in Search Atlas 1. Open the article in Search Atlas. 2. Check the version history or last-edited timestamp to confirm your changes are present. 3. Click Save and then Publish. A draft that is saved but not published will not sync. 2️⃣ Step 2: Verify the connector mapping 1. Go to Avatar → Settings → CMS Connectors and open your GoHighLevel CMS Connector. 2. Confirm the article is mapped to the correct GoHighLevel page or blog post. 3. If the mapping points to a different or duplicate page, update it to the correct destination. 3️⃣ Step 3: Run a fresh manual sync 1. From the connector screen, select the article. 2. Click Sync and wait for the status to change to Completed. 3. Do not start a new sync until the current one finishes, as overlapping syncs can re-queue the older version. 4️⃣ Step 4: Clear the GoHighLevel cache Even after a successful sync, GoHighLevel may continue serving a cached page. 1. Open the page in GoHighLevel and republish it. 2. View the live page in a private or incognito browser window to bypass your local cache. 3. If you use a CDN or third-party cache, clear it as well. 5️⃣ Step 5: Reconnect the integration If the latest version still isn't appearing, the connection may need to be refreshed. 1. In Avatar → Settings → CMS Connectors, disconnect the GoHighLevel CMS Connector. 2. Reconnect and re-authorize access to your GoHighLevel sub-account. 3. Re-map the article and run the sync again. 🚨 Still Seeing the Old Version? If you've completed all the steps and the connector is still pulling an outdated article, contact our support team and include the details below to speed up resolution: - The article name and its URL in Search Atlas. - The GoHighLevel page or post URL where the old version appears. - The date and time of your most recent edit and your most recent sync attempt. - A screenshot of the connector's sync status. 💡 Quick Tips to Prevent Sync Issues - Always publish your changes in Search Atlas before syncing. - Wait for each sync to finish before starting another. - Refresh the live page in a private browser window to confirm the update. - Re-authorize the connector periodically if you change GoHighLevel passwords or permissions.

🔧 Fix WordPress Blog Sync Failures in Search Atlas

🔍 Overview If your WordPress blog sync was working previously but has recently stopped, the most common cause is an outdated MetaSync plugin installed on your WordPress site. Search Atlas now blocks older plugin versions to ensure secure and reliable syncing. This article walks you through diagnosing and fixing the issue. ⚠️ Common Symptoms - Sync fails despite a previously successful connection - You see a "plugin needs an update" error or warning inside Search Atlas - Blog posts are not appearing or updating in the Content Assistant - Images are broken after a recent WordPress plugin update - REST API route errors are displayed during sync ✅ Step 1 — Update the MetaSync Plugin The most important step is making sure you have the latest version of the MetaSync plugin installed on your WordPress site. 1. Log in to your WordPress admin dashboard (e.g., yoursite.com/wp-admin). 2. Navigate to Plugins → Installed Plugins. 3. Locate the MetaSync by Search Atlas plugin. 4. If an update is available, click Update Now. 5. Wait for the update to complete, then return to Search Atlas. Note: If you clicked an update link inside Search Atlas and were taken to the wrong page previously, this has been fixed — the link now routes you directly to your WordPress login page. 🔁 Step 2 — Re-Attempt the Sync Once the plugin is updated, retry the sync from within Search Atlas. 1. Open the Content Assistant in Search Atlas. 2. Navigate to the blog or content piece you want to sync. 3. Click the Sync to WordPress button. 4. Confirm the sync completes without errors. If the sync succeeds, no further action is needed. If it fails again, continue to the steps below. 🛠️ Step 3 — Check Your WordPress REST API Search Atlas uses the WordPress REST API to communicate with your site. If the REST API is blocked or misconfigured, syncing will fail even with an updated plugin. - Visit yoursite.com/wp-json/ in a browser. You should see a JSON response. If you see an error or a blank page, your REST API may be disabled. - Check if a security plugin (e.g., Wordfence, iThemes Security) is blocking REST API access for unauthenticated requests. - Temporarily disable any caching plugins and retry the sync. - Ensure your WordPress permalink settings are not set to Plain — go to Settings → Permalinks and choose any option other than Plain, then click Save. 📁 Step 4 — Verify Subpath or Subdirectory Deployments If your WordPress site is installed in a subdirectory (e.g., yoursite.com/blog/), you need to confirm the base path is correctly configured in Search Atlas. - In Search Atlas, go to your WordPress integration settings. - Confirm the site URL includes the full subpath (e.g., https://yoursite.com/blog). - Save your settings and retry the sync. Search Atlas now supports base path and slug configurations for subpath deployments, so ensure your URL reflects the exact installation location of WordPress. 🖼️ Step 5 — Fix Broken Images After a Plugin Update If images in your synced content appear broken after updating the MetaSync plugin, follow these steps: 1. Open the affected blog post in the Content Assistant. 2. Re-sync the post to WordPress using the Sync to WordPress button. 3. Check the post on your WordPress site to confirm images are loading correctly. 4. If images remain broken, try re-uploading them manually through the WordPress Media Library and updating the post. ❌ A Note on Backlink Data Accuracy If you have noticed backlink data appearing incorrect or invalid for a domain in Search Atlas (such as referring domains showing unexpected links), please be aware that backlink databases are updated on a regular crawl cycle. Data shown at any given moment reflects the most recent crawl. If you believe specific backlink data is inaccurate, document the affected domain and the links in question, then contact our support team for investigation. 💬 Still Need Help? If you have followed all the steps above and your WordPress sync is still failing, our team is ready to assist. 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.

🛠️ Fix OTTO Not Detecting Your Cloudflare Site

🔍 Overview After moving your site to Cloudflare and connecting your Cloudflare token in OTTO, you may see errors such as "OTTO cannot be found" or "invalid name server." This usually happens because DNS changes take time to propagate, or because OTTO's scan runs before Cloudflare fully recognises your domain. This article walks you through the steps to resolve these issues and get OTTO detecting your site correctly. ⚠️ Why This Happens - DNS propagation delay: After changing nameservers, it can take up to 48 hours for changes to fully propagate across the internet. OTTO may scan your site before this process completes. - Cloudflare Worker not yet active: If the OTTO Worker deployment is triggered before Cloudflare finishes processing your domain, the pixel or UUID will not be detected. - Cloudflare proxy status: If the DNS record for your domain is set to DNS-only (grey cloud) instead of Proxied (orange cloud), Cloudflare cannot serve the OTTO Worker. - Token permission mismatch: The Cloudflare API token connected to OTTO may not have the correct permissions to deploy or read Workers on your zone. ✅ Step-by-Step Fix 1. Confirm nameserver propagation is complete. Visit a free DNS checker tool (such as whatsmydns.net) and verify that your domain's nameservers point to Cloudflare globally. Do not proceed until propagation shows as complete in most regions. 2. Check your Cloudflare domain status. Log in to your Cloudflare dashboard. Under your domain overview, the status should read Active. If it still shows Pending, wait and check again in a few hours. 3. Verify your DNS record proxy status. In Cloudflare, go to DNS → Records and confirm that your root domain (@) and www records have the orange cloud (Proxied) enabled. DNS-only records will prevent OTTO Workers from running. 4. Check your Cloudflare API token permissions. In Cloudflare, go to My Profile → API Tokens and confirm the token connected to OTTO has at minimum: Zone → DNS (Edit), Zone → Zone (Read), Account → Workers Scripts (Edit), Zone → Workers Routes (Edit), and Account → Workers KV Storage (Edit) permissions for the correct zone. Edit the token if any permissions are missing. 5. Reconnect the Cloudflare token in OTTO. In Search Atlas, navigate to OTTO SEO in the left sidebar. Open your OTTO session, go to the Cloudflare connection settings, disconnect the existing token, and reconnect it using the updated or verified token from Cloudflare. 6. Re-trigger the OTTO installation scan. After reconnecting the token, initiate a fresh scan or re-deploy the OTTO Worker from within your OTTO SEO session. Allow a few minutes for the Worker to deploy and for OTTO to verify detection. 7. Clear Cloudflare cache. In your Cloudflare dashboard, go to Caching → Configuration and click Purge Everything. This ensures Cloudflare serves the latest version of your site with the OTTO Worker active. 8. Run the detection check again. Return to your OTTO session in OTTO SEO and confirm the installation status now shows as detected. If the status is still not detected, wait 30 minutes and retry the scan once more. 💡 Tips to Prevent This Issue - Always wait for full DNS propagation before connecting your Cloudflare token to OTTO or triggering any Worker deployment. - When creating your Cloudflare API token, use the Edit Cloudflare Workers template as a starting point to ensure all required permissions are included. - Keep your Cloudflare domain status Active and proxy status set to Proxied at all times while using OTTO via Cloudflare. - Avoid switching nameservers or making major DNS changes while an OTTO deployment is already in progress. 🆘 Still Seeing the Error? If you have followed all the steps above and OTTO still cannot detect your Cloudflare site, our team can investigate the specific Worker deployment and zone configuration on your account. 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.

⚠️ Open Graph and Social Meta Checkboxes Not Saving in WordPress Plugin — Fixed

Open Graph and social meta toggle checkboxes in the Search Atlas WordPress plugin were reverting to enabled after every save. This bug has been fixed — updating to the latest plugin version resolves the issue immediately. 🔍 What's Happening The following nine checkboxes under the plugin's Open Graph and social settings could not be turned off: - Open Graph meta tags - Facebook meta tags - Twitter meta tags - OG image dimensions - Article timestamps - Article author - Article section - Article tags - Twitter image alt After unchecking any of these options and saving, the page reloaded with all checkboxes re-enabled. The settings were never stored, making it impossible to disable these features through the WordPress admin. 🛠️ How to Apply the Fix Update the Search Atlas WordPress plugin to the latest version. The fix ships in this release — no additional configuration is needed after updating. 1. Log in to your WordPress dashboard. 2. Go to Plugins → Installed Plugins or Dashboard → Updates. 3. Locate the Search Atlas plugin and click Update Now. 4. Once the update completes, navigate back to your OG and social settings. 5. Uncheck the desired options and click Save. The unchecked state will now persist correctly. 📡 Engineering Status The root cause of this bug has been identified and resolved. The fix is included in the latest release of the Search Atlas WordPress plugin and is available to all users now. No further action is required beyond updating the plugin. 📞 When to Contact Support If you update to the latest plugin version and checkboxes still revert after saving, contact our support team with the following details: - Your current WordPress version - The Search Atlas plugin version installed after updating - A brief description of the steps you followed Our team will follow up promptly to get your settings working correctly. 🌀 Updating the Search Atlas WordPress plugin resolves this issue completely — and if your Open Graph or social meta settings still aren't saving after the update, our support team is ready to help.

🔌 Fix 'No EO Pixel Found' Error in WordPress

🧭 Overview The No EO Pixel Found error means Search Atlas cannot detect the EO Pixel on your WordPress site after the plugin has been installed. In most cases, completing the standard setup resolves this. However, if you have already installed the plugin, updated PHP, and followed all setup steps, a secondary layer of issues — such as plugin conflicts, caching, or initialization timing — may be preventing detection. This article walks you through every advanced troubleshooting path. ✅ Confirm the Basics First Before moving to advanced steps, verify the following are already in place: - The Search Atlas WordPress plugin is installed and activated (not just installed). - Your site is running PHP 7.4 or higher. - You are connected to the correct WordPress site in your Search Atlas dashboard under Avatar Menu (👤) → Settings → CMS Connectors. - The plugin was authorized using the correct Search Atlas account credentials. If any of these are incomplete, resolve them first. If all are confirmed and the error persists, continue below. 🗂️ Step 1: Clear All Caches Caching is the most common reason the EO Pixel is not detected even after a successful install. The pixel may be present in your live code but invisible to the scanner because an old cached version of your page is being served. 1. Log in to your WordPress admin dashboard. 2. If you use a caching plugin (e.g., WP Rocket, W3 Total Cache, LiteSpeed Cache, WP Super Cache), open its settings and select Clear All Cache or Purge Everything. 3. If your hosting provider offers server-level caching (common with SiteGround, WP Engine, Cloudways, Kinsta), log in to your hosting control panel and clear the server cache from there as well. 4. If you use a CDN such as Cloudflare, log in and purge the cache for your entire domain. 5. Return to Search Atlas and attempt to reconnect your site. ⚡ Step 2: Check for Plugin Conflicts Another active plugin may be interfering with how the EO Pixel is injected into your page's HTML. Security plugins, firewall plugins, and script optimization tools are frequent causes. 1. In your WordPress admin, go to Plugins → Installed Plugins. 2. Temporarily deactivate all plugins except the Search Atlas plugin. To do this safely, use a staging environment if one is available. 3. After deactivating other plugins, clear your cache again (Step 1) and retry the connection in Search Atlas. 4. If the connection succeeds, reactivate your other plugins one at a time, testing after each activation to identify the conflicting plugin. 5. Common conflicting plugin categories include: security firewalls (e.g., Wordfence, iThemes Security), script managers (e.g., Autoptimize, Asset CleanUp), and HTML minifiers. If you identify a conflicting plugin, check its settings for options that block or defer third-party scripts, and whitelist the Search Atlas plugin or its associated scripts. 🛡️ Step 3: Check for Theme or Script Optimization Issues Some WordPress themes and page builders (e.g., Elementor, Divi, Beaver Builder) apply their own script management or output buffering that can strip or delay pixel injection. - Temporarily switch your theme to a default WordPress theme (e.g., Twenty Twenty-Four) and test the connection again. - If your theme uses a child theme, deactivate the child theme and test with the parent theme only. - Disable any JavaScript deferral or concatenation settings in your theme's performance options and retest. ⏱️ Step 4: Allow for Initialization Race Conditions In some environments, there is a brief delay between plugin activation and the pixel becoming detectable on the live page. This is known as an initialization race condition. Search Atlas needs to scan a fully rendered, live version of your page — not a cached or partially loaded one. 1. After activating the plugin and clearing all caches, wait at least 5 minutes before attempting to reconnect in Search Atlas. 2. Visit your site's homepage in a private/incognito browser window to confirm it loads without errors. 3. Use a tool such as CTRL+U (View Page Source) in your browser to search for EO Pixel or the Search Atlas script tag in your raw HTML. If visible in the source, the pixel is present and the issue is likely on the detection side; proceed to Step 5. 4. If the pixel is not visible in the page source, the plugin is not injecting it correctly — return to Steps 2 and 3. 🌐 Step 5: Verify Site Accessibility and SSL Search Atlas must be able to reach your site externally to verify the pixel. Certain server configurations can block this. - Confirm your site is publicly accessible (not under maintenance mode or behind a login wall). - Ensure your site uses a valid SSL certificate (HTTPS). Sites with mixed content warnings or expired SSL certificates may cause detection failures. - If your site uses a robots.txt file that blocks all crawlers, temporarily allow access and retry. - If your hosting plan restricts external HTTP requests (some managed hosting environments do this), contact your host to confirm outbound and inbound requests are permitted. 🔄 Step 6: Reinstall the Plugin If none of the above steps resolve the issue, a clean reinstall of the Search Atlas plugin can clear corrupted installation files. 1. In WordPress, go to Plugins → Installed Plugins, deactivate, and then delete the Search Atlas plugin. 2. In Search Atlas, go to Avatar Menu (👤) → Settings → CMS Connectors and disconnect the existing site entry if present. 3. Reinstall the plugin fresh by uploading the latest .zip version from your Search Atlas dashboard via WordPress → Plugins → Add New → Upload Plugin. 4. Complete the authorization flow again using your Search Atlas credentials. 5. Clear all caches and wait 5 minutes before testing the connection. 📋 Information to Have Ready When You Escalate If you have completed all steps above and the error persists, our team will need the following information to investigate further. Please gather this before reaching out: - Your WordPress version and PHP version. - Your hosting provider name and plan type. - A list of active plugins at the time of the error. - A screenshot of the Search Atlas Avatar Menu (👤) → Settings → CMS Connectors screen showing the error. - A screenshot or copy of your page source (CTRL+U on your homepage) showing whether the EO Pixel script tag is present or absent. - Whether your site uses a CDN or WAF (Web Application Firewall), and which provider. 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.

🛠️ Fix OTTO Pixel Not Detected via Cloudflare

🔍 Overview After installing the OTTO pixel through a Cloudflare Worker, the OTTO dashboard may still display a "Not Installed" status — even though the Worker deployed successfully and the pixel was working previously. This article explains the most common causes and the steps to resolve them. ⚙️ Why This Happens The OTTO pixel verification system scans your live site to confirm the pixel is present and firing correctly. A "Not Installed" status after a Cloudflare Worker deployment is almost always caused by one of the following: - Cloudflare API authorisation failure (cf_10000): The Worker was deployed but Search Atlas lost the API connection needed to confirm or maintain the installation. This surfaces as a silent failure — the deploy appears to succeed, but the pixel is not injected. - Worker route not covering the correct URLs: The Cloudflare Worker route may be scoped to a path or subdomain that does not match the pages OTTO is scanning. - Cached or stale scan result: OTTO's scanner checked the page before the Worker had fully propagated across Cloudflare's network (propagation can take a few minutes). - Worker disabled or overridden: A Cloudflare configuration change (for example, a Page Rule, Cache Rule, or another Worker) may be intercepting requests before your OTTO Worker runs. - Pixel key conflict: A previous pixel key installation was not cleanly removed, causing a conflict that blocks detection. 🚀 Step-by-Step Resolution 1. Check the Cloudflare API connection. In Search Atlas, go to OTTO SEO (left sidebar). Open your OTTO project settings and navigate to the Pixel Installation section. If you see a Cloudflare authorisation error or a cf_10000 code, re-authenticate by reconnecting your Cloudflare API token. Ensure the token has Zone:DNS:Edit, Zone:Zone:Read, Workers Scripts:Edit, Workers Routes:Edit, and Workers KV Storage:Edit permissions (the 'Edit Cloudflare Workers' template plus a Zone DNS Edit row) for the correct zone. 2. Verify the Worker is active in Cloudflare. Log in to your Cloudflare dashboard. Go to Workers & Pages and confirm the OTTO Worker is listed and shows a status of Active. Check that the Worker route pattern matches your full domain (for example, royallrides.com.au/*) and is not limited to a subdirectory. 3. Confirm no conflicting rules exist. In Cloudflare, review Page Rules and Cache Rules for your domain. Any rule that bypasses Workers or returns a cached response before the Worker executes will prevent the pixel from loading. Disable or reorder conflicting rules so the OTTO Worker runs first. 4. Remove and reinstall the pixel. If the issue persists, perform a clean reinstall. In OTTO's Pixel Installation section, delete the existing pixel key, wait 60 seconds, then generate a new key and redeploy via the Cloudflare Worker option. This clears any stale key conflict. 5. Trigger a fresh scan. After redeployment, wait at least 3–5 minutes for Cloudflare propagation, then return to the OTTO SEO section in Search Atlas and click Re-check Installation (or equivalent scan trigger). The status should update to Installed. 6. Test on a live page. Open a page on your domain in a private/incognito browser window. Right-click → View Page Source and search for the OTTO pixel snippet. If it is absent, the Worker is not injecting it — revisit steps 1–3. 📊 Impact on SEO Rankings The OTTO pixel is required for OTTO to read your live site, apply on-page optimisations, and track ranking changes. While the pixel is undetected, no OTTO automations will execute on the site. This means approved changes — including title tags, meta descriptions, schema, and internal linking improvements — are not reaching your live pages, which directly limits ranking progress. Restoring pixel detection is the single most important fix before any other SEO work will take effect. 🛡️ Prevention Tips - Avoid rotating or regenerating your Cloudflare API token without updating the credentials in Search Atlas at the same time. - After any Cloudflare configuration change (zone settings, Cache Rules, new Workers), re-check the OTTO pixel status in the platform. - If you use a third-party performance or security layer on top of Cloudflare (for example, an additional WAF or CDN), verify it is not stripping injected scripts. 💬 Still Need Help? If you have followed the steps above and the pixel still shows as "Not Installed", our team can review your specific Cloudflare configuration and scan 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.

🔄 Fix OTTO Pixel Not Installed After Previous Setup

🧩 Why This Happens The OTTO Pixel is a small tracking script that Search Atlas places on your website to enable SEO automation features. Once installed, the platform periodically checks that the script is still present and accessible on your site. If you recently made changes to your WordPress site — such as updating a plugin, switching themes, clearing caches, or migrating hosting — WordPress may have served a cached version of your pages that no longer includes the OTTO Pixel script. From Search Atlas's perspective, the pixel appears missing even though it was installed correctly before. The most common fix is a full WordPress cache purge, which forces your site to rebuild its pages and serve the latest version — including the OTTO Pixel code. ⚠️ Before You Start - Confirm the OTTO Pixel status in Search Atlas by going to OTTO SEO in the left sidebar, then opening SEO Automation (URL: /seo-automation-v3) and checking the pixel installation indicator. - Do not reinstall the pixel script manually before clearing the cache — this can create duplicate tags. - If you use a CDN (such as Cloudflare, BunnyCDN, or Amazon CloudFront), you will need to purge that cache separately after clearing WordPress. 🖥️ Option 1: Managed WordPress Hosting If your site is hosted on a managed WordPress platform such as WP Engine, Kinsta, Flywheel, or Pressable, follow these steps: 1. Log in to your hosting control panel or dashboard. 2. Locate the Cache or Performance section — the exact label varies by host. 3. Select Clear All Cache or Purge Cache for your site. 4. Wait 60–90 seconds for the purge to complete. 5. Return to Search Atlas, go to OTTO SEO in the left sidebar and open SEO Automation, and check whether the OTTO Pixel status has updated to installed. Most managed hosts also provide a cache-clearing button directly inside the WordPress admin toolbar at the top of the screen. Look for a label such as Clear Cache or your host's name next to a cache icon. 🔧 Option 2: Self-Hosted WordPress with a Cache Plugin If you manage your own WordPress hosting and use a caching plugin, the steps depend on which plugin you have installed. WP Super Cache 1. In your WordPress admin, go to Settings → WP Super Cache. 2. Click Delete Cache on the Easy tab. W3 Total Cache 1. In your WordPress admin, click Performance in the left menu. 2. Select Purge All Caches from the dropdown. LiteSpeed Cache 1. In your WordPress admin, click LiteSpeed Cache in the left menu. 2. Select Manage, then click Purge All. WP Rocket 1. In your WordPress admin toolbar, click WP Rocket. 2. Select Clear cache. After purging, wait 60–90 seconds, then return to Search Atlas, go to OTTO SEO in the left sidebar and open SEO Automation, to confirm the pixel status has updated. ☁️ Option 3: Purge Your CDN Cache If your site runs behind a CDN, cached copies of your pages at the CDN edge may still be served without the OTTO Pixel. Purge your CDN cache after clearing WordPress: - Cloudflare: Log in to the Cloudflare dashboard → select your domain → go to Caching → Configuration → click Purge Everything. - Other CDNs: Refer to your provider's documentation for a full cache purge or contact your CDN provider's support. Once the CDN purge is complete, check the OTTO Pixel status again in Search Atlas. ✅ Confirming the Fix 1. In Search Atlas, navigate to OTTO SEO in the left sidebar and open SEO Automation. 2. Review the OTTO Pixel installation status indicator. 3. If the status now shows as installed, no further action is needed. 4. If the status still shows as not installed after completing all cache purges, proceed to the next section. 👩‍💻 When to Involve a Developer You may need developer assistance if any of the following apply: - You cleared all caches and the pixel still shows as not installed after 5–10 minutes. - Your site uses a custom or headless WordPress setup where standard cache plugins do not apply. - Your hosting environment uses server-level caching (such as Nginx FastCGI cache or Varnish) that cannot be cleared through the WordPress admin. - You are unsure whether your site has a CDN or additional caching layers in place. In these cases, ask your developer to verify that the OTTO Pixel script tag is present in the rendered HTML source of your homepage and that no caching layer is stripping script tags from page output. 💬 Need More Help? 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.

🛠️ Fix OTTO Pixel UUID Errors on WordPress

🔍 Overview The OTTO pixel connects your website to Search Atlas so OTTO SEO can read your site's data and apply optimisations. On WordPress, the most common setup issues are an incorrectly entered UUID, a misconfigured plugin installation, or a white-label domain that interferes with pixel verification. This article walks you through the correct setup process and explains how to resolve each of these issues. ⚙️ Step 1 — Find Your OTTO Pixel UUID Before touching WordPress, make sure you have the correct UUID from Search Atlas. 1. Log in to Search Atlas and navigate to OTTO SEO in the left sidebar, then open SEO Automation (URL: /seo-automation-v3). 2. Select the project you are connecting. 3. Open the OTTO Pixel or Connect Site section. 4. Copy the full UUID — it is a long alphanumeric string. Copy it directly from the platform to avoid typos. Important: The UUID is unique to each project. If you manage multiple sites, confirm you are copying the UUID that belongs to the exact domain you are configuring. 🔌 Step 2 — Install the Pixel Using the WordPress Plugin Search Atlas provides a dedicated WordPress plugin that inserts the OTTO pixel automatically when you enter your UUID. Follow these steps precisely. 1. In your WordPress admin dashboard, go to Plugins → Add New → Upload Plugin, upload the Search Atlas plugin .zip file provided by Search Atlas, then install and activate the plugin. 2. After activation, go to the Search Atlas top-level menu in the WordPress admin sidebar and open Settings. 3. Paste your UUID into the OTTO Pixel UUID field. Do not add extra spaces, quotation marks, or any other characters around it. 4. Save your settings. Once saved, the plugin automatically injects the pixel script into every page of your site. You do not need to manually copy or paste the full script code anywhere — the plugin handles this for you. If you have been manually inserting script code, remove those manual insertions to avoid duplication conflicts. ✅ Step 3 — Verify the Pixel Is Firing Correctly After saving, return to Search Atlas and use the pixel verification tool to confirm the connection. 1. Navigate back to OTTO SEO → SEO Automation → your project → OTTO Pixel section. 2. Click Verify Pixel or Check Connection. 3. If verification passes, your setup is complete. 4. If you still see a "UUID not correct" error, continue to the troubleshooting steps below. ⚠️ Troubleshooting: "UUID Not Correct" Error If the platform still reports that the UUID is not recognised after following the steps above, work through the following checks in order. - Re-copy the UUID: Select all text in the UUID field in Search Atlas, copy it fresh, clear the WordPress plugin field completely, and paste again. A single wrong character will cause verification to fail. - Check for caching: WordPress caching plugins (WP Rocket, W3 Total Cache, LiteSpeed Cache, etc.) can serve a cached version of your pages that does not yet include the pixel. Clear all caches after saving the plugin settings, then re-run verification. - Check for conflicting scripts: If you previously inserted the OTTO script manually into your theme's functions.php, a header/footer plugin, or Google Tag Manager, remove those manual copies. Duplicate or malformed script instances will cause verification errors. - Confirm the plugin is active: Go to Plugins → Installed Plugins and confirm the Search Atlas plugin status shows Active. An inactive plugin will not inject any code. - Check your domain matches the project: In Search Atlas, confirm the domain listed under the project exactly matches the live URL of your WordPress site, including whether it uses www or not. 🌐 White-Label Domain Conflicts If your Search Atlas account is accessed through a white-label domain (for example, a custom URL like dashboard.youragency.com that points to the Search Atlas platform), this affects only the interface URL you use to log in — it does not affect how the OTTO pixel functions on your client's website. However, there are two scenarios where a white-label domain can indirectly cause issues. - Pixel script source URL: In some configurations, the pixel script may reference the Search Atlas origin domain. If your white-label setup involves custom DNS routing or SSL termination that blocks outbound requests, the pixel call may fail. Confirm with your hosting or DNS provider that your white-label domain correctly passes through all traffic to the Search Atlas platform without blocking script requests. - UUID copied from the wrong environment: If you have both a white-label dashboard and the main Search Atlas dashboard open, ensure you copy the UUID from the same environment where the project is registered. UUIDs are consistent across both interfaces, but double-checking removes any doubt. In most cases, a white-label domain configured correctly as a DNS CNAME or proxy to the Search Atlas platform will not interfere with pixel verification. If you have confirmed all the steps above and the error persists, the issue is most likely a caching layer or a duplicate script conflict rather than the white-label domain itself. 📋 Quick-Reference Checklist - UUID copied directly from OTTO SEO → SEO Automation → project → OTTO Pixel with no extra characters - Search Atlas WordPress plugin installed and Active - UUID pasted into the plugin settings and saved - No manual script copies in theme files, header/footer plugins, or Tag Manager - All WordPress caches cleared after saving - Project domain in Search Atlas matches the live site URL exactly - White-label domain DNS/proxy confirmed as passing through traffic correctly 💬 Need More Help? 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.

🔍 Verify OTTO Pixel Installation on WordPress + GTM

🧭 Overview If you see the message 'OTTO Pixel is not installed correctly' inside the OTTO dashboard, it means our system could not detect a valid Pixel signal from your website. This can happen even when the WordPress plugin is active and your GTM container is published. This guide walks you through a structured diagnostic process to identify and fix the exact cause. ⚠️ Before You Begin Confirm the following are already in place before proceeding: - The Search Atlas WordPress plugin is installed and activated on your site. - Your GTM container is published (not just saved in draft). - You are checking the correct domain — the one connected to your OTTO campaign. 🪜 Step 1 — Identify Your Installation Method The OTTO Pixel should only be installed through one method at a time. Using both the WordPress plugin and a GTM tag simultaneously is the most common cause of this error. Determine which method you are relying on: - WordPress Plugin only — The plugin injects the Pixel directly into your site's code. No GTM tag is needed. - GTM only — The Pixel fires through a GTM tag. The WordPress plugin's Pixel output should be disabled or the plugin should not be handling Pixel injection. If both methods are active at the same time, the signals can conflict and cause verification to fail. Choose one method and disable the other before continuing. 🔎 Step 2 — Verify the Pixel Is Firing in Your Browser This is the most reliable way to confirm whether the Pixel is actually loading on your site. Follow these steps: 1. Open your website in Google Chrome. 2. Right-click anywhere on the page and select Inspect. 3. Click the Network tab at the top of the DevTools panel. 4. In the filter bar, type otto or your Pixel ID to filter requests. 5. Reload the page. 6. Look for a network request that matches your OTTO Pixel ID. If you see it fire with a 200 status code, the Pixel is loading correctly. 7. If no request appears, the Pixel is not firing — continue to Step 3. Pro tip: You can also use the Google Tag Assistant Chrome extension to confirm your GTM container is loaded and which tags are firing on the page. 🏷️ Step 3 — Check Your GTM Tag Configuration If you are using GTM as your installation method, verify the tag is set up correctly: 1. Open your GTM workspace and locate the OTTO Pixel tag. 2. Confirm the tag type is Custom HTML and contains the full Pixel script provided in the Search Atlas platform. 3. Check the trigger — it should fire on All Pages (Page View) unless you have a specific reason to limit it. 4. Open GTM Preview Mode and load your website. Confirm the OTTO Pixel tag appears under Tags Fired on page load. 5. If the tag appears under Tags Not Fired, your trigger is not configured correctly — update it to fire on All Pages and re-publish the container. 6. After any changes, click Submit in GTM to publish the updated container. Saving alone does not push changes live. 🔌 Step 4 — Check for Plugin or Script Conflicts Certain WordPress configurations can block the Pixel from loading: - Caching plugins (WP Rocket, W3 Total Cache, LiteSpeed Cache) — Clear all caches after any change and confirm the Pixel is not being stripped from cached pages. - Cookie consent or privacy plugins — Tools like Cookiebot or Complianz can block third-party scripts until a user consents. Test the Pixel in a browser session where consent has been granted, or temporarily whitelist the Pixel script. - Script optimization plugins — Plugins that defer, delay, or combine JavaScript (such as Autoptimize) can interfere with GTM or direct Pixel loading. Exclude GTM or the Pixel script from optimization rules. - Security or firewall plugins — Wordfence or similar plugins may block external script calls. Check your firewall logs for blocked requests related to the Pixel. 📹 Step 5 — Record a Verification Video If the Issue Persists If you have completed Steps 1–4 and the error message remains, the fastest way to get a resolution is to record a short screen video. This allows our team to see exactly what is happening in your setup and pinpoint the cause immediately. Your video should show: 1. Your WordPress plugin settings page confirming the plugin is active. 2. Your GTM workspace showing the tag, trigger, and that the container is published. 3. The GTM Preview Mode session on your live site showing which tags fired. 4. The browser Network tab filtered for your Pixel ID after a page reload. 5. The OTTO dashboard showing the error message. A 2–3 minute recording covering these screens gives our support team everything needed to diagnose the issue without back-and-forth delays. ✅ Step 6 — Re-run Pixel Verification in Search Atlas Once you have made any changes, return to the platform to trigger a fresh check: 1. In the left sidebar, go to OTTO SEO → All Sites (SEO Automation) (URL: /seo-automation-v3). 2. Open your OTTO campaign and navigate to the Pixel settings section. 3. Click Verify Pixel or the equivalent re-check button to run a new detection scan. 4. Wait up to 5 minutes for the system to confirm the signal before re-checking the status. 💬 Still Seeing the Error? If you have followed every step above and the Pixel is still not verifying, our team can review your video recording and configuration directly. 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.

🛠️ Fix WordPress CMS Sync False Detection Error

🔍 What Is This Error? When you attempt to sync content to your WordPress site through Search Atlas, you may see a message stating "No WordPress website found" even though the Search Atlas WordPress plugin is installed and active. This false detection error can also cause your PR Distribution job to stall at 50% progress. This is a known issue currently being resolved by our engineering team. In the meantime, follow the steps below to get your sync working again. ✅ Step 1: Verify the Plugin Is Installed and Active 1. Log in to your WordPress admin dashboard. 2. Navigate to Plugins → Installed Plugins. 3. Confirm the Search Atlas plugin is listed and its status shows Active. 4. If the plugin is deactivated, click Activate and wait a few seconds before retrying the sync. 🔑 Step 2: Re-Authenticate the Plugin Authentication issues between the plugin and your Search Atlas account are a common cause of false detection errors. Follow these steps to refresh the connection: 1. Inside your WordPress admin, open the Search Atlas plugin settings page. 2. Disconnect and then reconnect your Search Atlas account by re-entering your API credentials or re-authorising via the provided login flow. 3. Save the settings and confirm the plugin shows a connected status. ⚙️ Step 3: Retry the CMS Sync in Search Atlas 1. Go to OTTO SEO → SEO Automation (All Sites) in the left sidebar (or navigate to /seo-automation-v3). 2. Locate the page or task where the sync failed. 3. Toggle Sync to CMS off, wait five seconds, then toggle it back on. 4. Monitor the progress indicator. The sync should now advance past the point where it previously stalled. 📋 Step 4: Check for PR Distribution Job Stalls If your PR Distribution job is stuck at 50% progress, this is directly linked to the CMS sync failure. Once the sync error is resolved using the steps above, the job should resume automatically. If it does not resume within a few minutes: - Refresh the page and check the job status again. - If the job remains at 50%, cancel it, resolve the sync issue first, and then resubmit the PR Distribution job. 🚫 Common Mistakes to Avoid - Do not install duplicate versions of the Search Atlas plugin — remove any older copies before reinstalling. - Do not use a caching plugin that may block the plugin's authentication requests. Temporarily disable caching and retry if issues persist. - Ensure your WordPress site is publicly accessible and not in maintenance mode, as Search Atlas cannot detect a site that is offline or behind a maintenance screen. - Confirm your WordPress site URL in Search Atlas exactly matches your actual site URL, including whether it uses www or not, and http vs https. 💡 Why Does This Happen? The false detection error occurs when Search Atlas is unable to receive a valid response from your WordPress plugin during the connection check. This can be caused by plugin authentication timeouts, URL mismatches, server configuration issues, or a temporary bug in the sync process. Our team has already shipped fixes for several cases of this error, and further improvements are in active development. 🆘 Still Seeing the Error? If you have followed all the steps above and the CMS sync still fails, our team can investigate your specific site configuration directly. 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. When you reach out, please have the following ready to speed up the investigation: - Your WordPress site URL as entered in Search Atlas - A screenshot of the error message and the plugin settings page - The name of any caching or security plugins active on your site

🔧 Fix WordPress Plugin Fatal Error and OTTO Pixel Alert

Overview Two separate issues can block a successful Search Atlas WordPress plugin installation: a fatal error that prevents activation entirely (commonly caused by PHP 7.4 incompatibility), and a site alert triggered after manually adding the OTTO pixel snippet to your theme header. This article walks you through resolving both issues in the correct order. Issue 1 — Fatal Error Blocks Plugin Activation (PHP 7.4) If you see "Plugin could not be activated because it triggered a fatal error" immediately after trying to activate the Search Atlas plugin, the most likely cause is that your server is running PHP 7.4, which is below the minimum required version. Why this matters: Standard troubleshooting steps — such as deactivating conflicting plugins or checking error logs inside WordPress — assume the plugin can at least partially load. When activation fails completely, those steps will not help until the PHP version is resolved first. 1. Confirm your current PHP version. Check your hosting control panel (cPanel, Plesk, or equivalent) — most hosts display the active PHP version under PHP settings or a similar section. You can also ask your host directly if you are unsure where to find this. 2. If your version is below PHP 8.0, upgrade to PHP 8.0 or higher. PHP 8.1 or 8.2 is recommended for best compatibility. Most managed hosts allow you to switch PHP versions from their control panel — consult your host's documentation if you are unsure how to do this. 3. After upgrading PHP, return to the Plugins section in your WordPress dashboard and activate the Search Atlas plugin again. 4. If the fatal error persists after upgrading PHP, check your server's PHP error log (available through your hosting control panel or via FTP) and note the exact error message before contacting support. Do not proceed to the OTTO pixel steps below until the plugin activates successfully. Adding the pixel snippet to a site where the plugin is not active will not establish a connection and may cause the alert described in Issue 2. Issue 2 — Site Alert After Adding the OTTO Pixel Snippet If you were advised to manually paste the OTTO pixel snippet into your theme's header and you then saw an alert or warning appear on your site, the snippet itself is the cause. This is a known side effect of adding the snippet to certain themes or page builders, and it must be removed before the alert will stop. How to remove the snippet and clear the alert: 1. Log in to your WordPress dashboard. 2. Navigate to your theme's header file. Depending on your setup, you can do this through your theme's editor in the Appearance section of your WordPress dashboard, or by using an FTP client or your host's File Manager to access the theme files directly. 3. Locate the OTTO pixel snippet and remove it completely, then save the file. 4. Confirm that the alert no longer appears on your site. If you continue to experience issues after following these steps, please reach out to our support team via the chat widget in your Search Atlas dashboard and we will be happy to help.

⚠️ GHL PDF Export: "Hide Empty Sections" Toggle and Known PDF Limitation

When you enable Hide Empty Sections in a GHL classical report, the web view correctly removes blank sections — but that setting does not carry over when you download the report as a PDF. A fix is actively being deployed; the workarounds below help you produce clean exports in the meantime. 📋 How the "Hide Empty Sections" Toggle Works in GHL Classical Reports The Hide Empty Sections toggle lives in the Report Builder for GHL classical reports. Enable it, and any section that contains no data — such as the Local SEO section — is removed from the web view instantly, keeping your report focused on populated data only. ⚠️ Known Issue: Empty Sections Reappear in Downloaded GHL PDF Reports When you download a GHL classical report as a PDF with Hide Empty Sections enabled, the PDF does not reflect the toggle state. Empty sections that are correctly hidden in the web view reappear in the exported file. This happens because the PDF rendering engine reads the full report structure rather than the filtered web view state — producing a PDF with blank placeholder sections, such as an empty Local SEO block, even when the toggle is on. Scope: This affects GHL classical reports only. Custom report layouts are not impacted. 🛠️ Workarounds While the Hide Empty Sections PDF Fix Is Deployed Use one of the following approaches to deliver a clean report to your client while the fix rolls out: 1. Share the live web report link. The web view correctly applies Hide Empty Sections, so recipients see only populated sections — no PDF download required. 2. Print to PDF directly from your browser: 1. Open the GHL classical report in your browser with Hide Empty Sections enabled. 2. Press Ctrl + P (Windows) or Cmd + P (Mac) to open the print dialog. 3. Set the destination to Save as PDF. 4. Click Save. The PDF captures the filtered web view and excludes empty sections. 3. Populate missing data before exporting. If a section is empty because data has not yet synced, complete the data entry first. With all sections populated, no blank sections appear in the PDF regardless of the toggle state. After exporting, review the PDF to confirm only data-filled sections are visible before sending it to your client. 🔄 Current Fix Status for the GHL PDF Hide Empty Sections Issue This issue (internal reference: RB-1278) is in In Release status — the fix is complete and actively being deployed to production. No action is required on your end; the update applies to your account automatically once the rollout is complete. After the fix is live, the Hide Empty Sections toggle will apply consistently to both the web view and all downloaded PDFs in GHL classical reports. 🎯 You now know why empty sections appear in GHL PDF exports despite the Hide Empty Sections toggle being on, and have three workarounds available until the fix reaches your account. For more on building and customizing GHL reports, explore the GHL Report Builder articles in this Help Center.

🛠️ Fix OTTO Pixel Not Found on Squarespace

🔍 Why Does This Happen? When Search Atlas reports that your OTTO pixel is not found on your Squarespace site, it almost always means the pixel code was not placed in the correct location, was saved incorrectly, or Squarespace's caching is delaying detection. This article walks you through the exact steps to install the pixel correctly and get it verified. 📋 Before You Begin - Make sure you are logged in to both your Search Atlas account and your Squarespace account. - You will need access to your site's Code Injection settings in Squarespace — this requires a Basic plan or higher. The Personal plan does not support code injection. - Have your OTTO pixel code ready to copy from Search Atlas. ⚙️ Step 1: Copy Your OTTO Pixel Code 1. In Search Atlas, go to OTTO SEO in the left sidebar, then open SEO Automation (or navigate to /seo-automation-v3). 2. Select your connected Squarespace website from the property selector. 3. Locate the OTTO Pixel section and click Copy Pixel Code. 4. Keep this code in your clipboard — do not modify it in any way. 🖥️ Step 2: Add the Pixel to Squarespace Code Injection 1. Log in to your Squarespace account and open your site. 2. In the left panel, click Settings. 3. Scroll down and click Advanced, then select Code Injection. 4. Paste your OTTO pixel code into the Header field. It must go in the Header, not the Footer. 5. Click Save and wait for the confirmation message before closing the page. ✅ Step 3: Verify the Pixel is Live 1. After saving, open your Squarespace site in a new browser tab and do a hard refresh (Ctrl + Shift + R on Windows or Cmd + Shift + R on Mac) to clear cached versions of the page. 2. Return to Search Atlas and navigate back to OTTO SEO in the left sidebar (/seo-automation-v3). 3. Click Check Pixel Status or re-run the site verification. Detection can take up to 5 minutes after a confirmed save. 🚫 Common Mistakes to Avoid - Wrong location: Pasting the pixel into the Footer or into a specific page's injection area instead of the site-wide Header field. - Modified code: Accidentally adding spaces, line breaks, or extra characters when pasting. - Unsupported plan: Squarespace Personal plan does not allow code injection. Upgrade to Basic or higher. - Caching delay: Squarespace can cache pages aggressively. Always hard-refresh or test in an incognito window after saving. - Multiple paste: Pasting the pixel code more than once in the Header field. Only one instance should be present. 🔄 Still Showing 'Not Found' After These Steps? If the pixel status still shows not found after following all steps above, try the following: - Open your site in an incognito or private browser window to rule out local cache issues. - Use your browser's View Page Source (right-click → View Page Source) and search for your pixel code to confirm it is present in the HTML. - Disconnect and reconnect your Squarespace site in Search Atlas, then re-paste the pixel code. - Check that no third-party scripts or Squarespace extensions are blocking custom code injection on your site. 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. Additional Notes When you first install the OTTO pixel, Search Atlas runs a full site audit that can take up to 24 hours to complete. Until finished, status shows 'Not Found' even if installed correctly — this is expected behavior. Also: verify install by right-clicking your live site, selecting View Page Source, and searching for your pixel ID or OTTO script tag.

🛠️ Fix Zoomed Images Caused by the Search Atlas Plugin

If images on your WordPress site appear zoomed or oversized after activating the Search Atlas (SA) plugin, clearing the Elementor cache resolves the issue. The fix takes less than a minute and requires no changes to the Search Atlas plugin itself. This article applies to WordPress sites that use Elementor as their page builder. If you use a different page builder, contact Search Atlas support. 🛠️ How to Clear the Elementor Cache in WordPress When the Search Atlas plugin is activated on a site running Elementor, the Elementor cache may need to be regenerated to render images at the correct size. Follow these steps in your WordPress admin panel (verified for Elementor 3.x): 1. Log in to your WordPress admin dashboard. 2. In the left sidebar, go to Elementor → Tools. 3. Click the General tab. 4. Click Regenerate Files & Data. 5. Wait for the on-screen confirmation that the process is complete. After regenerating, reload any affected page. Images return to their correct display size. If the issue reappears after a future Search Atlas plugin update or reactivation, repeat these steps to regenerate the cache. ✅ Confirm the Fix Worked Open an affected page and perform a hard refresh to bypass your browser's local cache: - Windows: Ctrl+Shift+R - Mac (Chrome/Firefox): Cmd+Shift+R - Safari on Mac: Cmd+Option+R, or go to Develop → Empty Caches then reload Images should now display at their correct size. Because the root cause is server-side, confirming the fix in one browser is sufficient — the resolution applies across all browsers automatically. 🌀 Clearing the Elementor cache after activating the Search Atlas plugin restores normal image rendering across your entire WordPress site. If images remain zoomed after completing these steps, contact Search Atlas support for a hands-on review of your configuration.

🛡️ Fix WordPress Sync Blocked by Cloudflare WAF

🔍 What Is This Error? When Search Atlas attempts to sync or publish content to your WordPress site, our servers send requests to your site's API. If Cloudflare's Web Application Firewall (WAF) is active on your domain, it may identify these requests as suspicious and block them — returning a cloudflare_blocked error in the platform. This is one of the most common reasons WordPress sync fails. The good news is that it can be resolved quickly inside your Cloudflare dashboard without disabling your firewall entirely. ⚙️ How to Fix the Cloudflare Block Follow these steps to whitelist Search Atlas traffic in Cloudflare so sync can complete successfully. 1. Log in to your Cloudflare dashboard at cloudflare.com and select the domain connected to your WordPress site. 2. Go to Security → WAF in the left-hand navigation menu. 3. Click on Tools (or IP Access Rules depending on your Cloudflare plan). 4. Create a new Allow rule for Search Atlas IP ranges. Contact our team via the chat widget (see below) to request the current list of IP addresses used by Search Atlas sync services. 5. Alternatively, use a Custom WAF Rule to allow requests that include the Search Atlas user-agent string or target the /wp-json/ REST API endpoint from our servers. 6. Save the rule and make sure it is set to Allow, not Challenge or Block. 7. Return to Search Atlas and retry the WordPress sync from the platform. 🔎 Alternative: Use a Page Rule to Bypass WAF If you prefer not to modify WAF rules directly, Cloudflare Page Rules offer a simpler bypass option for the WordPress REST API path. 1. In your Cloudflare dashboard, go to Rules → Page Rules. 2. Click Create Page Rule. 3. In the URL field, enter your site's REST API path, for example: yourdomain.com/wp-json/* 4. Set the action to Disable Security. 5. Save and deploy the rule. This tells Cloudflare to skip WAF checks for all REST API requests on that path, which is where Search Atlas communicates with your WordPress site. 🛠️ Check the Search Atlas WordPress Plugin In addition to the Cloudflare fix, make sure the Search Atlas WordPress plugin is correctly installed and authenticated on your site. A blocked or timed-out connection can sometimes look similar to a firewall error. - Log in to your WordPress admin panel and navigate to Plugins → Installed Plugins. - Confirm the Search Atlas plugin is active and up to date. - If the plugin shows an authentication error, deactivate it, then reactivate it and complete the authorization flow again from within the Search Atlas platform. - Once reauthorized, retry the sync. ✅ Confirm Sync Is Working After applying the Cloudflare fix and verifying the plugin status, test the connection: 1. Inside Search Atlas, go to the WordPress Sync section. 2. Select your WordPress website from the site selector. 3. Attempt to publish or sync a piece of content. 4. If the sync completes without a cloudflare_blocked error, the issue is resolved. If the error persists after following all steps above, the block may be coming from an additional security layer such as a server-level firewall, a separate security plugin (for example Wordfence or Sucuri), or a hosting provider firewall. Check those settings as well. 💡 Tips to Prevent This in the Future - Whenever you update or change your Cloudflare security settings, re-test the WordPress sync to ensure access is still permitted. - If you migrate your WordPress site to a new domain or host, reconnect the Search Atlas plugin and recheck firewall rules for the new environment. - Keep the Search Atlas WordPress plugin updated to ensure compatibility with the latest sync improvements and authentication methods. 🙋 Still Need Help? 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.

🛠️ Fix WordPress Plugin Fatal Errors and OTTO Pixel Alerts

🔍 Overview Some customers encounter a fatal error when activating the Search Atlas WordPress plugin, or see an alert after adding the OTTO pixel snippet to their theme header. This article explains the most common causes and how to fix them so you can connect your site and start using OTTO SEO. ⚠️ Fatal Error on Plugin Activation If you see a message like "Plugin could not be activated because it triggered a fatal error", the most common causes are: - PHP version incompatibility — The plugin requires PHP 8.0 or higher. PHP 7.4 (including 7.4.33) is no longer supported and will cause a fatal error on activation. - Outdated plugin version — Versions prior to 2.6.11 contain a known bug involving an undefined constant that triggers a fatal on activation. - Conflict with page builder themes — Certain themes such as Divi can trigger HTTP render fatal errors due to a conflict with the OTTO pixel class. ✅ How to Fix the Activation Fatal Error 1. Upgrade PHP to 8.0 or higher. Log in to your hosting control panel (e.g., cPanel, Plesk, or your host's dashboard) and change your PHP version. If you are unsure how to do this, contact your hosting provider. 2. Install the latest plugin version. Delete the current Search Atlas plugin from your WordPress admin panel, then download and install the latest version from the WordPress plugin repository or your Search Atlas dashboard. Versions 2.6.11 and above include fixes for the undefined constant fatal error. 3. Deactivate conflicting plugins or themes temporarily. If you use Divi or another heavy page builder, try activating the Search Atlas plugin with the default WordPress theme active to isolate the conflict. The render fatal error affecting Divi sites has been patched in recent plugin releases — ensure you are on the latest version. 4. Clear any caching layers. After updating PHP or the plugin, clear your server cache, object cache, and any CDN cache before retrying activation. 🚨 OTTO Pixel Snippet Alert in the Platform After you add the OTTO pixel code to your theme header, you may see an alert inside the Search Atlas platform. This usually means one of the following: - The pixel endpoint (/wp-json/otto-seo/v1/pixel) is not yet available — this can happen if the plugin did not activate successfully or if you are running an older plugin version. - The pixel code was added to the wrong location in your theme, or a caching plugin is serving a stale version of your header. - A memory exhaustion issue on very large pages is preventing the pixel from rendering correctly. ✅ How to Fix the Pixel Alert 1. Confirm the plugin is active and up to date. In your WordPress admin panel, go to Plugins → Installed Plugins and verify the Search Atlas plugin is active and shows the latest version number. 2. Check the pixel endpoint. In your browser, visit https://yourdomain.com/wp-json/otto-seo/v1/pixel (replace with your actual domain). If you see a valid JSON response, the endpoint is live. If you get a 404, the plugin is not active or the REST API is blocked — check your permalink settings under Settings → Permalinks and re-save them. 3. Verify pixel placement. The snippet must be placed inside the <head> tag of your theme. In most themes, this is done via Appearance → Theme File Editor → header.php, or through a dedicated header/script injection field in your theme settings. 4. Purge all caches. After confirming placement, purge your caching plugin (e.g., WP Rocket, W3 Total Cache), server-side cache, and CDN cache so the updated header is served immediately. 5. Check server memory. If your site has very large pages, the plugin's HTML processing may hit PHP memory limits. Increase WP_MEMORY_LIMIT in your wp-config.php file to at least 256M, or ask your hosting provider to raise the PHP memory limit. 📊 Verify the Connection in Search Atlas Once the plugin is active and the pixel is in place, confirm everything is working: 1. Log in to Search Atlas and navigate to OTTO SEO → All Sites (SEO Automation) in the left sidebar. 2. Check that your WordPress site shows as connected and that OTTO SEO is enabled for your domain. 3. If the alert persists after completing all steps above, wait 5 minutes and refresh the page — propagation can take a short time. 💡 Quick Reference: Requirements Checklist - PHP version: 8.0 or higher - Plugin version: 2.6.11 or higher (latest recommended) - Pixel endpoint: /wp-json/otto-seo/v1/pixel must return a valid response - Pixel placement: inside the <head> tag of your theme header - PHP memory limit: 256M or higher recommended - Permalinks: re-save after any plugin reactivation 🙋 Still Need Help? 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.

🛠️ Fix WordPress Plugin Blog Post Publishing Errors

🔍 Overview Some users encounter errors when attempting to publish or sync a blog post through the Search Atlas WordPress plugin. Common symptoms include a generic publish failure message, an HTTP 400 error, or a prompt asking for an application password that does not appear in your settings. This article explains what causes these issues and what steps to take. ❓ Do You Need an Application Password? No. As of plugin version 2.6.10, the Search Atlas WordPress plugin uses its own API key for authentication. You do not need to set up a WordPress application password. If you see guidance elsewhere suggesting this step, it does not apply to the current version of the plugin. You can safely ignore any prompts or instructions related to application passwords. ✅ Step 1: Confirm Your Plugin Is Connected Before investigating further, verify that your WordPress site is properly connected to Search Atlas: 1. Log in to your Search Atlas account. 2. Navigate to Avatar Menu (👤) → Settings → CMS Connectors. 3. Confirm that your site appears as connected and that the connection status shows no errors. 4. If the site is not connected, disconnect and reconnect it to refresh the authentication. ⚙️ Step 2: Check Your Plugin Version Make sure you are running the latest version of the Search Atlas WordPress plugin. An outdated plugin version can cause compatibility issues with the publishing pipeline. 1. Log in to your WordPress admin dashboard. 2. Go to Plugins → Installed Plugins. 3. Locate the Search Atlas plugin and check the version number. 4. If an update is available, apply it immediately and then retry publishing. 🔄 Step 3: Retry Publishing the Article After confirming the connection and plugin version, attempt to publish or sync your blog post again. In some cases, a temporary failure in the publishing pipeline can resolve itself after a reconnection or plugin update. 1. Open your article inside Content Genius by going to Left sidebar → Content → Content Genius. 2. Select the article you want to publish. 3. Attempt to publish or sync it to your connected WordPress site. 4. If the error persists, note the exact error message displayed — this will be important for the support team. ⚠️ When the Error Is a Known Bug In some cases, a publishing failure is caused by an issue on the Search Atlas side — specifically a pipeline error that prevents the API key from being recognised correctly during the publish request. This is a known bug that the engineering team has actively worked to resolve. If you have completed all the steps above and the error still occurs, this is likely a platform-level issue rather than a configuration problem on your end. You have not done anything wrong. The most effective next step is to contact our support team so they can investigate your specific account and connected site. 🚫 Common Errors This Article Covers - Could not publish to WordPress page - Unable to publish blog post (rest_forbidden error) - Unable to save content as a draft to a connected WordPress account - Empty response from the WordPress publish endpoint - HTTP 400 INVALID_ARGUMENT error related to the publishing pipeline 💬 Contact Support If you have followed all the steps above and are still unable to publish your blog post, our team can investigate the issue directly on your account. 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. When reaching out, please share the following to help us resolve your issue faster: - The exact error message you are seeing - Your WordPress site URL - The version of the Search Atlas WordPress plugin you have installed - The article title or URL you were trying to publish

🛠️ Breadcrumbs "Enable" Toggle Reverts to ON After Saving in MetaSync

A bug in MetaSync causes the Enable Breadcrumbs toggle to revert to ON after saving, generating duplicate BreadcrumbList schema that conflicts with Yoast SEO. Update MetaSync to the latest version to permanently fix this. ⚠️ What Happens When you uncheck Enable Breadcrumbs in MetaSync settings and click Save Changes, the page reloads with the checkbox back to ON. The setting is not persisted. This causes MetaSync to keep injecting BreadcrumbList structured data alongside Yoast SEO's breadcrumb schema, which Google flags as a critical structured data conflict in Google Search Console. 🔍 Who Is Affected This issue affects you if all of the following apply: - MetaSync is installed on a WordPress site. - Yoast SEO is also active with its breadcrumbs enabled. - Google Search Console shows a critical error for duplicate BreadcrumbList structured data. ⚙️ How to Fix It This bug is resolved in the latest MetaSync release. Update the plugin to apply the fix. 1. In your WordPress dashboard, go to Plugins → Installed Plugins. 2. Find MetaSync and click Update Now. If no update appears, deactivate then reactivate MetaSync to clear any cached plugin state. 3. Go to MetaSync → Settings → Breadcrumbs. 4. Uncheck Enable Breadcrumbs and click Save Changes. 5. Reload the settings page and confirm the checkbox stays unchecked. After saving, MetaSync stops injecting BreadcrumbList schema and the conflict with Yoast is resolved. ✅ How to Verify the Fix Worked Confirm the fix is working correctly: - Reload MetaSync → Settings → Breadcrumbs — the Enable Breadcrumbs checkbox should remain unchecked. - Run an affected page through Google's Rich Results Test — only one BreadcrumbList entry (from Yoast) should appear. - The critical error in Google Search Console will clear after Google re-crawls your affected pages, typically within 1–2 weeks. 💡 If the Toggle Still Reverts After Updating If the checkbox continues to revert even after updating MetaSync: - Clear your WordPress object cache using your caching plugin (WP Rocket, W3 Total Cache, LiteSpeed Cache, or similar). - Deactivate other SEO or schema plugins temporarily to rule out a secondary conflict. - Contact Search Atlas support with your MetaSync version number and a screenshot of the Breadcrumbs settings page immediately after saving. 🎯 Now that MetaSync is updated, the Enable Breadcrumbs toggle persists correctly and your site no longer outputs duplicate BreadcrumbList schema. If Search Console still shows errors after applying the fix, allow 1–2 weeks for Google to re-crawl and revalidate your affected pages.

🔌 Fix OTTO Pixel UUID Errors with White-Label Domains

🧭 Overview If you have installed the Search Atlas WordPress plugin and entered your UUID but still see a "UUID not correct" error, your white-label domain configuration is likely the cause. Standard plugin installations validate the UUID against the default Search Atlas dashboard URL. When your account uses a custom white-label domain — such as dashboard.hearingassetadvisors.com — the plugin needs additional configuration to recognize that domain as a trusted source. This article walks you through every fix. 🔍 Why White-Label Domains Cause UUID Errors The OTTO pixel plugin validates your UUID by communicating with the Search Atlas dashboard. If your account is accessed through a white-label domain, the plugin must be told which domain to trust. Without this, the handshake between your WordPress site and the dashboard fails, producing a UUID validation error even when the UUID itself is perfectly correct. - The UUID displayed inside a white-label dashboard is the same UUID used platform-wide — no separate UUID is issued. - The error is not caused by a wrong UUID; it is caused by a domain mismatch during validation. - Resolving the mismatch requires configuring the plugin settings under Search Atlas → Settings or inserting the pixel script manually. ✅ Step 1 — Verify Your UUID Is Copied Correctly Before changing any settings, confirm the UUID itself is error-free. 1. Log in to your dashboard through your white-label domain (for example, dashboard.hearingassetadvisors.com). 2. Navigate to OTTO SEO → All Sites (SEO Automation) in the left sidebar. 3. Locate your OTTO pixel UUID. It is a long alphanumeric string with hyphens. 4. Click the copy icon next to the UUID — do not type it manually. 5. Paste it into a plain-text editor and confirm there are no leading spaces, trailing spaces, or line breaks. 6. Re-enter this clean UUID in the WordPress plugin settings and save. If the error persists after this step, continue to Step 2. ⚙️ Step 2 — Enable the White-Label Domain in Plugin Settings The Search Atlas WordPress plugin includes a setting that allows you to declare your white-label domain so UUID validation routes correctly. 1. In your WordPress admin panel, go to Search Atlas → Settings in the sidebar. 2. Locate the field labelled Dashboard Domain or Custom Domain (exact label may vary by plugin version). 3. Enter your full white-label domain including the subdomain, for example: dashboard.hearingassetadvisors.com. 4. Save the settings. 5. Return to the UUID field, re-paste your UUID, and save again. 6. Reload the page and check whether the validation error has cleared. If your plugin version does not show a Dashboard Domain field, proceed to Step 3. 🔗 Step 3 — Enable Metasync in the Plugin Metasync is the background sync feature that links your WordPress site to the Search Atlas platform. It must be active for UUID validation to work under a white-label domain. 1. In your WordPress admin panel, open Search Atlas → Settings in the sidebar. 2. Find the toggle labelled Metasync or Enable Metasync. 3. Switch it to On or Enabled. 4. Save your settings. 5. Wait up to two minutes, then reload the plugin settings page to confirm the UUID now shows as verified. 📋 Step 4 — Insert the Pixel Script Manually (Alternative Method) If the plugin-based UUID entry continues to show errors, you can bypass it entirely by inserting the full OTTO pixel script directly into your WordPress site's code. This method works regardless of white-label domain configuration. 1. Log in to your dashboard through your white-label domain. 2. Go to OTTO SEO → All Sites (SEO Automation) in the left sidebar. 3. Find the OTTO pixel section and click Copy Script or Get Pixel Code. This copies the complete <script> tag including your UUID already embedded inside it. 4. In your WordPress admin panel, go to Appearance → Theme File Editor, or install a plugin such as Insert Headers and Footers if you prefer not to edit theme files directly. 5. Paste the copied script into the <head> section of your site. If using Insert Headers and Footers, paste it in the Scripts in Header field. 6. Save the changes. 7. Visit your website, right-click the page, and select View Page Source. Search for your UUID to confirm the script is present in the page HTML. Once the script is live in your page source, the OTTO pixel is active. You do not need the plugin's UUID field to show a green checkmark for tracking to function when the script is inserted manually. 🌐 Does Your White-Label Domain Affect Pixel Tracking? Your white-label domain affects the validation step inside the plugin UI, but it does not change what the pixel collects or how OTTO processes your site data. Once the pixel script is live on your pages — whether via the plugin or manual insertion — all tracking and OTTO automation works exactly as it does for standard installations. The white-label domain is purely a branding layer for your dashboard access. 🛠️ Quick Troubleshooting Checklist - UUID copied with extra spaces? Re-copy using the copy icon, not manual selection. - Plugin Dashboard Domain field filled in? Enter your full white-label domain. - Metasync enabled? Toggle it on and save. - Plugin version outdated? Update the Search Atlas plugin to the latest version from the WordPress plugin repository. - Script inserted manually but UUID not in page source? Clear your caching plugin and CDN cache, then re-check. - Firewall or security plugin blocking the script? Whitelist the Search Atlas pixel domain in your security plugin settings. 💬 Need More Help? 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.

🛠️ Fix OTTO Pixel Not Installed on GoDaddy

🔍 Overview If your OTTO pixel shows as not installed after adding it to your GoDaddy website, the most common cause is an incorrect installation method or a misconfigured Google Tag Manager (GTM) setup. This article walks you through the correct process to get your pixel firing properly. ⚙️ Before You Begin Make sure you have the following ready before starting: - Access to your Search Atlas account (navigate to OTTO SEO via the left sidebar, then open SEO Automation, or go to /seo-automation-v3) - Admin access to your GoDaddy website - A published Google Tag Manager container connected to your GoDaddy site - Your OTTO pixel code snippet, copied directly from the OTTO dashboard 📋 Step 1 — Copy Your OTTO Pixel Code 1. Log in to Search Atlas and go to OTTO SEO in the left sidebar, then open SEO Automation. 2. Open the OTTO dashboard for the website you are setting up. 3. Locate the pixel installation section and copy the full pixel code snippet. Do not modify the code. 🏷️ Step 2 — Add the Pixel via Google Tag Manager Using GTM is the recommended method for installing the OTTO pixel on GoDaddy websites, as GoDaddy's native editor has limited support for custom scripts. 1. Log in to Google Tag Manager and select the container linked to your GoDaddy site. 2. Click Tags in the left menu, then click New. 3. Click Tag Configuration and choose Custom HTML as the tag type. 4. Paste your OTTO pixel code into the HTML field. Ensure the full snippet is included — do not wrap it in any additional tags. 5. Click Triggering and select All Pages so the pixel fires on every page load. 6. Name your tag (for example, OTTO Pixel) and click Save. 7. Click Submit in the top-right corner of GTM, add a version name, and click Publish. 🌐 Step 3 — Confirm GTM Is Active on Your GoDaddy Site The OTTO pixel will only fire if GTM itself is correctly installed on your GoDaddy site. Follow these steps to verify: 1. Log in to your GoDaddy account and open your website builder or WordPress admin panel. 2. Confirm your GTM container snippet (both the <head> and <body> portions) is present in your site's code. In GoDaddy Managed WordPress, use a plugin such as GTM4WP to insert both snippets correctly. 3. Visit your live website and use the Google Tag Assistant browser extension or GTM's built-in Preview mode to confirm the GTM container is loading on every page. ✅ Step 4 — Verify the OTTO Pixel Is Detected 1. Return to the OTTO dashboard in Search Atlas (OTTO SEO in the left sidebar → SEO Automation → your website). 2. Click the Check Installation or Verify Pixel button. 3. Allow up to 5 minutes after publishing your GTM container before checking, as propagation can take a short time. 4. If the pixel status changes to Installed, your setup is complete. ⚠️ Common Reasons the Pixel Shows as Not Installed - GTM container not published: Saving a tag in GTM is not enough — you must also click Submit and Publish to push changes live. - Incomplete GTM snippet on GoDaddy: Both the <head> and <body> GTM code snippets must be present. Missing the body snippet is a frequent cause of failures. - Wrong trigger set: If the trigger is not set to All Pages, the pixel may not fire on the page OTTO checks. - Modified pixel code: Any changes to the original OTTO pixel snippet can break detection. Always paste the code exactly as provided. - Caching: GoDaddy or a caching plugin may serve a cached version of your site. Clear all caches after publishing your GTM container. - Ad blocker or browser extension interference: Test verification in an incognito window with extensions disabled. 💡 Tips for GoDaddy Managed WordPress If your GoDaddy site runs on Managed WordPress, the easiest way to install GTM (and therefore the OTTO pixel) is to use the GTM4WP plugin. Once installed and configured with your GTM container ID, the plugin automatically places both required snippets in the correct positions — no manual code editing needed. 🆘 Still Need Help? If you have followed all the steps above and the OTTO pixel still shows as not installed, 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.

🔍 Meta Descriptions Not Showing in WordPress

🧭 Overview If you have updated a meta description inside Search Atlas but do not see the change reflected in your WordPress backend editor, you are not alone. This is one of the most common questions our customers ask, and the good news is that it has a straightforward explanation. 💡 Why This Happens Search Atlas writes meta descriptions directly to your page's HTML output — the live, published version of your site — rather than to the WordPress database field that your theme or SEO plugin (such as Yoast SEO or Rank Math) displays inside the block editor or classic editor. As a result, the meta description field inside the WordPress backend may appear blank or still show the old value, even though your updated meta description is already live and visible to search engines. The two systems store this data independently, so a change in one place does not automatically update the other. ✅ How to Confirm Your Meta Description Is Live Before making any manual changes, verify that Search Atlas has successfully applied your meta description to the published page: 1. Open a new browser tab and navigate to the published URL of the page. 2. Right-click anywhere on the page and select View Page Source. 3. Use Ctrl + F (Windows) or Cmd + F (Mac) to search for meta name="description". 4. Check that the content value matches the meta description you set in Search Atlas. If your updated meta description appears in the page source, it is live and working correctly. Search engines read the page source, not the WordPress editor field. 🛠️ What to Do If You Want Both in Sync If it is important to you that the WordPress backend editor also reflects the meta description, you can manually copy the value from Search Atlas and paste it into the corresponding field in your WordPress SEO plugin. This keeps both systems aligned without affecting how the page performs in search. 1. In Search Atlas, go to Left sidebar → Content → On-Page Audit and open the relevant page. 2. Locate the meta description field and copy the text. 3. Log in to your WordPress backend and open the page or post editor. 4. Scroll to your SEO plugin section (e.g., Yoast SEO or Rank Math) and paste the meta description into the meta description field. 5. Save or update the page in WordPress. Note: Pasting the value into WordPress does not override what Search Atlas has already applied. The live output on your site is controlled by Search Atlas via the connected integration. ⚙️ How Search Atlas Applies Meta Data Search Atlas uses its WordPress plugin integration to inject optimised meta tags at the point of page rendering. This means the meta description is applied dynamically when the page loads, ensuring search engines always receive the most up-to-date value you have set inside Search Atlas. The WordPress editor simply does not have visibility into this layer, which is why the discrepancy appears. 🚫 Common Misconceptions - The change did not save: If you can see the updated value in your Search Atlas dashboard and it appears correctly in the page source, the change has saved and is working. - The old description will be shown to Google: Google reads the rendered page source. As long as the correct value is in the source, your updated meta description is what Google sees. - Clearing cache will fix the blank field in WordPress: Clearing your site cache can help with display issues on the front end, but it will not populate the meta description field inside the WordPress editor, as that field is separate from the Search Atlas integration. 📊 Where to Manage Meta Descriptions in Search Atlas You can create and edit meta descriptions from two locations inside Search Atlas: - Left sidebar → Content → On-Page Audit — audit and optimise meta descriptions for existing pages. - Left sidebar → Content → Meta Generator — generate bulk or individual meta descriptions using AI. 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.

🛠️ Fix OTTO Pixel Installation on BOKUN CMS

🔍 Overview If your OTTO pixel was previously connected to your BOKUN website but stopped working — or you have added the tracking code to your header and it still shows as inactive — this guide walks you through the correct reinstallation process. BOKUN has specific requirements for custom script injection that can cause the standard copy-paste approach to fail silently. ⚙️ Before You Begin Confirm the following before attempting a reinstall: - You have admin access to your BOKUN account. - You know which BOKUN website (if you manage more than one) needs the pixel. - Your Search Atlas account is active and you can reach the OTTO dashboard. - You have already removed or deactivated any previous version of the OTTO pixel code from BOKUN to avoid conflicts. 📋 Step 1 — Copy Your OTTO Pixel Code 1. Log in to Search Atlas. 2. In the left sidebar, navigate to OTTO SEO, then open SEO Automation inside it (URL: /seo-automation-v3). 3. Select the website associated with your BOKUN property. 4. Click Activate OTTO or open the OTTO settings for that site. 5. Locate the Pixel / Tracking Code section and click Copy Code. Keep this tab open — you will need it again in Step 3. 🖥️ Step 2 — Clear the Old Code from BOKUN 1. Log in to your BOKUN account and go to Website Builder. 2. Select your website, then open Settings (or Advanced Settings depending on your BOKUN plan). 3. Navigate to the Custom Code or Header Scripts section. 4. Delete all existing OTTO pixel snippets completely. Partial or duplicate code is a common reason the pixel never activates. 5. Save the changes before proceeding. 📥 Step 3 — Reinstall the OTTO Pixel Code in BOKUN 1. Still inside BOKUN's Custom Code / Header Scripts section, paste the fresh pixel code you copied in Step 1. 2. Make sure the code is placed inside the <head> tag area, not the body or footer — BOKUN sometimes labels this section differently depending on your theme. Look for labels such as Head HTML, Custom Head Code, or Tracking Scripts. 3. Save and publish your website. In BOKUN, changes to custom code do not take effect until the site is explicitly published. ✅ Step 4 — Verify Activation in Search Atlas 1. Return to Search Atlas, go to OTTO SEO in the left sidebar, and open SEO Automation inside it. 2. Open the OTTO settings for your website. 3. Wait up to 10 minutes, then refresh the page to check the pixel status. 4. The status indicator should change from Inactive to Active. If it does not, proceed to the troubleshooting section below. 🔧 Common Issues and Fixes - Pixel still shows Inactive after 10 minutes: Confirm the BOKUN site was fully published after you saved the code — draft mode will not fire the pixel. - Code added to the wrong section: BOKUN's website builder has separate code fields for individual pages and for the global site header. Make sure you used the global / site-wide header field, not a page-level field. - Caching delay: BOKUN may serve cached versions of your pages. Try opening your live website in an incognito browser window to bypass the cache, then recheck the status in Search Atlas. - Multiple BOKUN websites: If you manage more than one BOKUN site, verify you pasted the code into the correct website. Each BOKUN website must have its own unique OTTO pixel code. - Script blocked by a third-party app: Some BOKUN marketplace integrations or cookie-consent tools block custom scripts. Temporarily disable third-party scripts and test activation again. 💡 Tips to Prevent Future Disconnections - After major BOKUN theme updates, always verify that custom code sections were not reset to default. - Keep a backup copy of your OTTO pixel code saved in a secure document so you can quickly reinstall without revisiting Search Atlas. - Check OTTO pixel status periodically from the OTTO SEO V3 dashboard to catch any unexpected disconnections early. 🙋 Need More Help? If you have followed every step above and the pixel still will not activate, 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.

🔍 OTTO Pixel GTM Installation Not Showing Verified

🧩 Why This Happens GTM has two separate stages: preview/debug mode and live publishing. When you test a tag in GTM Preview, it only fires in your browser session. The tag is not active on your live website until you publish the container. Search Atlas checks your live site to confirm the OTTO pixel is present, so if the container has never been published after adding the tag, the platform will always report the pixel as not installed — even though GTM preview shows it firing correctly. This is the most common reason the OTTO pixel appears unverified after a GTM setup. It is unrelated to WordPress plugins or DNS configuration. ✅ Step 1 — Confirm the OTTO Pixel Tag Is Set Up Correctly in GTM Before publishing, verify the tag is configured properly inside your GTM workspace. 1. Log in to Google Tag Manager and open the workspace for the website you are connecting to Search Atlas. 2. Go to Tags in the left sidebar and locate your OTTO pixel tag. 3. Open the tag and confirm the pixel ID matches exactly what is shown inside Search Atlas. To find your pixel ID, go to Left sidebar → OTTO SEO → SEO Automation in Search Atlas, select your site, and follow the installation prompt. 4. Confirm the trigger is set to All Pages (or at minimum your target pages) so the pixel fires on every visit. 5. Save any changes if you made corrections. 📤 Step 2 — Publish the GTM Container This is the step most commonly missed. GTM Preview mode does not make your tag live. 1. In your GTM workspace, click the Submit button in the top-right corner. 2. On the submission screen, select Publish and Create Version. 3. Add an optional version name such as OTTO pixel added so you can identify this change later. 4. Click Publish to confirm. GTM will display a version summary when the publish is complete. Important: Do not close GTM or navigate away until you see the confirmation that the new version is live. If you leave the Submit screen without clicking Publish, the container will not update. 🔄 Step 3 — Trigger Verification in Search Atlas Once the GTM container is published, return to Search Atlas and ask the platform to re-check the pixel. 1. Go to Left sidebar → OTTO SEO → SEO Automation. 2. Find your site and click Continue installation if that option is shown, or open the site's installation status panel. 3. Click the button to re-verify or re-scan the pixel installation. Search Atlas will make a fresh request to your live site to detect the pixel. 4. Wait up to two minutes for the check to complete. If the pixel is firing correctly on your published site, the status will update to installed. 🛠️ Step 4 — If the Pixel Is Still Not Detected If Search Atlas still reports the pixel as not installed after publishing the GTM container, work through the following checks. - Clear any caching layers. If your site uses a caching plugin, a CDN such as Cloudflare, or server-side caching, purge the cache after publishing GTM. Cached pages may not include the updated GTM snippet. - Confirm the GTM snippet is on your site. Visit your website, right-click the page, and choose View Page Source. Search for your GTM container ID (format: GTM-XXXXXXX). If it is not present in the source, the GTM snippet itself has not been added to your site's HTML. The pixel tag inside GTM cannot fire without this base snippet. - Check for tag-blocking consent tools. If your site uses a cookie consent manager or tag-blocking solution, ensure the OTTO pixel tag is not being blocked by default before user consent is given. Search Atlas's verification crawler does not accept cookies, so a blocked tag will not be detected. - Verify the correct GTM workspace. If your GTM account contains multiple containers or workspaces, confirm you added the OTTO pixel tag to the container whose snippet is installed on the website registered in Search Atlas. ⚠️ This Is Not a WordPress Plugin or DNS Issue If you are using GTM to install the OTTO pixel, you do not need to install a separate WordPress plugin or make any DNS changes. Those methods apply to different installation paths. If you followed the GTM route and confirmed the tag fires in preview, the steps above are the correct troubleshooting path. Switching methods mid-setup can cause duplicate tags or configuration conflicts. 💬 Still Need Help? 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.

🛡️ Fix Cloudflare WAF Blocking WordPress Sync

🔍 What This Error Means When you try to publish or sync an article to your WordPress site, you may see a message such as "We're unable to sync with your WordPress site" or a status of cloudflare_blocked. This means your site is protected by Cloudflare, and its Web Application Firewall (WAF) is treating the request from Search Atlas as suspicious traffic. Cloudflare sits between your website and the internet. When our platform sends content to your WordPress REST API — specifically the Search Atlas SEO plugin's /wp-json/metasync/v1/ route — Cloudflare can mistakenly flag that automated request and stop it before it reaches your site. The result is a blocked sync, even though your login details and plugin are correct. A related symptom is an HTTP 525 ("SSL handshake failed") response from Cloudflare for this endpoint, which points to a Cloudflare-side connection problem rather than incorrect WordPress credentials. Note that cloudflare_blocked is distinct from a wp_client_error status, which indicates a different WordPress connection issue rather than a Cloudflare block. ⚙️ Why Cloudflare Blocks the Sync Cloudflare's firewall uses rules to filter out bots and automated tools. Publishing software like Search Atlas connects through the WordPress REST API, which can look like automated activity. Common reasons for a block include: - Managed WAF rules that flag requests to the /wp-json/ REST API endpoint. - Bot Fight Mode or Super Bot Fight Mode challenging non-browser traffic. - Rate limiting rules that block repeated requests in a short time. - Custom firewall rules created by your team or hosting provider. - Security plugins working alongside Cloudflare that add extra filtering. ✅ Before You Begin You will need access to your Cloudflare dashboard for the affected domain. If your site is managed by a hosting provider or developer, you may need to ask them to apply these changes. Always make one change at a time and re-test the sync so you know which fix worked. 🛠️ How to Allow the Sync in Cloudflare Follow these steps to let Search Atlas connect to your WordPress site: 1. Log in to your Cloudflare dashboard and select the domain you are trying to sync. 2. Go to Security, then WAF. 3. Open the Firewall rules or Custom rules tab. 4. Create a new rule that allows traffic to your REST API. Set the field to URI Path, the operator to contains, and the value to /wp-json/. The SearchAtlas plugin specifically uses the /wp-json/metasync/v1/ path, so you can target that route if you prefer a tighter, more specific rule. 5. Set the action for this rule to Skip or Allow, so these requests bypass the firewall. 6. Save and deploy the rule, then try the sync again from the Search Atlas platform. 🤖 Adjust Bot Protection Settings If the block continues, your bot protection may be the cause. In your Cloudflare dashboard: - Go to Security, then Bots. - Temporarily turn off Bot Fight Mode or Super Bot Fight Mode and test the sync. - If this resolves the issue, create an exception so legitimate requests to /wp-json/ are not challenged. You can also check Security, then Events, to see a log of blocked requests. This log helps you confirm which rule stopped the sync and lets you adjust the correct setting. 🌐 Allow Our Connection at the Server Level Some hosts apply security at the server level in addition to Cloudflare. If you still see a block after updating Cloudflare, ask your hosting provider to confirm that requests to the WordPress REST API are not being filtered, and that your SearchAtlas SEO plugin is active and up to date. 🔁 Re-Test the Sync After making your changes, return to the Search Atlas platform and try publishing again: 1. Open the article you want to publish. 2. Confirm your WordPress site is correctly connected in your integration settings. 3. Click Publish or Sync and wait for the confirmation message. If the sync succeeds, the block has been resolved. If it still fails, review your Cloudflare Events log again to identify any remaining rule that needs adjusting. 💡 Tips to Prevent Future Blocks - Keep your SearchAtlas SEO plugin updated to the latest version. Search Atlas sends sync requests using a WAF-aware user agent designed to reduce false blocks, so running the latest plugin version ensures you benefit from this behavior. - Avoid overly strict global firewall rules that apply to the entire site. - Document any custom rules you create so they are easy to review later. - Coordinate with your hosting provider before adding new security tools that may filter API traffic.

⚙️ OTTO JavaScript Warning During WordPress Plugin Installation

🤔 What Is OTTO JavaScript? OTTO is Search Atlas's OTTO SEO automation engine. When you activate OTTO for a website inside Search Atlas, it deploys a small JavaScript snippet to your site. This snippet allows OTTO to read your page structure and apply on-page SEO optimizations automatically — such as updating title tags, meta descriptions, schema markup, and more. So yes, OTTO JavaScript is supposed to be on your website once you have connected and activated OTTO for that site. Seeing it present is normal and expected behavior. ⚠️ Why Am I Seeing a JavaScript Conflict Warning? When you install the Search Atlas WordPress plugin, it scans your site and checks for existing OTTO JavaScript. A warning appears in one of two situations: - Duplicate snippet detected: The OTTO JavaScript has been added more than once — for example, once via the WordPress plugin and once manually via your theme or another plugin. - Snippet mismatch: An older or incorrect version of the OTTO JavaScript is present and does not match the version the plugin expects to manage. This warning does not mean OTTO is broken or that your site is at risk. It is an alert that the plugin found a conflict it needs you to resolve before it can manage the snippet cleanly. 🔍 How to Check the OTTO Status on Your Site 1. Log in to Search Atlas and go to OTTO SEO in the left sidebar, then open SEO Automation (or navigate to /seo-automation-v3). 2. Locate the website showing the conflict warning and open its OTTO settings. 3. Review the JavaScript Deployment section. It will show whether the snippet is active, inactive, or flagged as duplicated. 🛠️ How to Resolve the OTTO JavaScript Conflict Follow the steps below based on your situation. Option A — You installed OTTO only through the WordPress plugin (recommended setup) 1. In your WordPress admin, go to Search Atlas → Settings. 2. Confirm your Search Atlas API Key (or One-Click Authentication) and OTTO Pixel UUID are entered and saved. The plugin will handle the snippet automatically. 3. Remove any manually added OTTO JavaScript you may have added to your theme files (such as functions.php) or through a third-party plugin like Insert Headers and Footers. 4. Save your changes and revisit the OTTO SEO dashboard in Search Atlas to confirm the warning has cleared. Option B — You added OTTO JavaScript manually before installing the plugin 1. Locate where the script was manually placed. Common locations include your theme's functions.php, a header/footer injection plugin, or Google Tag Manager. 2. Remove the manually added snippet entirely. 3. Allow the Search Atlas WordPress plugin to manage the snippet going forward — it will re-inject the correct version automatically. 4. Clear your site's cache (including any hosting-level or CDN cache) after making changes. 5. Return to OTTO SEO in the left sidebar in Search Atlas, then open SEO Automation, and confirm the conflict warning is gone. Option C — You want to remove OTTO JavaScript entirely 1. In Search Atlas, go to OTTO SEO in the left sidebar, then open SEO Automation, and open the settings for your site. 2. Deactivate OTTO for that site. This will stop OTTO from managing the snippet. 3. In your WordPress admin, go to Search Atlas → Settings. If you want OTTO turned off while you're logged in so you can edit original content, enable the Disable OTTO for Logged in Users checkbox. 4. If you previously added the snippet manually anywhere, remove those instances as well. 5. Clear your site cache to ensure the snippet is fully removed from all pages. ✅ Best Practices to Avoid Future Conflicts - Always manage the OTTO JavaScript through one method only — the Search Atlas WordPress plugin is the recommended approach for WordPress sites. - Do not add the OTTO snippet manually if the WordPress plugin is installed and active. - After any change, clear your site cache before rechecking the status in Search Atlas. - If you use a caching plugin such as WP Rocket, W3 Total Cache, or a CDN like Cloudflare, clear those caches too — a cached page may still show the old snippet. ❓ Frequently Asked Questions Does removing the OTTO JavaScript hurt my SEO? If OTTO is actively managing optimizations on your site, deactivating it means those automated changes will no longer be applied. Any changes OTTO has already made to your content will remain in place. You will just need to manage those elements manually going forward. How do I know if OTTO is working correctly after resolving the conflict? Go to OTTO SEO in the left sidebar in Search Atlas, then open SEO Automation. If the conflict warning is no longer displayed and OTTO shows an active status, the snippet is deployed correctly and OTTO is functioning as expected. The warning is still showing after I made changes. What should I do? Make sure you have cleared all caches — including browser cache, WordPress caching plugins, and any CDN. Then reload the OTTO SEO dashboard. If the warning persists, the duplicate snippet may still exist somewhere on your site. Use your browser's View Page Source tool and search for otto to locate any remaining instances. 💬 Need More Help? 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.

🛠️ Fix WebSocket 403 Errors on MCP Bulk Send

🔍 Overview When using the Search Atlas AI Agent via the Model Context Protocol (MCP), calls to ws_bulk_send_message may return an HTTP 403 Forbidden error on the WebSocket channel. This article explains why this happens, how to confirm the root cause, and what steps to take to restore normal functionality. ⚠️ What Causes the 403 Error? An HTTP 403 (Forbidden) response on a WebSocket upgrade or message-send request means the server received your connection attempt but rejected it due to a missing, expired, or malformed JSON Web Token (JWT). Because ws_bulk_send_message relies on the same authenticated WebSocket channel used by Website Studio's MCP tools, a broken token blocks every bulk message call — even when the underlying message delivery actually succeeds on the server side. A 403 error on ws_bulk_send_message is almost always caused by one of the following: - Expired or invalid JWT token: The authentication token used to open the WebSocket connection has expired or was not issued correctly, causing the server to reject subsequent message calls. - MCP bulk sends disabled at the project level: In some cases, the ability to send bulk messages via MCP can be turned off for a specific project, either by a configuration change or a platform update. - Incorrect WebSocket endpoint: An older integration may be pointing to a deprecated REST endpoint instead of the correct WebSocket channel, resulting in auth failures. An earlier version of Website Studio's V2 integration attempted REST endpoint calls instead of routing traffic through the correct WebSocket channel, producing 403 and 404 responses. - False failure reporting: In some resolved cases, ws_bulk_send_message reported a 403 failure even though the message was delivered successfully. This was a known bug that has since been fixed. - create_project dependency: Because create_project and ws_bulk_send_message share the same authenticated session setup, a broken project-creation flow could leave the WebSocket channel in an unauthenticated state for all subsequent calls. Common symptoms include: - All ws_bulk_send_message calls return 403 immediately without queuing messages. - Website Studio editing tools (create_project, page edits) also fail or return errors when accessed via MCP. - The AI Agent log shows JWT auth errors alongside the 403 response. - Some messages appear delivered in the UI despite the 403 error in the API response — this is a known false-failure behaviour that has been patched. ✅ How to Confirm the Root Cause Before taking corrective action, follow these steps to identify exactly what is causing the error in your project: 1. Check your JWT token validity. Inspect the token being passed in your MCP connection headers. Tokens typically expire after a set period. If the token is expired, re-authenticate to generate a new one and re-establish the WebSocket connection. 2. Verify your WebSocket endpoint. Confirm that your integration is connecting to the correct WebSocket URL for the Search Atlas agent channel. If you see REST-style URLs (e.g., /api/v2/...) in your request logs, your integration may be misconfigured and needs to be updated to use the WebSocket endpoint. 3. Test with a fresh project. Create a new project and attempt a ws_bulk_send_message call. If the call succeeds on a new project but fails on the original one, the issue is likely tied to that specific project's configuration. 4. Check whether MCP sends are enabled. In your project settings, confirm that MCP-based messaging is active. If the option appears greyed out or unavailable, the feature may have been disabled for your account or project. Note that a true MCP-disabled state returns a configuration-level error message (such as "MCP tool not available" or "feature disabled") indicating the feature is turned off — it does not return an HTTP 403. If you are receiving a 403 specifically, MCP messaging is enabled but the request is being rejected at the authentication layer. 5. Review recent platform updates. If the error appeared suddenly without any changes on your end, it may be related to a recent platform update. Check the Search Atlas changelog or status page for any relevant notices. 🔧 Steps to Restore ws_bulk_send_message Once you have identified the cause, use the appropriate fix below: - Expired JWT token: Re-authenticate your MCP client using your Search Atlas credentials to obtain a fresh JWT token. In Search Atlas, go to Avatar Menu (👤) → Settings → API Keys and regenerate your API key. Copy the new key and update it in your MCP client configuration. Restart your AI Agent or MCP client to force a fresh WebSocket handshake with the new JWT. Do not reuse a cached session token from before a fix was deployed. Update your WebSocket connection to use the new token before retrying ws_bulk_send_message. - Wrong endpoint: Update your integration to point to the correct WebSocket channel. Remove any references to legacy REST endpoints. Contact support via the chat widget if you need the current endpoint details for your account. - Project-level configuration issue: If a specific project appears to have MCP messaging disabled or misconfigured, try removing and re-adding the project connection within the AI Agent settings. This resets the channel configuration. Also confirm that the target project was created successfully by opening Website Studio and verifying it exists. If create_project previously failed silently, the project may be missing, which will cause all subsequent ws_bulk_send_message calls to 403 because there is no valid channel to attach to. Re-run create_project if needed. - False failure on successful delivery: If your messages are actually being delivered despite the 403 error appearing in your logs, this was a known reporting bug that has been resolved in recent platform updates. Ensure your platform is on the latest version and verify message delivery directly in Website Studio before assuming a failure occurred. If you retried sends during the false-failure window, your project may contain duplicate content — review the affected pages in Website Studio and remove any duplicates manually. - Test with a single message first. Before running a bulk send, call ws_bulk_send_message with a single small payload to confirm the channel is authenticated and returning 200. 🚫 How to Confirm if MCP Sends Are Disabled To check whether MCP bulk messaging has been disabled for your project: 1. Click Atlas Agent in the header (e.g., 'Launch Atlas Agent' on Home). 2. Navigate to the project in question and open its MCP Channel Settings. 3. Look for a toggle or status indicator labelled Bulk Messaging or MCP Sends. If it is off, enable it and save your changes. 4. Retry the ws_bulk_send_message call to confirm the error is resolved. If the toggle is not visible or cannot be enabled, the feature may require reactivation at the account level by a member of our team. If you see a message such as "MCP tool not available" or "feature disabled", contact support to confirm your plan includes MCP access. 💡 Prevention Tips - Always handle JWT token expiry gracefully in your MCP integration by implementing automatic re-authentication before the token expires. - Log both the HTTP status code and the actual delivery outcome separately so you can distinguish between true failures and false reporting errors. - After any Search Atlas platform update, do a quick test call on your most active projects to confirm WebSocket connectivity is intact. - After any bulk send retry cycle, review affected pages in Website Studio to check for duplicate content that may have been created during a false-failure window. 🙋 Still Need Help? If you have followed the steps above and are still experiencing 403 errors on ws_bulk_send_message, our team can review your account's WebSocket logs directly. To reach us, open the chat widget in the bottom-right corner of the platform and type human teammate.

🔌 Fix WordPress Plugin Sync & Pixel Errors

🔍 Understanding the Sync Status Discrepancy It can be confusing when your WordPress dashboard shows the Search Atlas plugin as active and synced, yet the OTTO SEO panel reports it as not installed correctly. These two status indicators pull data from different sources, so they can fall out of sync. The WordPress side confirms the plugin is installed and running on your server, while OTTO verifies a live, authenticated connection to your specific website property inside Search Atlas. The most common causes of this mismatch are: - The plugin was installed on the wrong WordPress site (e.g., a staging or subdomain URL that does not match your OTTO website property) - The Search Atlas pixel or API key inside the plugin settings was not saved correctly - A caching layer or security plugin is blocking the pixel verification request - The plugin was updated or reactivated after the initial connection, resetting the authentication token - Your website's server returned an error during OTTO's last verification check ✅ Step-by-Step: Verify Your Plugin Configuration 1. Confirm the correct website URL. In Search Atlas, go to your OTTO dashboard and note the exact domain associated with your website property (including or excluding www must match precisely). 2. Check the plugin is active on that domain. Log into the WordPress admin for that specific domain. Go to Plugins and confirm the Search Atlas plugin status shows Active. 3. Re-enter your API key. Inside WordPress, navigate to Search Atlas → Settings. Copy your API key fresh from your Search Atlas account settings and paste it into the plugin field. Click Save Changes. 4. Trigger a manual re-sync. After saving, look for a Sync Now or Verify Connection button within the plugin settings and click it. Wait 30–60 seconds for the handshake to complete. 5. Return to OTTO and refresh. Go back to your OTTO SEO dashboard in Search Atlas, refresh the page, and check whether the installation status has updated to Connected. 🛡️ Resolve Caching & Security Plugin Conflicts Security plugins such as Wordfence or iThemes Security, and caching plugins such as WP Rocket or W3 Total Cache, can sometimes block the outbound pixel request or serve a cached version of your site that does not include the Search Atlas pixel. Try the following: - Clear all site caches — purge server cache, CDN cache (e.g., Cloudflare), and any WordPress caching plugin cache. - Temporarily whitelist Search Atlas — in your security plugin, add Search Atlas domains to your allowlist, then re-run the sync. - Disable then re-enable the plugin — deactivate the Search Atlas plugin in WordPress, save, then reactivate it. This forces the pixel script to be re-injected into your page templates. - Check for JavaScript errors — open your website in a browser, right-click and select Inspect → Console, and look for any script-blocking errors related to the Search Atlas pixel. 🔑 Locate Your API Key in Search Atlas If you are unsure where to find your API key, follow these steps: 1. Log into your Search Atlas account. 2. Click your Avatar Menu (👤) in the top-right corner and select Account Settings. 3. Navigate to the Integrations or API Keys tab. 4. Copy the key and paste it into the Search Atlas WordPress plugin settings as described above. Important: Each website property in Search Atlas may use a unique key. Make sure you copy the key associated with the exact domain you are configuring — do not reuse a key from a different property. 🔄 When to Re-install the Plugin If the steps above do not resolve the issue, a clean re-installation often clears any corrupted configuration data: 1. In WordPress, go to Plugins → Installed Plugins, deactivate the Search Atlas plugin, then click Delete. 2. Go to Plugins → Add New → Upload Plugin, upload the Search Atlas plugin .zip file provided by Search Atlas, and install it. 3. Activate the plugin and immediately enter your API key in Search Atlas → Settings before navigating away. 4. Save your settings, trigger the sync, and verify the connection status in OTTO. 💡 Tips to Keep Your Plugin Synced - Avoid installing the plugin on staging environments using the same API key as your live site — this can cause verification conflicts. - After any WordPress core update or theme change, revisit the plugin settings to confirm the pixel is still rendering on your pages. - If you migrate your site to a new host or domain, disconnect the old property in Search Atlas and create a new one with the updated URL before re-syncing. 🙋 Still Seeing a Sync Error? If you have followed every step above and your plugin still shows as not installed correctly in OTTO, our team can investigate the server-level handshake logs on your behalf. 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.

💳 Fix Double Billing and Shopify Publishing Failures

🔍 Overview Some customers have experienced two separate charges within a short period — one through Shopify and one directly to a credit card — alongside content quota being consumed unexpectedly and generated articles or schemas failing to publish to their Shopify blog. This article explains why these issues occur, what has been fixed, and the exact steps to take to get your account and billing corrected. 💳 Why You May Have Been Charged Twice A technical issue caused Shopify app purchases to charge merchants successfully but fail to provision access inside Search Atlas. Because the system did not recognise the Shopify payment as complete, some accounts were charged a second time through a direct credit card transaction to restore access. This happened because: - The Shopify billing confirmation was routed to an internal system address instead of completing the provisioning step. - Subscription cancellations triggered from within Search Atlas could not reach Shopify subscriptions, leaving orphaned charges that were not reconciled automatically. - Webhook events for unrecognised or orphaned Shopify subscriptions were ignored rather than flagged, so duplicate charges went undetected. These routing and reconciliation issues have since been resolved. If you were affected, your account is eligible for a full refund of the duplicate charge. 📊 Why Your Quota Was Consumed Again When access provisioning failed after a Shopify charge, some accounts were reset or re-onboarded when the second charge processed. This reset caused previously used quota to be counted again as new usage during the republishing process, effectively double-counting consumption. If you republished content specifically to regain access or to test whether your account was working correctly after a billing problem, that quota usage is considered part of the same billing incident and is also eligible for reversal. Document which content was republished and flag it when you contact support. 🛠️ Why Articles and Schemas Won't Post to Your Shopify Blog Publishing failures to Shopify blogs are connected to the same provisioning problem. If your subscription was not correctly recognised by Search Atlas after a Shopify charge, the platform's connection to your Shopify store may have been left in an incomplete state. This can cause: - Generated articles to queue but never post to your Shopify blog. - Schema markup to save inside Search Atlas but not appear on your live store pages. - Repeated publish attempts to consume quota without successfully delivering content. Re-authenticating your Shopify connection after your subscription is correctly provisioned resolves most publishing failures. ✅ Steps to Resolve Your Issue 1. Gather your billing evidence. Collect screenshots or statements showing both charges — the Shopify transaction and the direct card charge — including dates and amounts. 2. Note any republished content. List the articles or schemas you republished during the affected period so quota reversals can be applied accurately. 3. Contact support via live chat. 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. Share your billing evidence and content list directly in the chat. 4. Confirm your subscription status. Ask the support agent to verify that your Shopify subscription is correctly provisioned and that no duplicate or orphaned subscription remains active on your account. 5. Re-authenticate your Shopify connection. Once your subscription is confirmed, go to Avatar (top-right corner) → Settings → CMS Connectors → [Your CMS] → Shopify → Reconnect and reconnect your store. This refreshes the publishing connection and resolves most post-to-blog failures. 6. Test publishing. After reconnecting, attempt to publish one article or schema to your Shopify blog to confirm the integration is working before republishing in bulk. 💡 What to Expect After Contacting Support - Duplicate charge refund: The refund for the duplicate charge will be processed back to the original payment method. Timing depends on your bank or Shopify's billing cycle, but you will receive confirmation once the refund is initiated. - Quota reversal: Any quota consumed as a direct result of the billing incident — including republishing attempts made to restore access — will be reviewed and credited back to your account. - Subscription clean-up: Support will ensure only one active subscription exists on your account and that it is correctly linked to your access level. 🚀 Preventing This in the Future - If you ever lose access to Search Atlas after a Shopify payment, contact support before making any additional payment or republishing content. - Check your Avatar (top-right corner) → Billing page (Plans & Top-ups) to confirm your subscription status before assuming a charge has failed. - After any reconnection or subscription change, always test the Shopify publishing integration with a single piece of content before running bulk publish jobs. 🆘 Still Need Help? 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.

🛠️ Fix OTTO Pixel Blocked by Wordfence

🔍 What Is Happening? When Wordfence Security is active on your WordPress site, it can silently block the OTTO pixel script from loading — even if your Search Atlas account is authenticated and synced successfully. This causes the OTTO activation panel to display an "OTTO not found" error, because Wordfence intercepts the pixel request before it reaches your site. This is one of the most common reasons OTTO appears connected in Search Atlas but remains undetected on your website. ⚙️ Before You Begin Confirm the following before making any changes to Wordfence: - You are logged in to your WordPress admin dashboard with administrator access. - The Wordfence Security plugin is installed and active. - In Search Atlas, your site shows a successful account authentication and sync status under SEO Automation (Left sidebar → OTTO SEO → SEO Automation). - The OTTO status still reads "OTTO not found" despite the successful sync. 🛠️ How to Whitelist the OTTO Pixel in Wordfence Follow these steps to allow the OTTO pixel through Wordfence's firewall: 1. Log in to your WordPress Admin Dashboard. 2. In the left sidebar, click Wordfence, then select Firewall. 3. Click the Allowlisted URLs tab (sometimes labelled Whitelisted URLs depending on your Wordfence version). 4. Click Add URL to Allowlist. 5. In the URL field, enter the OTTO pixel endpoint. Use the exact URL provided in your Search Atlas OTTO installation instructions. It typically follows the pattern: yourdomain.com/?otto_pixel=1 — copy it directly from the Search Atlas platform to avoid typos. 6. Leave the Parameter fields blank unless Wordfence specifically prompts you to add one. 7. Click Save. After saving, Wordfence will stop blocking requests matching that URL pattern. ✅ Verify the Pixel Is Now Detected 1. Return to Search Atlas and navigate to OTTO SEO in the left sidebar, then open SEO Automation. 2. Locate your site and open the OTTO activation panel. 3. Click Re-check or Refresh Status to trigger a new pixel detection scan. 4. The status should update from "OTTO not found" to "OTTO Active" within a few seconds. If the status does not update immediately, wait two to three minutes and refresh the page. Detection can occasionally take a short time after the allowlist rule is saved. 💡 Additional Wordfence Settings to Check If whitelisting the URL alone does not resolve the issue, check these additional Wordfence settings: - Web Application Firewall (WAF) rules: Wordfence's WAF may have a rule blocking inline scripts. Under Wordfence → Firewall → All Firewall Options, temporarily set the WAF to Learning Mode, trigger the OTTO pixel, then review the blocked requests log to identify and allowlist the specific rule. - Brute Force Protection: If your site limits external requests aggressively, check Wordfence → Login Security and confirm that OTTO's server IP range is not blocked. Search Atlas uses fixed outbound IPs — contact support (see below) if you need the current IP list. - Live Traffic blocking: Go to Wordfence → Tools → Live Traffic and filter by Blocked to see if OTTO pixel requests appear. If they do, click the request and choose Allowlist this IP or Allowlist this URL. 🚫 Common Mistakes to Avoid - Do not deactivate Wordfence entirely as a test — this exposes your site to security risks and is unnecessary. - Do not confuse authentication errors with pixel errors. A successful sync in Search Atlas means your API credentials are correct, but it does not confirm the pixel script is loading on your front end. - Copy the pixel URL exactly from the Search Atlas platform. A single character difference will prevent the allowlist rule from matching. 💬 Still Seeing 'OTTO Not Found'? If you have followed all the steps above and the error persists, your hosting provider or a secondary security plugin (such as Sucuri, iThemes Security, or Cloudflare WAF) may also be blocking the pixel. 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.

🔧 Fix OTTO Pixel Installation on GoDaddy with GTM

🧭 Overview When you add the OTTO pixel to a GoDaddy website through Google Tag Manager (GTM), the pixel may still show as Not Installed inside Search Atlas. This happens because GoDaddy's website builder loads GTM inside an iframe, which isolates the pixel from the top-level page that OTTO monitors. This article explains why this occurs and walks you through the correct fix. ⚠️ Why GoDaddy's GTM Integration Causes This Problem GoDaddy's built-in Google Tag Manager connection injects the GTM container inside an iframe rather than directly into the <head> of your page. OTTO's pixel verification checks the top-level document, so a pixel that fires only inside an iframe is invisible to the status checker and will always appear as not installed. This is a GoDaddy platform limitation, not a bug in OTTO or GTM. The solution is to place the OTTO pixel script directly in your page's HTML, bypassing the iframe entirely. 📋 Before You Start - You are logged in to your GoDaddy account and have access to the website editor. - You have access to the OTTO or OTTO SEO section in Search Atlas where your pixel snippet is available. - You have your unique OTTO pixel snippet copied and ready (see the step below). 📎 Step 1 — Copy Your OTTO Pixel Snippet 1. In Search Atlas, navigate to the section where your OTTO pixel code is provided for your project. 2. Select the project connected to your GoDaddy website. 3. Locate your pixel snippet and copy it to your clipboard or a text editor — you will paste it shortly. 🛠️ Step 2 — Add the Pixel Directly to Your GoDaddy HTML Because GTM runs inside an iframe on GoDaddy, you must inject the pixel script directly into the page HTML. The exact location of the custom code option varies by GoDaddy plan, but generally you should look for a way to add custom code or header code to your site's settings: 1. Open the GoDaddy Website Builder and enter the editor for your site. 2. Look in your site settings for an option that allows you to add custom code or scripts to the header of your pages. 3. Paste your OTTO pixel snippet into that field so it loads in the <head> of every page. 4. Save and publish your changes. Important: If your GoDaddy plan does not provide a header code field, check whether GoDaddy offers an HTML element or custom section block inside the page editor, and place the pixel snippet as close to the top of the page as possible. 🚫 Avoiding Duplicate Pixel Detection If you previously attempted to install the pixel through GoDaddy's built-in GTM connection and you are now adding it directly to the HTML, you must remove one of the two installations to avoid duplicate pixel detection. Keep only the direct HTML installation, as this is the one that OTTO can reliably verify. ✅ Step 3 — Verify the Pixel Is Detected After saving and publishing, return to Search Atlas and check the pixel status for your project. It may take a few minutes for the status to update. If the pixel now shows as installed, the direct HTML method has worked correctly. 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.

🔌 Fix WordPress Plugin Authentication Errors

🔍 Overview If your Search Atlas WordPress plugin is showing an authentication error, a login screen after a successful sync, or an API key verification failure, this guide walks you through the most common causes and fixes. Follow the steps in order before reaching out to support. ⚠️ Common Symptoms - Authentication failed or timed out after authorizing the plugin - The plugin dashboard shows a login page even though sync completed successfully - The error message: "The API key could not be verified" - A 500 error appears in the API key authentication popup 🛠️ Step 1 — Regenerate Your API Key An expired or invalid API key is the most frequent cause of authentication failures. To generate a fresh key: 1. Log in to your Search Atlas account. 2. Navigate to Settings → API Keys. 3. Click Generate New Key and copy the key immediately — it will not be shown again. 4. In your WordPress admin panel, go to Search Atlas → Settings. 5. Paste the new API key and click Save. Important: If you previously had an old key saved in the plugin, make sure to fully replace it rather than appending to it. 🔄 Step 2 — Re-Authorize the Plugin Sometimes the plugin loses its connection after a timeout or a platform update. Manually re-authorizing resets the session: 1. In your WordPress admin panel, go to Search Atlas → Settings. 2. Click Disconnect or Log Out if the option is available. 3. Clear any cached credentials by deactivating the plugin, then reactivating it from the Plugins page. 4. Re-enter your API key and complete the authorization flow. 🌐 Step 3 — Check for Server or Hosting Conflicts Some hosting environments block outbound API requests or enforce aggressive caching, which can interrupt authentication. Try the following: - Disable caching plugins temporarily (e.g., WP Rocket, W3 Total Cache) and attempt authentication again. - Check your firewall or WAF rules — ensure requests to Search Atlas API endpoints are not blocked. Ask your hosting provider if outbound HTTPS calls are restricted. - Confirm your PHP version is 7.4 or higher, as older versions can cause unexpected failures during API handshakes. - Increase PHP timeout limits if your server has a very low execution time setting (under 30 seconds). The authentication handshake may time out before completing. 🔁 Step 4 — Update or Reinstall the Plugin Running an outdated version of the Search Atlas plugin can cause compatibility issues with the current API. To update: 1. In your WordPress admin panel, go to Plugins → Installed Plugins. 2. Check if an update is available for Search Atlas and click Update Now. 3. If no update is available but issues persist, deactivate and delete the plugin, then reinstall the latest version from your Search Atlas account or the WordPress plugin directory. 4. After reinstalling, re-enter your API key and re-authorize. 🖥️ Step 5 — Clear Browser and WordPress Cache A cached login state can cause the plugin dashboard to show a login page even after a successful sync. This is a display issue, not an authentication failure: - Clear your browser cache and cookies, then reload the WordPress admin panel. - If you use a caching plugin, purge all cached pages. - Try opening the plugin in a private or incognito browser window to rule out session conflicts. ✅ When Everything Looks Correct but Still Fails If you have completed all the steps above and authentication still fails — especially if a 500 error appears in the authentication popup or regenerating the API key does not resolve the issue — this may indicate a platform-side bug that requires investigation by our engineering team. 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. When you reach out, please share the following to speed up the resolution: - Your Search Atlas account email - The exact error message or screenshot - Your WordPress version and PHP version - Your hosting provider name - Steps you have already tried from this guide

🔌 Troubleshooting CMS Connector Status Mismatch

This article addresses a specific issue where Search Atlas reports that your CMS connector is not connected, but when you check your connector settings, the connection appears active and healthy. This contradiction is a known status sync issue. Because the root cause occurs at the platform level, it cannot be fixed by reconnecting or refreshing from your end alone — the steps below will help you first confirm whether this is actually a status sync issue (versus a misconfiguration), and then prepare everything needed for a fast resolution if escalation is required. 🔍 What This Issue Looks Like - Search Atlas displays a disconnected or error status for your CMS connector. - Your CMS connector settings show the connection as active and healthy. - The mismatch persists even after navigating away and returning to the affected project. 🧭 Triage First: Is This a Status Sync Issue or a Misconfiguration? Before escalating, work through the following questions to determine whether this is the known sync issue or something that can be resolved without support: 1. Which CMS are you connecting? Note the CMS name and the integration method (e.g., API key, OAuth). Confirm that the integration type is still supported and that your credentials have not recently expired or been rotated. 2. Does the disconnected status affect all of your projects, or only one specific project? If it affects only one project, check whether that project's connector was recently re-saved, duplicated, or edited — a partial save can sometimes create a false-disconnected state that resolves on its own after a few minutes. 3. Were any changes made recently? For example: a password or API key reset in your CMS, a workspace transfer, a plan change in Search Atlas, or any third-party access revocation. If so, try removing and re-adding the connector in the affected project only if the issue started immediately after that change — this may be a simple re-auth rather than a sync bug. 4. Has the status been inconsistent for more than 30 minutes without any changes on your end? If yes, and the connector settings clearly show the connection as active, this is the pattern consistent with the platform-level sync issue described in this article. 🛠️ If You Have Confirmed This Is the Sync Issue: What to Prepare 1. Open your CMS connector settings and take a screenshot showing the current connected status, including any last-sync timestamp or confirmation message displayed there. 2. Note the exact project or site within Search Atlas that is showing the disconnected warning — record its name exactly as it appears in the platform. 3. Note the approximate time you first noticed the mismatch, including your timezone. 4. Do not reconnect or revoke the connector before contacting support — doing so can make the issue harder for the team to diagnose. 5. Reach out to support (see below) with your screenshot, project name, and the timestamp of when the issue first appeared. The support team will investigate the status sync on the platform side and resolve it for you. ✅ How to Confirm It Is Resolved Once the support team has addressed the underlying sync issue, the status indicator for your CMS connector should update to show a consistent Connected state in Search Atlas. You can also confirm the fix is effective by verifying that your content or data is actively syncing and that the disconnected warning no longer appears when you navigate to the affected project. 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.

🔧 Troubleshooting Cloudflare Token Paste Errors in Search Atlas

This article helps you resolve the error that appears when you paste a Cloudflare API token into Search Atlas. The error is almost always caused by one of a few specific token configuration issues — this guide walks you through each one so you can identify and fix the exact cause. 🔍 Common Causes - Incorrect token permissions: The token was created without the required permissions for Search Atlas to connect. - Token scope too narrow: The token is scoped to a specific zone (domain) but Search Atlas requires access to all zones, or vice versa. - Extra whitespace: Copying the token from Cloudflare sometimes includes a leading or trailing space, which causes the validation to fail silently. - Token was created as a Global API Key instead of an API Token: Search Atlas requires an API Token, not the Global API Key. - Token has been revoked or expired: A previously working token may have been deleted or expired in Cloudflare. 🛠️ Step-by-Step 1. Log in to your Cloudflare dashboard at dash.cloudflare.com and go to My Profile → API Tokens. 2. Verify you are using an API Token, not the Global API Key. The Global API Key will not work. If you used the Global API Key, you must create a new API Token instead. 3. Check the token's permissions. The token must include at minimum: Zone → DNS → Edit and Zone → Zone → Read. Read-only DNS access is not enough because OTTO writes DNS settings (it enables DNS proxy on DNS-only records). If these permissions are missing, click Edit on the token, add the missing permissions, and save. 4. Check the token's Zone Resources scope. Set it to All zones unless Search Atlas documentation specifies a single-zone scope. Mismatched scope is a frequent cause of this error. 5. Regenerate the token if you are unsure of its current state. In Cloudflare, click Roll (or delete and recreate it) to get a fresh token value. 6. Copy the new token carefully. Click the copy icon in Cloudflare rather than selecting the text manually. This reduces the risk of copying extra whitespace characters. 7. Paste the token into Search Atlas by opening your project settings and navigating to the Cloudflare integration field. Before saving, click inside the field and press Ctrl+A (or Cmd+A on Mac) to select all, then paste — this replaces any previous value fully rather than appending. 8. Save the token and wait for the connection validation to complete. ✅ How to Confirm It Worked After saving, Search Atlas will attempt to validate the token immediately. You will know the connection succeeded when: - The error message disappears and is replaced by a green success indicator or a confirmation message such as "Token connected" or "Cloudflare connected successfully." - Your Cloudflare zones or domain data become visible within the integration area — if zones were not populating before, they should now appear in a dropdown or list. - No red error banner is shown after saving. If the red error persists even after following all steps, the token value itself is the issue — return to Cloudflare and create a brand-new token from scratch rather than reusing the same one. 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.

🛠️ Fix Shopify Logo Corruption After Pixel Install

🔍 Overview Some Shopify store owners notice their logo appears distorted — with scrambled or corrupted characters — shortly after installing the Search Atlas tracking pixel. This article explains what causes the issue and walks you through the steps to resolve it quickly. ⚙️ What Is Causing the Logo Corruption? The Search Atlas pixel itself does not modify your store's images or logo files. However, the pixel installation process involves editing your Shopify theme code, typically the theme.liquid file. If a character encoding conflict or a copy-paste error occurs during that edit, it can corrupt nearby HTML or asset references — which may cause your logo to render incorrectly. Common root causes include: - A hidden encoding character (such as a non-breaking space or a Unicode artifact) introduced when pasting the pixel code into the theme editor - The pixel snippet accidentally placed inside an existing HTML tag or asset attribute, breaking the surrounding markup - A Shopify theme that uses a custom font or SVG logo that is sensitive to unexpected characters in the theme.liquid head section 🚀 How to Fix the Issue 1. Back up your current theme. In your Shopify Admin, go to Online Store → Themes, click the three-dot menu next to your live theme, and select Duplicate. This gives you a safe restore point. 2. Open the theme code editor. From the same Themes page, click Actions → Edit code on your live theme. 3. Locate the pixel snippet. Open theme.liquid and use your browser's Find function (Ctrl+F or Cmd+F) to search for the Search Atlas pixel code. It will typically appear in the <head> section. 4. Remove the existing pixel snippet. Carefully delete only the Search Atlas pixel code block. Do not remove any surrounding Shopify or theme code. Save the file and check your storefront — if the logo is restored, the snippet placement was the cause. 5. Re-add the pixel correctly. Copy the pixel code directly from Search Atlas (avoid reformatting tools or rich-text editors that may alter encoding). Paste it as the very last item inside the closing </head> tag, on its own line, ensuring it sits outside all other HTML tags. 6. Save and verify. Save the updated theme.liquid file and reload your Shopify storefront in a fresh browser tab. Confirm the logo displays correctly and the pixel is firing as expected. ✅ How to Confirm the Pixel Is Working After re-adding the snippet, verify the pixel is active without breaking your site layout: - Open your browser's developer tools (F12) and check the Console tab for any new JavaScript errors. - Use the Network tab to filter requests and confirm a call to the Search Atlas pixel domain is being made on page load. - Browse several pages of your store — including the homepage, a product page, and the cart — to confirm the logo and all visual elements remain intact. 🛡️ Prevention Tips - Always duplicate your theme before editing code, so you can roll back instantly if something goes wrong. - Paste pixel code using a plain-text editor (such as Notepad or TextEdit in plain-text mode) to strip any hidden formatting characters before adding it to your theme. - Place the pixel snippet just before the closing </head> tag rather than near any asset or image-related code. - Test on a duplicate theme first before pushing changes to your live store. 💬 Still Need Help? If you have followed the steps above and your logo is still displaying incorrectly, or if you are unsure where to place the pixel code in your specific theme, our team is ready to help. 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.

🔄 Update & Fix WordPress Plugin Sync

🔌 Updating the Search Atlas WordPress Plugin Keeping the plugin updated is the most important first step — many sync issues are resolved automatically once you're on the latest version. 1. Log in to your WordPress admin dashboard. 2. Navigate to Plugins → Installed Plugins. 3. Locate Search Atlas SEO or OTTO SEO in the list. 4. If an update is available, click Update Now. 5. Once complete, confirm the plugin displays the latest version number. 🛠️ Fixing WordPress Sync Issues If changes aren't syncing between Search Atlas and your WordPress site, work through the steps below in order. Many issues are resolved before reaching the final step. 1. Confirm the plugin is up to date — always verify you're running the latest version before troubleshooting further (see section above). 2. Re-authenticate the connection — in your WordPress admin, open the Search Atlas plugin settings and re-enter or refresh your API key to re-establish the connection between your site and Search Atlas. 3. Verify the OTTO pixel is installed and active — the OTTO pixel must be firing correctly on your site for deployments to render. Check that it hasn't been accidentally removed or blocked. 4. Clear all caches — stale cache layers are a common cause of sync delays. Clear each of the following: - Your WordPress caching plugin (e.g. WP Rocket, W3 Total Cache, LiteSpeed Cache) - Your CDN cache (e.g. Cloudflare, Fastly) - Your browser cache 5. Trigger a fresh re-sync — redeploy from Search Atlas and check the live page to confirm changes appear correctly. 6. Check for plugin conflicts — temporarily deactivate other SEO or caching plugins that may be overriding or interfering with Search Atlas changes, then test the sync again. ✅ Before Contacting Support If sync still fails after completing all steps above, please have the following information ready when you reach out — it will help our team resolve your issue faster: - Your domain URL - A clear description of what isn't syncing (e.g. meta tags, content changes, schema) - The plugin version currently installed - Any caching plugins or CDNs active on your site 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.

🔌 Fix GSC Integration 'No Properties Found' Errors

🧭 Overview Two error messages commonly appear when your Google Search Console (GSC) integration loses its connection or encounters an authentication issue inside Search Atlas: - "Your connected GSC Account doesn't have any project associated" - "No properties found for 1 account" Both errors mean Search Atlas cannot retrieve your GSC properties — usually because of a stale authentication token, a browser cache conflict, or a permission mismatch. Follow the steps below in order to resolve them quickly. ✅ Before You Start: Quick Checklist Confirm the following before troubleshooting the integration itself: - You are logged into the correct Google account — the one that owns or has full access to the GSC property you need. - That Google account has Owner or Full User permission on the GSC property (not Restricted). - The GSC property is verified and active in your Google Search Console dashboard at search.google.com/search-console. - You are using a supported browser (Google Chrome or Mozilla Firefox, latest version). 🔄 Step 1 — Disconnect Your GSC Account 1. Log in to Search Atlas and open Settings from the top-right corner (Avatar Menu (👤)). 2. Go to the Integrations section and locate your connected Google Search Console account. 3. Click Disconnect (or Remove) next to the account showing the error. 4. Wait for the confirmation message that the account has been removed before continuing. 🗑️ Step 2 — Clear Browser Cache and Cookies A stale browser cache is one of the most common hidden causes of GSC authentication errors. Clearing it ensures the reconnection starts from a clean state. 1. Open your browser settings and navigate to Privacy and Security. 2. Select Clear browsing data. 3. Set the time range to All time. 4. Check both Cached images and files and Cookies and other site data. 5. Click Clear data and wait for the process to finish. 6. Fully close and restart your browser before moving to the next step. 🔑 Step 3 — Revoke Search Atlas Access in Google Revoking the old permission token in Google ensures a completely fresh OAuth handshake when you reconnect. 1. Go to myaccount.google.com/permissions in your browser. 2. Find Search Atlas in the list of connected apps. 3. Click on it, then select Remove Access and confirm. 4. If Search Atlas does not appear in the list, proceed to Step 4 — no action is needed here. 🔗 Step 4 — Reconnect Your GSC Account 1. Return to Search Atlas and navigate to Site Metrics → Site Explorer → Manage Sites (page: /gsc/sites-list). 2. Click Connect GSC Account. 3. In the Google sign-in window that appears, select the correct Google account that has access to your GSC properties. 4. When prompted, click Allow to grant Search Atlas the required permissions. Make sure all permission checkboxes are selected before confirming. 5. After the redirect back to Search Atlas, wait 15–30 seconds for the properties to load. ✔️ Step 5 — Verify Properties Are Now Visible 1. Navigate to Site Metrics → Site Explorer → Open Google Search Console (Manage Sites/Connect GSC Account) in Search Atlas (page: GSC Accounts). 2. Confirm your properties are now listed on the GSC Accounts page. 3. Select the correct property and save your settings. 4. Trigger a data refresh or wait for the next scheduled sync to confirm data is flowing correctly. ⚠️ Still Seeing the Error? Additional Checks If the error persists after completing all five steps, review the following: - Multiple Google accounts open: Sign out of all Google accounts in your browser, then sign back in with only the account that owns the GSC property before reconnecting. - Domain property vs. URL-prefix property: Search Atlas supports both types, but ensure the property type in GSC matches how your site is configured. Check your GSC dashboard to confirm the property is verified. - GSC property has no data yet: Newly verified properties can take 24–48 hours before Google populates them with data. The integration may connect successfully but show empty reports until data is available. - Organisation-level restrictions: If your Google account is a Google Workspace account, your administrator may have restricted third-party app access. Contact your Google Workspace admin to whitelist Search Atlas. 💬 Need More Help? 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.

🛠️ Fix OTTO Pixel Detection and GHL Integration Pricing

🔍 Overview Two common questions arise when managing your OTTO SEO setup: why the OTTO pixel shows as not installed even after a successful installation, and how pricing differs between a GoHighLevel (GHL) integration and a direct Search Atlas plan. This article walks you through both topics step by step. ⚙️ Why the OTTO Pixel Shows 'Not Installed' After placing the OTTO pixel on your website, the platform may still display a not installed status. This is almost always caused by one of the following reasons: - The pixel code was added to only some pages rather than site-wide (e.g., in a footer or header that does not load on every page). - A caching layer — from your hosting provider, CDN, or a caching plugin — is serving an older version of the page that does not yet include the pixel. - The pixel was placed inside a conditional block or tag manager rule that prevents it from firing on every visit. - The verification check was run immediately after installation before the platform had time to detect it. 🛠️ How to Reinstall or Verify the OTTO Pixel 1. In the left sidebar, navigate to OTTO SEO and open SEO Automation (URL: /seo-automation-v3). 2. Locate your website and open its OTTO SEO dashboard. 3. Find the Pixel Installation section and click Get Pixel Code to copy the latest snippet. 4. Paste the snippet inside the <head> tag of your website's global template so it loads on every page — not just the homepage. 5. If you use a caching plugin (e.g., WP Rocket, W3 Total Cache) or a CDN (e.g., Cloudflare), purge all caches immediately after saving the change. 6. Return to the OTTO SEO dashboard and click Verify Installation. Wait up to five minutes for the status to update. 7. If the status still shows not installed after five minutes, open an incognito browser window, visit your website, then re-run the verification check. If you manage the site through a page builder (e.g., Elementor, Divi) or a third-party tag manager, make sure the pixel fires on all pages and is not limited to a specific trigger or audience rule. 💡 Common Installation Platforms — Quick Tips - WordPress: Use a header/footer plugin or paste the snippet directly into your theme's header.php file inside the <head> section. - Shopify: Add the pixel under Online Store → Themes → Edit Code → theme.liquid inside the <head> tag. - GoHighLevel (GHL) Sites: Go to your site settings in GHL, open the Tracking Code or Header Scripts field, and paste the pixel there. - Webflow / Wix / Squarespace: Use each platform's built-in custom code or header injection settings to add the snippet globally. 📊 GHL Integration Pricing vs. Direct Search Atlas Plan Search Atlas offers two ways to access the platform, and the pricing structure differs between them. - Direct Search Atlas Plan: You subscribe and pay Search Atlas directly. You have access to all plan features at the standard published rate and manage billing entirely within your Search Atlas account. - GHL (GoHighLevel) Integration: Access is provisioned through your GHL account or sub-account. Pricing for this integration is set at the GHL agency or marketplace level and may differ from the direct plan rates. Your Search Atlas subscription is tied to the GHL connection. Because GHL integration pricing is managed at the agency or reseller level, the exact rate depends on your specific GHL setup. For a precise quote or to compare costs for your account, please reach out via the chat widget so our team can review your configuration directly. 🔄 Will My Account Need to Be Disconnected or Reconnected? In most cases, switching between a GHL integration and a direct plan does not require disconnecting and reconnecting your account. However, there are scenarios where a reconnection step is needed: - If you are moving from a GHL sub-account to a standalone Search Atlas account (or vice versa), your billing source will change and a reconnection may be required. - If your GHL integration was set up under a different email or organisation than your direct plan, accounts may need to be merged or migrated by the support team. Before making any changes to your plan or integration, contact our team first so we can confirm the safest path and prevent any interruption to your OTTO SEO data or pixel tracking. 🚀 Still Need Help? 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.

🛠️ Fix OTTO Cloudflare Worker Validation Failures

🔍 Overview When connecting OTTO SEO to your site via Cloudflare, the diagnostics tool may show validation errors even when your API token permissions and worker routes appear to be set up correctly. This article walks you through the exact fixes a support agent used to resolve this, so you can self-serve without waiting for help. ⚠️ The Most Common Cause: Incorrect Zone-DNS Permission A frequent source of validation failure is a misconfigured Cloudflare API token permission. Specifically, the Zone - DNS permission must be set to Edit, not Read. To fix this in Cloudflare: 1. Log in to your Cloudflare dashboard. 2. Navigate to My Profile → API Tokens. 3. Find the API token you created for OTTO and click Edit. 4. Locate the Zone - DNS permission row. 5. Change the permission level from Read to Edit. 6. Save your changes. This single change resolves a large proportion of validation failures. After saving, move on to the next step. 🔄 Re-Engage the OTTO Worker After Fixing Permissions Once the API token is corrected, you must re-engage the OTTO worker inside the platform for the changes to take effect. Validation errors will persist if the worker is not refreshed after updating your Cloudflare credentials. 1. Go to Left sidebar → OTTO SEO → Overview in Search Atlas. 2. Use the Engage OTTO action available on that page to re-initiate the worker connection. 3. Allow a few moments for the process to complete, then re-run diagnostics to check whether the validation errors have cleared. In most cases, correcting the Zone-DNS permission to Edit and then re-engaging the worker will fully resolve the issue. 🚫 Excluding Click-Tracking from the Worker (If Applicable) If your setup involves click-tracking scripts or third-party analytics that conflict with the Cloudflare worker, you may need to configure an exclusion on the Cloudflare side. Your support agent can provide specific instructions tailored to your worker route configuration if this applies to your situation. 🐛 Known Issue: Diagnostics Tool May Still Show Errors After a Correct Setup In some cases, the OTTO diagnostics tool itself may report errors even when the worker is correctly installed and functioning. This is a known bug that has been escalated to the engineering team. If you have followed all the steps above and your site appears to be working correctly, the remaining diagnostic error may be a display issue rather than a real configuration problem. The engineering team is actively working on improvements to the diagnostics tool, including per-check results with detailed reason codes and version tracking for the Cloudflare worker. These updates will make it easier to pinpoint the exact cause of any failure in the future. ✅ Summary Checklist - Zone - DNS permission is set to Edit (not Read) in your Cloudflare API token. - Worker routes are correctly configured in Cloudflare for your domain. - OTTO worker has been re-engaged via Left sidebar → OTTO SEO → Overview after any credential changes. - Click-tracking exclusions are in place if your setup requires them. - If diagnostics still show an error but your site is functioning, this may be a known display bug — see the note above. 💬 Still Need Help? 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.

🔧 Fix OTTO Pixel Installation Across CMS Platforms

🧭 Overview The OTTO Pixel connects your website to Search Atlas so OTTO can monitor and automate SEO tasks. If your pixel shows as Not Installed or Duplicate Detected, this guide walks you through platform-specific considerations, UUID validation, and a verification checklist for multi-account setups. 🔑 Step 1: Retrieve Your Account-Specific Pixel Code Each Search Atlas account has a unique pixel tied to its UUID. Using the wrong code—or reusing one across accounts—is the most common cause of detection errors. 1. Log in to Search Atlas and navigate to the OTTO or SEO automation section of the platform. 2. Select the specific account or project you are troubleshooting. 3. Locate the OTTO Pixel snippet for that account and copy it exactly as displayed. 4. Confirm the UUID string inside the snippet matches the account you are working on. The UUID is the alphanumeric identifier embedded in the pixel script URL. 5. If you manage multiple accounts, repeat this process for each one individually—never share a single pixel across different accounts. 📍 Step 2: Understand Header Placement Requirements The OTTO Pixel must be placed inside the <head> tag of every page, as high as possible before other scripts. Placement in the footer or body will cause unreliable detection and may trigger a Not Installed status even when the code is present. - The pixel should load on all pages, not just the homepage. - Avoid placing it inside conditional logic blocks that prevent it from firing on every page load. - If a tag manager (such as Google Tag Manager) is used, ensure the tag is set to fire on All Pages with no exceptions. 🏗️ Step 3: Platform-Specific Installation Guidance ⚡ GoHighLevel (GHL) GHL allows you to add custom scripts at the site or funnel level. Paste your OTTO Pixel snippet into your site's header script area so it fires on every page. Note that site-level scripts may not automatically apply to funnel pages—check each funnel's settings individually and add the pixel there as well if needed. Save and publish your changes, then allow some time before re-checking detection status in Search Atlas. 🔵 WordPress On WordPress, the pixel must be inserted into the <head> section of every page. You can do this by editing your theme's header template directly, or by using a plugin that allows you to inject scripts into the header site-wide. Using a plugin is generally recommended for stability, as direct theme edits may be lost if the theme is updated or changed. Whichever method you use, verify the pixel is loading on all pages—not just the homepage—after installation. 🌸 Orchid CMS Orchid CMS and similar platforms typically provide a global header code or custom script area in site settings. Paste your OTTO Pixel snippet into that header field so it applies across all pages. Consult your CMS documentation if you are unsure where the global header script area is located. ✅ Step 4: Verification Checklist - Confirm the UUID in your pixel snippet matches the correct Search Atlas account. - Verify the pixel is placed in the <head> section, not the footer or body. - Check that the pixel fires on all pages, not just the homepage. - For multi-account setups, ensure each site uses its own unique pixel—do not share snippets across accounts. - After making changes, wait a few minutes and then recheck pixel status in Search Atlas. - Use your browser's developer tools (View Source or Network tab) to confirm the pixel script is present in the page source. 🆘 Still Seeing Issues? If you have followed all of the steps above and your pixel status still shows as Not Installed or Duplicate Detected, a support agent can investigate further. When reaching out, please have the following ready: your Search Atlas project or account name, the URL of the affected site, the UUID from your pixel snippet, and a description of which CMS platform you are using. 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.

🔧 OTTO Pixel & Schema Markup Troubleshooting in GoHighLevel

Overview When using GoHighLevel (GHL) as your website platform, two common OTTO issues can appear together: the OTTO pixel script is not detected after installation, and the schema markup feature shows an incomplete or failed deployment status. This article explains what to prepare and check for both issues, and how to get them resolved quickly with our support team. Where to Find OTTO In your Search Atlas dashboard, navigate to OTTO SEO using the left sidebar. Your OTTO settings, pixel script, and schema markup controls are all located within this section. Issue 1: OTTO Pixel Not Detected in GoHighLevel OTTO verifies that its pixel script is live on your site before activating automations. If the script appears to be installed in GHL but OTTO still shows it as undetected, common causes include: - Caching layers serving an older version of your page that does not include the script. - Script optimization or minification tools deferring or excluding the pixel before OTTO can read it. - The script being placed in a section or block that does not render on all pages sitewide. Steps to Try for Pixel Detection 1. Copy your OTTO pixel script from OTTO SEO in your Search Atlas dashboard. 2. In GoHighLevel, ensure the script is placed in a global location that injects into every page — not inside an individual page builder block, as these do not always render sitewide. Consult GoHighLevel's own documentation for the correct global script placement option in your account. 3. If you use any caching or script optimization tools alongside GHL, purge all caches and check whether those tools are processing or excluding the OTTO pixel. You may need to configure those tools to leave the pixel script untouched. 4. After making changes, return to OTTO SEO in Search Atlas and trigger a re-verification so OTTO re-crawls your site. 5. To confirm the script is being output, open your site in a browser, right-click, and choose View Page Source. Search for your OTTO pixel script ID in the raw HTML. If it is absent, the script is not being rendered by GHL and the placement should be reviewed. Issue 2: Schema Markup Showing Incomplete or Failed Deployment If your OTTO schema markup feature shows an incomplete or failed deployment status in GoHighLevel, this is typically related to the same root causes as pixel detection — the schema deployment relies on the pixel being correctly detected first, and GHL-specific caching or script handling can interfere with the deployment process. Steps to Try for Schema Markup Deployment 1. Confirm that the OTTO pixel is successfully detected (see Issue 1 above) before troubleshooting schema deployment, as a failed pixel detection will block schema deployment. 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.

🔑 Fix Wix CMS API Key Authentication Errors

🔍 Overview When connecting Wix CMS to Search Atlas, you may encounter an authentication error that reads: "Invalid or expired API Key. Please ensure your Wix API Key has the 'Manage Blog' permission enabled." This article walks you through the most common causes and how to fix them. ⚠️ Common Causes of This Error - The API key is missing the required Manage Blog permission - The API key was regenerated or expired after the initial connection was made - The Account ID was not included during setup - The wrong Wix site is associated with the API key - The API key belongs to a different Wix account than the one managing the site 🛠️ Step-by-Step Troubleshooting 1. Log in to your Wix account and go to Settings > API Keys in the Wix dashboard. 2. Verify the Manage Blog permission is enabled on your API key. If it is not checked, edit the key, enable the permission, and save. 3. Locate your Account ID. In Wix, your Account ID appears in the API Keys section, typically labeled Account ID at the top of the page. This is different from your Site ID. 4. Re-enter your credentials in Search Atlas. Go to the Wix CMS connector settings via Avatar Menu (👤) → Settings → CMS Connectors in Search Atlas, remove the existing connection, and reconnect using both your API Key and your Account ID. 5. Confirm the correct site is selected. During reconnection, make sure the site you are linking matches the site associated with your API key. 6. Generate a new API key if needed. If the key may have been regenerated or revoked, create a fresh API key in Wix, ensure Manage Blog is enabled, and use the new key in Search Atlas. ✅ Required Wix API Key Permissions Your Wix API key must have at least the following permission enabled for the Search Atlas integration to work correctly: - Manage Blog — required to read categories, posts, and other blog data Without this permission, Search Atlas cannot authenticate against the Wix API, even if the key itself is valid. 🔄 Reconnecting After Fixing Your Credentials Once you have corrected your API key permissions or generated a new key, follow these steps to restore the connection: 1. Open Search Atlas and navigate to your CMS Connector settings. 2. Select your Wix connection and click Disconnect or Reconnect. 3. Enter your updated API Key and Account ID in the fields provided. 4. Click Connect and wait for the status indicator to confirm a successful connection. 5. If the connection succeeds, trigger a manual sync to confirm data is flowing correctly. ❓ Frequently Asked Questions Do I need to include my Account ID? Yes. The Account ID is a required field. Submitting only the API key without the Account ID will cause the connection to fail, even if all permissions are correctly set. My permissions look correct but I still get the error. What should I do? Try generating a brand-new API key in Wix and reconnecting. Existing keys can become invalid if your Wix account credentials or plan change. What does "meta-site not found" mean? This error typically means the API key is associated with a different Wix account or site than the one you are trying to connect. Double-check that the Account ID and API key both belong to the same Wix account that owns the target site. 💬 Still Need Help? 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.

🔗 Fixing Unreachable OTTO Scripts After Lovable Migration

🔎 What This Article Covers If your SEO automation dashboard shows that all your OTTO scripts are unreachable after moving your whitelabel setup to Lovable, this guide explains why it happens and how to fix it. You will also learn how to migrate without losing your agency profile or disconnecting your OTTO sites. ⚠️ Why OTTO Scripts Become Unreachable OTTO works by connecting each of your sites to a small script that must load from the domain associated with your whitelabel setup. When you migrate your platform to a new host or environment such as Lovable, that connection can break for a few common reasons: - The whitelabel domain changed, so the OTTO script points to an address that no longer serves it. - DNS records were not updated after the migration, so requests to the script fail. - The OTTO script snippet on each site still references the old environment. - Caching or CDN settings from the previous setup are still active. When any of these happen, the dashboard cannot verify the script and marks your sites as unreachable, even though your account and data are intact. 🛡️ Protect Your Agency Profile First Your agency profile and OTTO site connections are stored in your account, not in the migrated front end. Migrating to Lovable does not delete this data. To keep everything safe before you make changes: - Confirm you are logged in to the same account you used before the migration. - Do not create a new account or new agency profile, as this can split your data. - Note your current whitelabel domain and any custom DNS records. 🛠️ How to Reconnect Your OTTO Scripts Follow these steps in order to restore the connection between your sites and OTTO. 1. Confirm your new whitelabel domain. Open your whitelabel settings and verify the domain now points to your Lovable environment. 2. Update your DNS records. Make sure the CNAME or A record for your whitelabel domain resolves to the correct destination. DNS changes can take up to 48 hours to fully propagate. 3. Re-copy the OTTO script. For each affected site, open the OTTO settings and copy the current script snippet. Replace the old snippet on your site with this fresh version. 4. Clear caches. Clear your site cache, browser cache, and any CDN cache so the new script can load. 5. Re-run the connection check. Return to the Left sidebar → OTTO SEO and use the option to verify or re-scan each site. ✅ Confirm Everything Reconnected After completing the steps above, review your dashboard to confirm the results: - Each OTTO site should now show a connected or active status instead of unreachable. - Your agency profile, branding, and client list should appear exactly as before. - Any pending OTTO tasks should resume automatically once the script is reachable. If a site still shows as unreachable, wait for DNS propagation to finish and then re-run the connection check. Most remaining errors clear on their own within a day. 💡 Tips to Avoid This During Future Migrations - Plan the domain move first. Set up and verify your new whitelabel domain before switching environments. - Keep the same account. Never start fresh, as your OTTO connections live in your existing profile. - Update scripts last. Refresh the OTTO snippet on each site only after DNS is confirmed working. - Migrate in batches. If you manage many sites, reconnect a few first to confirm the process before doing the rest. 💬 Still Need Help? If your OTTO scripts remain unreachable after following these steps, our team can review your specific setup. If you need further assistance, click the chat icon in the bottom-right corner of the platform to start a live chat with a member of our team.

🛠️ Fix Search Atlas WordPress Plugin Visual Rendering Issues

🔍 Overview Some WordPress sites experienced visual rendering problems after activating the Search Atlas plugin. Symptoms included images appearing zoomed in, page layouts breaking, and visitors seeing 'page not found' errors across all browsers. These issues have been identified as a visual rendering crash tied to the Search Atlas WordPress plugin. Updating to the latest available version of the plugin is the recommended resolution. ⚠️ Symptoms to Look For - Images appear zoomed in or distorted after activating the Search Atlas plugin. - Homepage or other pages fail to display content correctly. - Visitors see 'page not found' errors site-wide while the plugin is active. - Layout breaks persist across multiple browsers, ruling out a browser-specific cause. ✅ Solution: Update the Search Atlas Plugin The visual rendering crash has been linked to the Search Atlas WordPress plugin. Updating to the latest available version is the confirmed fix for this issue. 1. Log in to your WordPress admin dashboard. 2. Go to Plugins → Installed Plugins in the WordPress sidebar. 3. Locate the Search Atlas plugin in the list. 4. If an update is available, click Update Now. 5. Once the update completes, reload your website in a browser to verify images, layouts, and pages display correctly. 🔄 If the Problem Persists After Updating If updating the plugin does not immediately resolve the visual issues, try the following additional steps: - Clear your WordPress and page builder cache. If you use a caching plugin or a page builder such as Elementor, clear its cache after updating the Search Atlas plugin. Stale cached assets can continue to cause layout issues even after the underlying bug is fixed. - Clear your browser cache. Press Ctrl + Shift + Delete (Windows) or Cmd + Shift + Delete (Mac) to clear cached files, then reload your site. - Test in a private or incognito browser window. This rules out locally cached resources as the cause. - Deactivate and reactivate the plugin. In Plugins → Installed Plugins, deactivate the Search Atlas plugin, then reactivate it to ensure the updated version loads cleanly. 📋 Still Experiencing Issues? If your site continues to show rendering problems after updating the plugin and clearing caches, please reach out to the Search Atlas support team via the chat widget in your dashboard so we can investigate further.

🔌 Fix WordPress MetaSync Plugin Authentication Failures

🔍 Overview When connecting your WordPress site to Search Atlas using the MetaSync plugin, you may encounter an Authentication Failed error or a blank/spinning popup that prevents the connection from completing. This article walks you through the most common causes and how to fix them. ⚙️ Before You Begin Make sure you have the following ready: - Admin access to your WordPress dashboard - Admin access to your Search Atlas account - The latest version of the MetaSync plugin installed and activated 🛠️ Step 1 — Verify Your OTTO SEO Setup The MetaSync plugin requires an active OTTO SEO setup linked to your site before authentication can complete. If OTTO has not been configured, the plugin cannot verify your account. 1. Log in to your Search Atlas account. 2. Navigate to OTTO SEO from the main menu. 3. Confirm that your WordPress site's domain is listed and that OTTO has been activated for it. 4. If your site is not listed, add it and complete the OTTO setup before proceeding. 🔑 Step 2 — Regenerate Your API Key A corrupted or outdated API key is a common cause of authentication failures. Regenerating the key often resolves the issue. 1. In Search Atlas, go to Settings → API Keys (or your account/profile settings). 2. Locate your existing API key and select Regenerate or Create New Key. 3. Copy the new API key immediately — it will only be shown once. 4. In your WordPress dashboard, go to Search Atlas → Settings. 5. Paste the new API key into the API Key field and save. 6. Click Connect and wait for the authentication popup to complete. 🌐 Step 3 — Check for a 500 Error in the Authentication Popup If the authentication popup returns a 500 error instead of a success message, this indicates a server-side verification issue. Try the following: - Clear your browser cache and cookies, then retry the connection in a fresh browser window. - Disable any browser extensions (especially ad blockers or privacy tools) that may interfere with the popup. - Try a different browser to rule out a local browser issue. - Ensure your WordPress site is publicly accessible and not behind a maintenance mode plugin or firewall that blocks external API requests. 🔒 Step 4 — Confirm Your Site Allows External API Requests The MetaSync plugin communicates with Search Atlas servers to verify your API key. If your hosting environment blocks outbound requests, authentication will fail. - Check with your hosting provider that outbound HTTPS requests on port 443 are not blocked. - If you use a security plugin (e.g., Wordfence, iThemes Security), temporarily disable it and retry the connection. - If you use a firewall or CDN (e.g., Cloudflare), make sure Search Atlas API endpoints are not being blocked or rate-limited. - Ensure your WordPress site has a valid SSL certificate — authentication will not complete over HTTP. 🔄 Step 5 — Reinstall the MetaSync Plugin If none of the steps above resolve the issue, reinstalling the plugin clears any corrupted plugin files that may be causing the failure. 1. In your WordPress dashboard, go to Plugins → Installed Plugins. 2. Deactivate and then Delete the MetaSync plugin. 3. Download the latest version of the MetaSync plugin from your Search Atlas account or the WordPress plugin repository. 4. Upload and activate the plugin. 5. Re-enter your API key and attempt the connection again. ✅ Confirming a Successful Connection A successful connection will display a confirmation message inside the MetaSync plugin settings page, and your site will appear as connected in your Search Atlas dashboard. Once connected, data sync between WordPress and Search Atlas will begin automatically. 💬 Still Need Help? If you have followed all the steps above and are still seeing an authentication error, 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. When reaching out, please share the following to help us investigate faster: - Your WordPress site URL - The exact error message or screenshot you are seeing - Your WordPress version and MetaSync plugin version - Any security plugins or firewall tools active on your site

🔗 Reconnecting Google Search Console in Search Atlas

🔍 Overview If you have connected your Google account to Search Atlas but cannot select the correct Google Search Console (GSC) property — or the connection is not working as expected — this guide walks you through the steps to resolve the issue quickly. ⚠️ Common Causes of This Issue - Your Google account lost authorization and needs to be reconnected. - You are signed into the wrong Google account in your browser. - The GSC property you need is owned by a different Google account than the one you connected. - Permissions on the GSC property were changed or revoked after the initial connection. 🛠️ Step 1: Disconnect Your Current Google Account Before reconnecting, remove the existing Google authentication to start fresh. 1. Click your Avatar Menu (👤) or account settings in the top-right corner of Search Atlas. 2. Navigate to the Integrations or Connected Accounts section. 3. Find the Google Search Console connection and click Disconnect or Remove. 4. Confirm the disconnection when prompted. 🌐 Step 2: Check Which Google Account You Are Using This is the most common reason customers cannot find the right property. Your GSC property must be accessible from the Google account you connect. - Open a new browser tab and go to search.google.com/search-console. - Confirm you are signed in with the Google account that owns or has access to the property you want to use. - If you see the correct property listed in GSC, you are using the right account. If not, switch Google accounts before proceeding. 🔄 Step 3: Reconnect Google Search Console 1. Return to Search Atlas and navigate to Site Metrics → Site Explorer → Open Google Search Console (Manage Sites page). 2. Click Connect GSC Account. 3. A Google sign-in window will appear. Select the correct Google account — the same one that has access to your GSC property. 4. When prompted, grant all requested permissions. Search Atlas requires read access to your GSC data to display metrics correctly. Do not uncheck any permission checkboxes. 5. Click Allow to complete the authorization. 📊 Step 4: Select Your GSC Property Once the account is reconnected, you should be able to choose your property. 1. Navigate to Left sidebar → Site Metrics → Site Explorer. 2. Open the project or site you want to link to GSC. 3. In the GSC property selector, click the dropdown and look for your property in the list. 4. Select the correct property and save your settings. If the property still does not appear in the dropdown, confirm the following: - The property is verified in Google Search Console (not pending verification). - You connected the Google account that has Owner or Full User access to that property — Restricted User access may limit what Search Atlas can retrieve. - The property URL format matches exactly — for example, https://www.example.com and https://example.com are treated as separate properties in GSC. 💡 Tips to Avoid This Issue in the Future - Always use the same Google account to manage both your GSC properties and your Search Atlas connection. - If you change GSC property ownership or permissions, reconnect the integration in Search Atlas afterwards. - Avoid revoking Search Atlas app permissions from your Google account settings, as this will break the connection. 🙋 Still Need Help? If you have followed all the steps above and still cannot connect or select your GSC property, 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.

🛠️ Fix OTTO Pixel React Hydration Errors in Next.js

🔍 Overview The OTTO Pixel is a client-side script injection method that works well for traditional server-rendered or static sites. However, in Next.js and other React-based frameworks, the Pixel can cause React hydration errors and trigger repeated client-side API calls. This happens because the Pixel modifies the DOM after the initial server render, creating a mismatch between server-rendered HTML and what React expects on the client. The recommended solution for Next.js sites is to use the OTTO API integration, which fetches SEO data server-side before the page is rendered, completely avoiding DOM conflicts. ⚠️ Why the OTTO Pixel Causes Issues in Next.js React hydration works by attaching event listeners and state to a DOM that must exactly match what the server produced. When the OTTO Pixel injects meta tags or structured data into the DOM after hydration begins, React detects a mismatch and throws errors such as: - Hydration failed because the initial UI does not match what was rendered on the server - Repeated or duplicate API calls firing on every client-side navigation - SEO tags flickering or appearing inconsistently in page source Switching to the OTTO API integration resolves all of these issues by moving data-fetching to the server, so the HTML React receives on the client is already complete. 🚀 How the OTTO API Integration Works Instead of injecting a script tag into your page, the OTTO API integration lets your Next.js app call the OTTO API directly during server-side rendering (SSR) or static site generation (SSG). The API returns the SEO metadata for each page, which you render into your <head> before the HTML is sent to the browser. React then hydrates a page that is already complete — no DOM conflicts, no duplicate calls. ⚙️ Step-by-Step: Implementing the OTTO API Integration in Next.js 1. Remove the OTTO Pixel script tag from your _app.js, _document.js, or any layout component where it is currently injected. Removing it first prevents any conflicts during the migration. 2. Locate your OTTO UUID by navigating to Left sidebar → OTTO SEO → Installation Guide in the Search Atlas platform. Your UUID is displayed on that page and is required for all API requests. 3. Fetch SEO data server-side inside getServerSideProps (for SSR) or getStaticProps (for SSG) in each page file. Make a request to the OTTO API endpoint, passing your UUID and the current page path as parameters. The API response will contain the meta title, meta description, canonical URL, structured data, and any other SEO fields OTTO manages for that page. 4. Pass the API response as props to your page component. Keep the data shape flat and serialisable so Next.js can pass it through props without issues. 5. Render the SEO data into your <head> using Next.js's built-in next/head component (or your preferred head-management library). Because this happens on the server, the rendered HTML will already contain the correct meta tags before React hydrates. 6. Verify the integration by viewing the page source (not the browser inspector) and confirming the OTTO-managed meta tags appear in the raw HTML. Also check your browser console for any remaining hydration warnings. 7. Re-scan your site in Search Atlas by navigating to Left sidebar → OTTO SEO → Site Audit → Overview (Website Overview) and clicking Recrawl Site. This confirms OTTO can read the tags from your live pages and that the installation status updates correctly. 💡 Tips for a Smooth Migration - Handle API errors gracefully. Wrap your OTTO API call in a try/catch block and fall back to default meta values if the request fails, so a temporary API issue never breaks your pages. - Cache responses for SSG pages. If you use getStaticProps with revalidate, the OTTO API is only called during build or revalidation — not on every visitor request — which keeps performance fast. - Use a shared fetch utility. Create a single helper function (e.g., fetchOttoSeo(uuid, path)) that all your page files import. This avoids duplicating fetch logic and makes future updates easier. - Do not include the Pixel and the API integration at the same time. Running both simultaneously will cause duplicate tags and may trigger the same hydration conflicts you are trying to fix. - Dynamic routes (e.g., /blog/[slug]) should pass the resolved path string to the API — not the Next.js route pattern — so OTTO can match it to the correct page record. ✅ Confirming the Fix After completing the integration, confirm the following: - No hydration errors appear in the browser console on first load or client-side navigation. - Meta tags are visible in the raw page source before JavaScript executes. - The OTTO installation status in Left sidebar → OTTO SEO → Site Audit → Overview (Website Overview) shows as active and scanning correctly. - Network requests show a single server-side call to the OTTO API per page render — not repeated client-side calls. 💬 Need More Help? 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.

🔌 Fix WordPress Connector Gateway API Errors

🔍 What This Error Means If your WordPress connection shows a status of Active but you see an error such as 'operation wordpress-get-current-user is not available', the connection has lost its ability to communicate with the Search Atlas gateway. This typically means the link between Search Atlas and your WordPress site has broken at the API level, even though the dashboard still displays the connection as healthy. This is a known issue that can affect one or more WordPress sites connected within the same workspace. ⚠️ Does This Affect All My WordPress Sites? Not necessarily, but it can. Each WordPress connection in your workspace operates independently, so the error may be isolated to a single site. However, if the underlying cause is workspace-level (for example, a plugin sync failure or a gateway registration problem), multiple connected sites can be affected at the same time. We recommend checking all your WordPress connections when you encounter this error. 🛠️ Common Causes - The Search Atlas WordPress plugin was deactivated, removed, or is outdated on your WordPress site. - A plugin sync failure caused the site to drop out of the gateway registry, making its operations unavailable. - The connection token expired or became invalid after a WordPress update or site migration. - A previous reconnection attempt appeared successful in the dashboard but did not fully re-register the site with the API gateway. ✅ Step-by-Step Fix 1. Check the Search Atlas plugin on your WordPress site. Log in to your WordPress admin panel, go to Plugins, and confirm the Search Atlas plugin is installed, active, and up to date. If it is deactivated, reactivate it. If it is missing, reinstall it from your WordPress plugin library or via the instructions in your Search Atlas account. 2. Delete and reconnect the WordPress connector in Search Atlas. In your Search Atlas workspace, navigate to Avatar → Settings → Integrations (or CMS Connectors). Find the affected WordPress connection, click the options menu, and select Delete. Once removed, click Add Connection and reconnect your WordPress site from scratch. This forces a full re-registration with the API gateway. 3. Run a test connection. After reconnecting, use the Test Connection option to confirm the gateway can reach your site and that all operations are available. A successful test will show a green status with no errors. 4. Repeat for each affected site. If you have multiple WordPress sites in your workspace showing the same error, delete and reconnect each one individually. Do not assume a successful reconnect on one site resolves the others. 5. Retry your publishing or sync action. Once all connections test successfully, return to the content or task that originally triggered the error and try again. 💡 How to Prevent This in the Future - Keep the Search Atlas WordPress plugin updated whenever a new version is released. - Avoid deactivating the plugin on your WordPress site without first disconnecting it inside Search Atlas. - After any WordPress update or site migration, run a test connection in Search Atlas to confirm the API gateway link is still healthy. - If you transfer a WordPress site to a new host or change its domain, delete and reconnect it in Search Atlas rather than relying on the existing connection. ❓ Still Seeing the Error? If you have followed all the steps above and the error persists, or if the connector appears grayed out and cannot be deleted or reconnected, there may be a deeper configuration issue that requires investigation by our team. 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. Additional Notes Because the root cause is at the platform level, it requires investigation by the Search Atlas team. Gather: exact error message, failing operation name, WordPress site URL, date/time error first appeared, screenshots. Open chat widget and type 'human teammate' to reach support.

🔌 Fix Wix Integration Reconnect Button Not Responding

🔍 Overview When connecting your Wix site to Search Atlas, the Reconnect button may appear clickable but produce no response. This typically happens when Search Atlas detects an invalid or expired credential state — for example, a mismatched API key, an incorrect Site ID, or a Wix account permission issue. This article walks you through the steps to resolve the problem and complete your integration successfully. ⚠️ Common Causes - The Wix API key has expired or been regenerated in your Wix dashboard since the last connection attempt. - The Site ID entered does not exactly match the site you are trying to connect. - The Wix account used to generate the API key does not have sufficient permissions for the target site. - The integration is stuck in a disconnected credential state, preventing the reconnect flow from completing. - The site's display name in Wix exceeds 200 characters, which causes a validation error during connection. 🛠️ Step-by-Step Fix 1. Log in to your Wix account and navigate to Settings → Advanced → API Keys. 2. Check whether the existing API key is still active. If it has been revoked or regenerated, create a new API key and copy it immediately. 3. Locate your Wix Site ID by going to Settings → General Info and scrolling to the Site ID field. Copy the exact value — it is case-sensitive. 4. Confirm that the Wix account you are using is listed as an Owner or Admin on the site. Contributor roles may not have the permissions needed for API access. 5. Check your Wix site's display name (the public-facing name shown in Settings → General Info). If it is longer than 200 characters, shorten it and save the change before retrying. 6. Return to Search Atlas and open Settings → Integrations → Wix. 7. If the integration shows a disconnected or error state, click Disconnect first to fully reset the connection. Wait a few seconds for the status to update. 8. Click Connect (not Reconnect) and enter your new API key and the exact Site ID from step 3. 9. Click Save and wait up to 30 seconds for Search Atlas to validate the credentials and confirm the connection. ✅ Confirming a Successful Connection Once the integration completes successfully, the status indicator next to your Wix site will change to Connected. If you still see a Reconnect or Fix Now prompt after following the steps above, refresh the page — the status sometimes requires a manual refresh to update in the UI. 💡 Tips to Prevent This Issue - Always use an API key generated by the site Owner account, not a collaborator account. - Keep your Wix site's display name under 200 characters to avoid validation errors during sync. - If you regenerate your Wix API key for any reason, update it in Search Atlas immediately to avoid credential expiry issues. - Do not close the browser tab or navigate away while the connection process is running. 💬 Still Need Help? If you have followed all the steps above and the Reconnect button is still unresponsive, our team can investigate the credential state on your account directly. 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.

⚡ Search Atlas REST API Authentication and Error Fixes

Overview The Search Atlas REST API requires proper authentication before making API calls. Understanding how to obtain and use the correct credentials is essential to successfully integrating with the API. This article covers how to authenticate with the Search Atlas API and how to resolve common API errors related to credential configuration. Part 1 — Authenticating with the Search Atlas REST API The Search Atlas REST API uses a token-based authentication system. To make authenticated API requests, you must first obtain an access token using your Search Atlas account credentials. What credentials are required? - username — your Search Atlas account email address (the same one you use to log in to app.searchatlas.com) - password — your Search Atlas account password These are the same credentials you use to log in to the main platform. Once you have obtained your access token, include it in the headers of subsequent API requests as a Bearer token. Important notes: - Access tokens are time-limited. If you receive an authentication error mid-session, re-request a fresh token and retry your request. - Make sure you are using your Search Atlas login credentials, not a separate API key, when requesting an access token from the token endpoint. - Avoid hardcoding credentials directly in shared scripts. Use a secure credential storage method appropriate for your integration environment. Part 2 — Fixing Common API Authentication Errors If you are receiving authentication or configuration errors when calling the Search Atlas API, the most common causes are: 1. Wrong credential type — Using the wrong value (for example, passing a login password where an API key is expected, or vice versa). Confirm which credential type each endpoint requires before making calls. 2. Incorrect or malformed credential — The credential was copied with extra whitespace, a missing character, or from an outdated or revoked source. Copy your credentials carefully from your Search Atlas account settings. 3. Credential not yet generated — If you have not yet created an API key or token in your account, the relevant endpoint will reject your request. Check your account settings to confirm your credentials exist and are active. 4. Incorrect endpoint URL — Requests sent to a wrong or mistyped endpoint path will return errors. Double-check the endpoint URLs against the official Search Atlas API documentation. If you are unsure which credentials or endpoint configuration apply to your specific use case, gather the following before escalating: the endpoint URL you are calling, the exact error message or response code you are receiving, and the credential type you are passing. 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.

🔧 Fix OTTO Pixel Navigation Bar Conflicts in GoHighLevel

🧭 Overview When you install the OTTO Pixel on a GoHighLevel (GHL) site, the mobile navigation bar can disappear or become unresponsive. This happens because the OTTO Pixel script can interfere with GoHighLevel's built-in CSS cascade, z-index stacking, or DOM rendering order. This article explains the verified root causes and gives you exact steps to fix the conflict. ⚠️ Why This Happens There are three common reasons the navigation bar disappears after adding the OTTO Pixel to a GoHighLevel site: - CSS cascade conflict: The OTTO Pixel script loads external stylesheets or inline styles that override GoHighLevel's navigation CSS, causing the nav bar to render hidden or behind other elements. - Z-index conflict: GoHighLevel navigation components rely on specific z-index values. If the OTTO Pixel introduces a stacking context at a higher z-index, the nav bar is visually obscured even though it still exists in the DOM. - DOM manipulation timing: If the OTTO Pixel script executes before GoHighLevel finishes building the navigation element, it can remove or alter nodes the nav bar depends on, causing it to disappear on mobile viewports where rendering order is stricter. 📍 Where to Place the OTTO Pixel Script in GoHighLevel Correct placement is the single most important fix. Follow these steps exactly: 1. Log in to your GoHighLevel account and open the site or funnel where the issue occurs. 2. Go to Settings → Custom Code (or Site Settings → Header Tracking Code, depending on your GHL version). 3. Locate the Header code block — this is where the OTTO Pixel must be placed. 4. Paste the OTTO Pixel script as the last item inside the header code block, after any existing scripts or meta tags. Placing it last prevents it from interfering with GoHighLevel's own script initialization order. 5. Save and publish your changes. 6. Test on a mobile device or using your browser's mobile emulation tool to confirm the navigation bar is visible and functional. Do not place the OTTO Pixel in the body or footer code blocks. Body and footer placement increases the risk of DOM manipulation conflicts because GoHighLevel builds navigation components earlier in the render cycle. 🏷️ Adding the data-cfasync Attribute The data-cfasync="false" attribute tells Cloudflare's Rocket Loader to skip asynchronous processing of the OTTO Pixel script. Without it, Rocket Loader can delay or reorder script execution, which worsens DOM timing conflicts on GoHighLevel pages. Add the attribute directly inside the opening script tag of the OTTO Pixel, like this: - Find the OTTO Pixel script tag in your GoHighLevel header code block. - Change <script src="..."> to <script data-cfasync="false" src="...">. - If your OTTO Pixel is an inline script (no src attribute), add the attribute the same way: <script data-cfasync="false">. - Save and republish the site. Important: The data-cfasync="false" attribute must be placed inside the opening script tag itself, not as a separate tag or comment. Placing it anywhere else will have no effect. 🔍 Diagnosing a Z-Index or CSS Conflict If the navigation bar is still missing after correct script placement and adding the data-cfasync attribute, a z-index or CSS conflict may still be present. Use these steps to investigate: 1. Open your browser's developer tools (right-click the page and select Inspect). 2. Use the element selector to click on the area where the navigation bar should appear. 3. In the Styles panel, look for any CSS rule applying z-index, display: none, visibility: hidden, or opacity: 0 to the navigation element. 4. Check whether any of those overriding rules originate from a script or stylesheet loaded after GoHighLevel's core styles. 5. If you find a conflicting rule, note the CSS selector and contact our support team with that information so our team can advise on a targeted fix. ✅ Quick Checklist Before Escalating - OTTO Pixel script is placed last inside the GoHighLevel header code block. - data-cfasync="false" is added inside the opening script tag. - No duplicate OTTO Pixel scripts exist in body or footer code blocks. - Site has been saved and published after changes (not just saved). - Navigation issue has been tested on an actual mobile device, not just desktop. - Browser cache has been cleared before retesting. 🔗 Finding the OTTO Pixel in Search Atlas To locate your OTTO Pixel code in Search Atlas, go to Left sidebar → OTTO SEO, then open SEO Automation (URL: /seo-automation-v3). From there, open your connected project and navigate to the OTTO settings to find your unique pixel snippet. 💬 Still Need Help? If you have confirmed all checklist items above and the navigation bar is still not displaying correctly, our team will need to review your specific GoHighLevel HTML structure and script configuration. 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.

🔄 Fix WordPress Content Sync and Publishing Failures

🔍 Overview Search Atlas can connect directly to your WordPress site to publish and manage content. When a sync appears successful but content still fails to publish, the issue may stem from a misconfigured connection, a WordPress plugin conflict, or insufficient user permissions. This article describes the types of issues that can cause WordPress content sync and publishing failures in Search Atlas and explains what information to have ready when contacting our support team. ⚙️ Step 1 — Verify Your WordPress Connection A successful sync indicator does not always mean the connection is fully functional. Confirm that your WordPress integration is correctly configured by checking the following: - Locate the WordPress integration settings within Search Atlas and confirm that the site URL entered matches your WordPress site exactly — including the correct protocol (http:// or https://) — with no trailing slash errors. - Re-enter your WordPress credentials or API key and save the connection to refresh it. - If you are using the Search Atlas WordPress plugin, confirm it is installed, activated, and running the latest version inside your WordPress dashboard. 🔐 Step 2 — Check WordPress User Permissions Search Atlas publishes content using the WordPress user account linked during setup. If that account lacks sufficient permissions, publishing may fail even when the sync reports no errors. - Log in to your WordPress admin dashboard. - Locate the user account connected to Search Atlas and verify it has adequate publishing rights. - Save any changes and attempt to publish again from Search Atlas. 🛠️ Step 3 — Check for Plugin or REST API Conflicts WordPress publishing through Search Atlas relies on the WordPress REST API. Security plugins, firewall plugins, or misconfigured server settings can block REST API requests, causing silent publishing failures. 1. In your WordPress dashboard, review your installed plugins and consider temporarily deactivating any security or firewall plugins to test whether they are blocking the connection. 2. Attempt to publish a piece of content from Search Atlas again. 3. If publishing succeeds after deactivating a plugin, re-enable your plugins one at a time to identify which one is causing the conflict. 4. Once identified, configure that plugin to allow requests from Search Atlas, then re-enable it. You can also check whether your WordPress REST API is accessible by visiting yoursite.com/wp-json/ in a browser. If you see a JSON response, the API is active. If you see a blank page or error, the API may be disabled or blocked — contact your hosting provider in that case. 🔁 Step 4 — Retry the Sync and Escalate if Needed After making any of the corrections above, retry publishing from Search Atlas. If the issue persists, our support team can investigate further. To help us resolve your case as quickly as possible, please have the following ready: - The name of the Search Atlas project or workspace affected - The WordPress site URL you are trying to connect - A description of the exact error message or behavior you are seeing (including any error codes if shown) - The approximate date and time the issue started - A note on whether the Search Atlas WordPress plugin is installed and its current version 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.

📸 Connect and Troubleshoot Your Instagram Account

📋 Before You Connect: Account Requirements Instagram connections in Search Atlas are powered by the Meta API, which enforces a few hard prerequisites. Check all of the following before attempting to connect: - Business or Creator account type: Instagram Personal accounts cannot be linked to any third-party platform. Open the Instagram app and go to Settings → Account → Switch to Professional Account to convert before proceeding. - Instagram linked to a Facebook Page: Meta requires your Instagram Business or Creator account to be connected to a Facebook Page. In the Instagram app, go to Settings → Account → Linked Accounts and connect a Facebook Page. - Admin access on the Facebook Page: The Facebook account you use to authorise the connection must hold Admin-level permissions on that linked Page. Ask the Page owner to upgrade your role if needed. 🔗 How to Connect Instagram in Search Atlas 1. Click Local in the left sidebar. 2. Select Posts from the sub-menu. 3. Click Connect Account and choose Instagram from the platform list. 4. A Meta authorisation pop-up will open. Log in with the Facebook account linked to your Instagram Business or Creator account. 5. Grant all requested permissions — Search Atlas requires these to publish and schedule posts on your behalf. 6. Select the correct Instagram account from the list and confirm the connection. Once connected, your Instagram account will appear in the Posts section and you can begin creating and scheduling content immediately. ⚠️ Common Reasons Instagram Won't Connect - Personal account type: This is the most frequent cause. Meta's API blocks Personal accounts entirely. Convert to Business or Creator as described above, then retry. - Instagram not linked to a Facebook Page: Without an active Page link, the Meta API cannot verify ownership. Add the link inside the Instagram app, then restart the connection flow in Search Atlas. - Insufficient Facebook Page permissions: If you are not an Admin on the linked Page, the authorisation will fail silently or mid-flow. Confirm your role with the Page owner. - Pop-up blocker active: The Meta authorisation window opens as a browser pop-up. If nothing appears after clicking Connect, disable your browser's pop-up blocker for the Search Atlas domain and try again. - Previously revoked Meta permissions: If Search Atlas was removed from your connected Facebook apps, you must fully re-authorise. In Facebook, go to Settings & Privacy → Settings → Security and Login → Apps and Websites, remove any Search Atlas entry, then reconnect from scratch in the platform. - Expired access token: Meta tokens can expire after 60–90 days. A previously connected account showing as disconnected simply needs to be reconnected using the same steps above. 🔄 Reconnecting a Disconnected Account If an Instagram account that was working before is now showing as disconnected or returning an error: 1. Go to Local → Posts in the left sidebar. 2. Locate the affected Instagram account and click Reconnect, or remove it and re-add it using the Connect Account flow. 3. Complete the Meta authorisation as described above. If the reconnection fails immediately, verify that the Instagram account is still set to Business or Creator type and that the Facebook Page link is still active inside the Instagram app — both settings can be changed accidentally. 💬 Still Need Help? 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.

🔧 Fix WordPress Content Sync Unexpected Error

🔍 Identify the Issue If you see an unexpected_error popup or the message We're unable to sync with your WordPress site when publishing content, and synced posts show no permalink URLs, the sync process may be failing even though posts are actually publishing. 🛠️ Use the Plugin's Manual Sync Option 1. Log in to the Search Atlas dashboard. 2. Navigate to Left sidebar → Content → Content Genius (What are we writing today?). Use the CMS SYNC column to trigger a manual content sync. 3. Check your WordPress posts list — the content should now appear published with valid permalinks. This manual sync often bypasses the UI issue that incorrectly flags successfully published posts as unsynced. ✅ Verify the Fix After running the manual sync, open a few synced posts in WordPress and confirm they have live permalink URLs. If posts are publishing correctly but the Search Atlas dashboard still shows an error, the issue is likely a display bug that has been resolved in a recent platform update. 📞 Contact Support If Needed If the manual sync does not resolve the issue or errors persist across multiple sites, 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. Provide the affected site URLs and any error screenshots to help us investigate further.

🛠️ Fix OTTO Pixel Not Installed Correctly Error

🔍 Why You're Seeing This Error The "OTTO Pixel is not installed correctly" message appears when Search Atlas cannot detect your OTTO Pixel firing on your website. This can happen even if you have the WordPress plugin installed and your GTM container published. The most common causes are a conflict between two installation methods, an unpublished GTM tag, or a firing trigger that hasn't been configured correctly. ⚙️ How the OTTO Pixel Can Be Installed There are two supported ways to install the OTTO Pixel. You should use only one method — running both at the same time will cause conflicts and trigger the error. - Method 1 — WordPress Plugin: The OTTO Pixel snippet is injected directly into your site via the Search Atlas WordPress plugin. - Method 2 — Google Tag Manager (GTM): You add the OTTO Pixel as a custom HTML tag inside GTM and publish the container. If you installed the WordPress plugin and also added the pixel code inside GTM, disable one of them before proceeding. 🛠️ Step-by-Step: Verify Your GTM Installation If you are using GTM as your installation method, follow these steps carefully. 1. Confirm the WordPress plugin is not also injecting the pixel. In your WordPress dashboard, go to the Search Atlas plugin settings and check whether the pixel output is enabled. If it is, disable it so GTM is the only active method. 2. Check your GTM tag is set up correctly. Log in to your GTM account, open the correct container for your website, and locate the OTTO Pixel tag. Make sure the pixel code is pasted in full inside a Custom HTML tag — not a different tag type. 3. Verify the trigger fires on all pages. Open the tag in GTM and check the trigger assigned to it. It should be set to All Pages (Page View trigger). If no trigger is assigned, the tag will never fire. 4. Publish the GTM container. Click Submit in the top-right corner of GTM and then Publish to push the latest version live. Saving a tag without publishing means the change is not yet active on your site. 5. Use GTM Preview mode to confirm the tag fires. Click Preview in GTM, enter your website URL, and navigate to any page. In the Tag Assistant panel, confirm the OTTO Pixel tag shows a status of Fired. If it shows Not Fired or does not appear at all, revisit the trigger configuration in step 3. 🛠️ Step-by-Step: Verify Your WordPress Plugin Installation If you are using the WordPress plugin as your installation method (without GTM), follow these steps. 1. Confirm the plugin is active. In your WordPress dashboard, go to Plugins → Installed Plugins and verify that the Search Atlas plugin status shows Active. 2. Check the pixel is configured inside plugin settings. In WordPress, go to Search Atlas → Settings and confirm the OTTO Pixel UUID field is populated and saved. 3. Remove any duplicate pixel code from GTM. If the OTTO Pixel tag also exists inside a GTM container, remove or pause it and re-publish the container so it is no longer firing. 4. Clear your site cache. If you use a caching plugin such as WP Rocket, W3 Total Cache, or a CDN like Cloudflare, purge all caches so the latest version of your pages is served to visitors and to Search Atlas during verification. ✅ Re-Run the Pixel Verification in Search Atlas Once you have completed the steps above, return to Search Atlas and re-trigger the pixel check. 1. In the left sidebar, navigate to OTTO SEO and open SEO Automation (URL: /seo-automation-v3). 2. Locate your OTTO project and open its settings. 3. Find the Pixel Installation section and click Verify Installation or the equivalent re-check button. 4. Wait a few seconds for the check to complete. If the pixel is detected correctly, the error message will be replaced with a green confirmation status. 💡 Quick Troubleshooting Checklist - Only one installation method is active — plugin or GTM, not both. - GTM container has been published (not just saved). - GTM tag trigger is set to All Pages. - GTM Preview mode confirms the tag Fired. - WordPress plugin is Active and pixel output is enabled in settings. - Site cache and CDN cache have been purged. - No ad blocker or browser extension is interfering during your own verification test. 💬 Still Seeing the Error? If you have followed all the steps above and the pixel is still not verifying, there may be a theme conflict, a custom caching layer, or an advanced GTM configuration causing the issue. 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.

🔌 Fix 'Pixel Not Connected' in WordPress Plugin

🔍 Understanding the 'Pixel Not Connected' Error After installing the Search Atlas WordPress plugin and authorizing it via your WordPress login, you may see a Pixel Not Connected status. This typically means the plugin has been authenticated but the tracking pixel has not yet been verified or properly linked to your Search Atlas account. Follow the steps below to resolve this. ✅ Step 1: Confirm the Plugin Is Installed and Active 1. Log in to your WordPress admin dashboard. 2. Go to Plugins → Installed Plugins. 3. Locate the Search Atlas plugin and confirm its status shows Active. If it shows Inactive, click Activate. 🔑 Step 2: Re-Authorize the Plugin Connection Authorization via WordPress login alone does not always complete the pixel handshake. You must also connect your site from within the Search Atlas platform. 1. Log in to your Search Atlas account. 2. In the left sidebar, click Site Metrics (Site Explorer). 3. Locate your website in the list, or add it if it has not been added yet. 4. Follow any prompts to reconnect or verify your site. This step triggers the pixel verification process. 🛠️ Step 3: Verify the Pixel Is Firing on Your Site Even when the plugin is active, a caching layer or conflicting plugin can prevent the pixel from loading correctly on your site's front end. - Clear your WordPress cache — if you use a caching plugin such as WP Rocket, W3 Total Cache, or LiteSpeed Cache, purge all cached files after activating the Search Atlas plugin. - Clear your CDN cache — if your site runs through Cloudflare or another CDN, purge the CDN cache to ensure the updated page code is served. - Check for plugin conflicts — temporarily deactivate other plugins one at a time to identify any that may be blocking the pixel from loading. - Disable minification — some optimization plugins that minify or combine JavaScript files can interfere with pixel scripts. Temporarily disable JS minification and retest. 🌐 Step 4: Check Your Site's URL Format A mismatch between the URL registered in Search Atlas and the actual URL of your WordPress site is a common cause of pixel connection failures. - Make sure the URL in Search Atlas matches your site exactly — including whether it uses www or non-www, and http or https. - If your site recently moved to HTTPS or changed its primary domain, update the URL in Search Atlas to reflect this. 🔄 Step 5: Reinstall the Plugin If the steps above do not resolve the issue, a clean reinstall of the plugin often clears corrupt configuration data. 1. In your WordPress dashboard, go to Plugins → Installed Plugins. 2. Deactivate and then Delete the Search Atlas plugin. 3. Reinstall the plugin by uploading the latest plugin .zip provided by Search Atlas via Plugins → Add New → Upload Plugin. 4. Activate the plugin and complete the authorization flow again. 5. Return to Site Explorer in Search Atlas and check whether the pixel status has updated to Connected. ⏱️ Allow Time for Status to Update After completing authorization and verifying the pixel is present on your site, the Pixel Not Connected status may take up to 15–30 minutes to refresh inside the Search Atlas platform. Visit a few pages on your site to generate pixel activity, then return to Site Explorer to recheck the status. 💬 Still Seeing the Error? If you have followed all the steps above and the pixel is still showing as not connected, 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.

🚀 Installing OTTO Pixel on Next.js Without Errors

Overview OTTO supports two installation methods: direct pixel installation and Google Tag Manager (GTM) deployment. This article explains how to implement either method in a Next.js project so you do not encounter React hydration errors or performance issues. Why Hydration Errors Happen React hydration errors occur when the HTML rendered on the server does not match what React expects to render on the client. The OTTO pixel is a client-side script. If it runs during server-side rendering (SSR), it can reference browser-only globals such as window or document that do not exist in the Node.js environment, causing a mismatch. The fix is to ensure the pixel only ever runs in the browser, after the component has mounted. Supported OTTO Integration Methods - Direct pixel installation — Embed the OTTO pixel script directly in your Next.js project using a client-side-safe approach. - Google Tag Manager — Deploy the OTTO pixel through a GTM container tag, which fires only in the browser environment. If you are unsure which method fits your setup, contact the Search Atlas support team and they will help you choose the right approach. How to Find Your OTTO Pixel Code Log in to your Search Atlas account and locate your site-specific OTTO pixel snippet inside your project settings. If you are unsure where to find your pixel code, contact our support team and they will guide you to the correct screen. Method 1: Direct Pixel Installation Using useEffect The safest way to load the OTTO pixel directly in a Next.js project is to use the useEffect hook, which only runs in the browser after the component has mounted. This prevents any server-side execution. 1. Create or open a layout or page component where you want the pixel to load globally (for example, _app.js in the Pages Router, or your root layout.js in the App Router). 2. Import useEffect from React at the top of the file: import { useEffect } from 'react'; 3. Inside the component, add a useEffect block that creates a script element and appends it to the document body: - Create the script tag: const script = document.createElement('script'); - Set the src to your OTTO pixel URL: script.src = 'YOUR_OTTO_PIXEL_URL'; - Set it to load asynchronously: script.async = true; - Append it: document.body.appendChild(script); 4. Make sure the dependency array is empty ([]) so it runs only once after the initial render. 5. Save the file, then open your browser's developer console and confirm no hydration errors appear and the pixel fires as expected. Method 1 Alternative: Using next/script Next.js provides a built-in Script component from next/script that handles client-safe loading automatically. 1. Import the Script component: import Script from 'next/script'; 2. Add the Script component to your layout or page, setting the strategy prop to afterInteractive or lazyOnload. Both strategies ensure the script only runs in the browser after the page is interactive: <Script src="YOUR\_OTTO\_PIXEL\_URL" strategy="afterInteractive" /> 3. Verify in the browser developer console that no hydration errors appear and that the pixel fires correctly. Method 2: Installing via Google Tag Manager If you prefer to manage the OTTO pixel through GTM, the key is to load the GTM container itself in a browser-safe way within Next.js. 1. Retrieve your GTM container ID (formatted as GTM-XXXXXXX) from your Google Tag Manager account. 2. In your Next.js project, add the GTM snippet using the next/script Script component with strategy="afterInteractive" so it only runs in the browser. 3. Place the GTM <noscript> iframe fallback inside the <body> tag of your layout. 4. Inside GTM, configure your OTTO pixel as a Custom HTML tag set to fire on All Pages (or your preferred trigger). GTM tags fire in the browser by default, so no additional SSR guard is needed on the tag itself. 5. Publish your GTM container, then verify in the browser developer console and GTM Preview mode that the OTTO pixel fires without hydration errors. General Best Practices - Always load the OTTO pixel in a way that guarantees it only executes in the browser, not during server-side rendering. - If using GTM, ensure the GTM container tag is also loaded in a browser-safe manner within your Next.js project. - After installation, verify in your browser's developer console that no hydration errors appear and that the pixel fires as expected. Getting Help With Your Next.js Integration Because Next.js projects vary in structure (Pages Router vs. App Router, SSR vs. static export), the correct way to integrate the OTTO pixel depends on your specific setup. If you need tailored guidance, please reach out to our support team. Share details about your Next.js version and rendering approach so the team can advise you on the right integration method. If we were unable to resolve your issue, please contact our support team and we will be happy to help.

🛠️ GHL Keyword Gap Analysis CSV Export Returning an Empty File

The Keyword Gap Analysis CSV export bug that produced completely empty files — no headers, no data rows — on all four tabs has been resolved. Re-export your data now to receive a fully populated CSV. ⚠️ What the Issue Was Clicking Export on the Keyword Gap Analysis page in GHL downloaded a CSV file that was completely empty — no column headers and no data rows — regardless of which tab was active. The keyword data remained fully visible on screen but did not transfer to the exported file. Any exports downloaded while the bug was active should be re-downloaded to ensure the file contains complete data. 📋 Which Tabs Were Affected All four tabs on the Keyword Gap Analysis page returned empty CSV files during the affected period: - Keywords in Common - Keyword Opportunities - Unique Keywords - All Keywords Keyword Gap Analysis and CSV export are available to all accounts with Keyword Explorer access. 📊 How to Export Keyword Gap Analysis Data Now The export function is fully restored. To download your keyword data: 1. In the left sidebar, click Keyword Explorer, then select Keyword Gap Analysis from the sub-menu. 2. Select the tab you want to export: Keywords in Common, Keyword Opportunities, Unique Keywords, or All Keywords. 3. Click the Export button. 4. Save the CSV file to your device. The downloaded file now includes all column headers and data rows shown on screen. 🛠️ What to Do If the CSV Is Still Empty If a newly downloaded CSV still appears empty, try the following steps: - Refresh the Keyword Gap Analysis page and attempt the export again. - Confirm that data is visible on the selected tab before exporting — an empty table will always produce an empty file. - Clear your browser cache, then retry the export. - Switch to a different browser and attempt the export again to rule out a local caching issue. - If the issue persists after all steps above, contact Search Atlas Support with your account details and a screenshot of the empty file so the team can investigate. 🎯 The Keyword Gap Analysis CSV export now works correctly across all four tabs. If you previously downloaded an empty file, re-run your export to retrieve your complete keyword data — and reach out to Search Atlas support if any issues persist.

🛠️ Troubleshooting the Contentful CMS Connector: Invalid or Expired Management API Token

🔧 Contentful Connector Authentication If your Contentful connector reports an invalid or expired Management API token, verify the token, Space ID, and permissions shown in your current Search Atlas connector setup. 🔍 Common causes - The token was revoked or regenerated in Contentful. - The Contentful user who created the token was removed or had permissions reduced. - The token does not have access to the selected Space, content types, or assets. - The Space ID in Search Atlas does not match the selected Contentful Space. - The token was copied with missing characters or extra whitespace. 🛠️ Troubleshooting 1. In Contentful, confirm that the token is active and has access to the target Space. 2. Confirm the Space ID in Search Atlas matches the Contentful Space. 3. In Search Atlas, open Settings → CMS Connectors and select the affected Contentful connector. 4. Follow the connection fields and actions currently displayed in the Search Atlas interface. 5. Save the connection and check whether its status becomes active. If the connector remains invalid, contact support with the exact error, Space ID, and a screenshot. Do not share the token itself. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate.

🔧 How to Fix WordPress and Rank Math Conflicts with OTTO SEO

Why WordPress and Rank Math Conflicts Happen When Search Atlas generates content and syncs it to your WordPress site, the Rank Math SEO plugin can sometimes interfere with how titles, meta descriptions, and other SEO data are displayed. This happens because Rank Math applies its own templates and rules that may override the SEO data Search Atlas sends to WordPress. Common symptoms include: - Titles or meta descriptions not matching what was generated in Search Atlas - Rank Math displaying warnings or errors about title length or duplicate meta tags - SEO data appearing differently on your live WordPress pages than expected General Troubleshooting Steps If you are experiencing conflicts between Search Atlas content and Rank Math, try these steps: - Check whether Rank Math has global title or meta templates enabled that may be overriding the SEO data synced from Search Atlas. - Review the SEO settings on individual WordPress posts or pages to see if Rank Math has modified what was published. - Verify that your WordPress connection in Search Atlas is active and syncing correctly by re-publishing or re-syncing the affected content. - If you recently installed or updated Rank Math, note whether the issue started after that change. - Clear your WordPress site cache after any changes to ensure updated SEO data is served correctly. Information to Have Ready When Contacting Support If the conflict persists, gathering the following details will help our team investigate and resolve the issue efficiently: - The name or URL of the affected WordPress site - The specific Search Atlas project or article experiencing the issue - Screenshots or a description of what Rank Math is displaying versus what Search Atlas generated - The version of Rank Math installed on your WordPress site - The approximate date and time when you first noticed the conflict 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.

🔌 Fix WordPress Plugin Unengaged Status & Errors

🔍 What Does "Unengaged" Mean? When your Search Atlas WordPress plugin shows an Unengaged status, it means the plugin is installed on your site but has not successfully established an active, verified connection with your Search Atlas account. This is different from a failed installation — the plugin is present, but the handshake between your site and Search Atlas is incomplete. ⚠️ Common Causes of the Unengaged Status - Incorrect API key or token: The credentials entered during setup do not match your Search Atlas account. - Plugin version mismatch: An outdated version of the plugin may not communicate correctly with the Search Atlas platform. - Caching interference: Server-side or plugin-based caches can block the authentication request from completing. - Conflicting plugins: Security plugins, firewall plugins, or other SEO tools can intercept or block outbound API calls. - PHP or server restrictions: Some hosting environments restrict external HTTP requests, preventing the plugin from reaching Search Atlas servers. - WordPress site URL mismatch: If your WordPress address and site address settings differ, authentication may fail silently. 🛠️ Step-by-Step Troubleshooting 1. Verify your API credentials. In Search Atlas, go to Settings > Integrations > WordPress and copy your API key. In your WordPress dashboard, navigate to Search Atlas Plugin > Settings, paste the key, and save. Double-check there are no extra spaces before or after the key. 2. Update the plugin. Go to WordPress Dashboard > Plugins > Installed Plugins, find Search Atlas, and click Update if a newer version is available. Always use the latest version to ensure compatibility. 3. Deactivate, then reactivate the plugin. In Installed Plugins, click Deactivate next to Search Atlas, wait 10 seconds, then click Activate again. Re-enter your API key and save. 4. Clear all caches. Purge your WordPress caching plugin (e.g., WP Rocket, W3 Total Cache, LiteSpeed Cache) and clear your hosting provider's server cache. Then retry the connection. 5. Check for plugin conflicts. Temporarily deactivate security or firewall plugins such as Wordfence, iThemes Security, or All In One WP Security. Attempt to authenticate again. If it works, whitelist the Search Atlas domain in your security plugin settings and re-enable it. 6. Confirm your WordPress URL settings. In WordPress Dashboard > Settings > General, ensure the WordPress Address (URL) and Site Address (URL) fields are identical and use the correct protocol (https:// if SSL is enabled). 7. Test external HTTP requests. Ask your hosting provider whether outbound HTTP requests to external APIs are allowed. Some managed hosting plans restrict this by default. Request that they whitelist Search Atlas API endpoints if needed. 8. Reinstall the plugin cleanly. Deactivate and delete the plugin, then download the latest version from Search Atlas and reinstall it via Plugins > Add New > Upload Plugin. Re-enter your credentials after reinstallation. ✅ How to Confirm the Plugin Is Now Engaged After completing the steps above, return to your Search Atlas dashboard and navigate to Settings > Integrations > WordPress. Your site should now display a green Engaged status. If you see this, the connection is active and data will begin syncing automatically. 💡 Tips to Prevent Future Issues - Always keep the Search Atlas plugin updated to the latest version. - After any major WordPress core update, re-check the plugin status in Search Atlas. - Avoid using multiple SEO plugins simultaneously, as they can conflict with each other. - If you migrate your WordPress site to a new domain or host, re-authenticate the plugin immediately after the move. 🆘 Still Showing Unengaged? If you have followed all the steps above and the plugin still shows an Unengaged status or persistent errors, our team is ready to help. 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.

🔌 Fix OTTO Pixel WordPress Plugin Configuration

🔍 Overview The OTTO Pixel plugin connects your WordPress site to Search Atlas so OTTO can read your site's structure and deploy SEO optimizations automatically. If the integration is not working, the most common cause is one or more required checkboxes being disabled in the plugin's settings. This article walks you through the correct configuration. ✅ Before You Begin - Make sure you have the OTTO Pixel plugin installed and activated on your WordPress site. - Confirm you are logged in to Search Atlas with an account that has access to OTTO SEO (Left sidebar → OTTO SEO → SEO Automation). - Have your WordPress admin dashboard open in a separate tab so you can switch between both screens. ⚙️ Step 1 — Open the OTTO Pixel Plugin Settings 1. Log in to your WordPress admin dashboard. 2. In the left-hand menu, locate Search Atlas → Settings and click it to open the plugin settings page. 3. You will see a settings panel with several configuration checkboxes and your connection status. ☑️ Step 2 — Enable All Required Checkboxes Each checkbox controls a specific permission that OTTO needs to communicate with your site. Leaving any of these unchecked is the most frequent reason the integration fails. - Search Atlas API Key — Enter your API key here (or use One-Click Authentication to connect). - OTTO Pixel UUID — Enter your OTTO Pixel UUID so the plugin knows which OTTO project to connect to. - Disable OTTO for Logged in Users — Optional. Enable this to turn OTTO off while logged in so you can edit original content. Enable every checkbox that corresponds to the OTTO features you have activated inside Search Atlas. If you are unsure, enabling all checkboxes is safe and recommended for full functionality. 💾 Step 3 — Save Your Settings 1. After enabling all required checkboxes, scroll to the bottom of the plugin settings page. 2. Click Save Settings (or Update, depending on your plugin version). 3. Wait for the confirmation message confirming your settings have been saved. 🔄 Step 4 — Verify the Connection in Search Atlas 1. Return to Search Atlas and navigate to OTTO SEO in the left sidebar, then open SEO Automation. 2. Open your project and check the OTTO connection status indicator at the top of the page. 3. The status should now show as Connected or Active. 4. If OTTO was previously paused or showing an error, click Activate OTTO to restart the automation. 🛠️ Common Issues and Fixes - Plugin shows "Connected" but changes are not deploying: Double-check that the specific checkboxes for the features you are using (e.g., Schema, Meta Tags) are enabled, not just the master toggle. - Checkboxes revert after saving: A conflicting security plugin or caching plugin may be blocking the save. Temporarily disable caching, save the settings again, then re-enable your cache. - Connection status remains "Disconnected" after completing all steps: Clear your WordPress site cache and your browser cache, then reload both the plugin settings page and the Search Atlas OTTO SEO page. - OTTO Pixel plugin not visible in WordPress menu: The plugin may not be activated. Go to Plugins → Installed Plugins, find OTTO Pixel, and click Activate. 💡 Best Practices - After any WordPress core update or plugin update, revisit the OTTO Pixel settings to confirm all checkboxes are still enabled. - Keep the OTTO Pixel plugin updated to the latest version to ensure compatibility with new Search Atlas features. - If you manage multiple WordPress sites, repeat this configuration process for each site individually. 🙋 Need More Help? 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.

🛠️ Troubleshooting Deployed Changes Not Reflecting in Shopify

This article explains the difference between a change being deployed within Search Atlas and that change being written to your live Shopify store — and walks you through what to check if your storefront has not updated after a deployment. 🔍 What Does 'Deployed' Actually Mean? In Search Atlas, deploying a change marks it as approved and ready to be pushed to your connected platform. However, deployment within Search Atlas does not always mean the change has been instantly written to Shopify. The two stages are distinct: - Deployed in Search Atlas: The change has been confirmed and queued on the Search Atlas side. - Written to Shopify: The change has been successfully transmitted to and accepted by your Shopify store via the integration. If your Shopify storefront does not reflect the change, it most likely means the write to Shopify is pending, failed silently, or the integration requires attention. 🛠️ Step-by-Step 1. Confirm the deployment status inside Search Atlas. Open the relevant project or optimization task and look for a status indicator next to the deployed item. A status such as "Deployed" or "Published" on the Search Atlas side confirms it was queued — but does not confirm Shopify received it. 2. Check whether your Shopify integration is active and authenticated. Open your project settings and navigate to the integrations or connected platforms area. Verify that your Shopify store is still connected, that the access token has not expired, and that no disconnection notice is shown. 3. Re-authorize the integration if needed. If the connection shows as expired or disconnected, follow the prompts to reconnect your Shopify store. After reconnecting, attempt to redeploy the change. 4. Redeploy the specific change. Once you have confirmed the integration is healthy, locate the item that was previously deployed and use the available option to push or redeploy it to Shopify. This forces a fresh write attempt. 5. Allow propagation time. After a successful write, Shopify may take a few minutes to reflect meta field updates, title or description changes, or other on-page edits depending on your store's cache and theme settings. Wait at least 5 minutes before concluding the change did not apply. ✅ How to Confirm It Worked To verify that your changes have been successfully written to Shopify — not just deployed in Search Atlas — check the following: - Visit the affected product, collection, or page directly in your Shopify admin and confirm the updated title, meta description, or content field matches what you deployed from Search Atlas. - Open the live URL of the affected page in a browser (use an incognito window to bypass cache) and inspect the page source or use a browser extension to confirm the updated meta tags are present in the HTML. - If Search Atlas shows a post-deployment status update (such as a confirmation timestamp or a "Synced" indicator), that is the most reliable signal that the write to Shopify completed successfully. 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. Additional Notes When escalating to support, have ready: your project name, the specific URL(s) of affected Shopify pages/products/collections, the exact status shown in Search Atlas (e.g., Deployed, Pending), and any error messages received. Also: check the specific resource directly in Shopify admin to verify if SEO field values are present.

🛠️ Fix OTTO Pixel Installation Issues on Wix

🔍 Overview The OTTO pixel is a small tracking script that allows Search Atlas to analyse your site and automate SEO improvements. Wix has a unique site structure that requires specific steps to install the pixel correctly. If your pixel is not firing, this guide explains the general approach and what to have ready when contacting support. ⚙️ Before You Begin Make sure you have the following ready before starting: - Admin access to your Wix account and your Search Atlas account. - Your OTTO pixel code, found inside the Search Atlas platform in the OTTO or SEO settings area. - A published (live) Wix site — the pixel cannot be verified on an unpublished site. 📋 Step 1: Copy Your OTTO Pixel Code 1. Log in to Search Atlas and locate the OTTO pixel code for your connected website. Refer to the in-platform instructions or tooltips for the exact location, as the navigation path may vary by account. 2. Copy the full pixel code without modifying it. 🖥️ Step 2: Add the Pixel to Wix Using Custom Code Wix does not allow direct file access, so you must use Wix's built-in custom code injection feature to add the pixel. The exact menu path may differ depending on your Wix plan and dashboard version — consult the Wix Help Center for the most current instructions on adding custom code to your site. 1. Log in to your Wix account and open your site's Dashboard. 2. Find the custom code or tracking tools section in your Wix settings. 3. Add a new custom code snippet and paste your OTTO pixel code into the code box. 4. Give the snippet a recognisable name, for example: OTTO SEO Pixel. 5. Set the snippet to load on All Pages in the Head section. 6. Save your changes. 🚀 Step 3: Publish Your Wix Site Changes made in the Wix Dashboard do not go live automatically. You must publish your site after adding custom code, otherwise the pixel will not fire. 1. Return to your Wix Editor or Dashboard. 2. Click the Publish button to push your changes live. 3. Wait for Wix to confirm the site is live before attempting to verify the pixel in Search Atlas. ✅ Step 4: Verify the Pixel Is Firing 1. Return to Search Atlas and navigate to your OTTO or pixel settings for the connected website. 2. Use the available pixel status or verification feature to check whether the pixel is detected on your live site. Refer to in-platform guidance for the exact option name, as the interface may be updated over time. ⚠️ Common Issues and Fixes - Pixel not detected after verification: Confirm you published your Wix site after saving the custom code. Verification checks the live version of your site, not the draft. - Code saved but pixel still not firing: Double-check that the snippet is set to load on All Pages and is placed in the Head section, then republish your site. - Unsure where to find the pixel code in Search Atlas: Contact our support team with your project name and the connected website URL so we can confirm the correct location for your account. 📞 Still Need Help? If you are unable to resolve the pixel installation issue using the steps above, please have the following ready before reaching out: - Your Search Atlas project name and the URL of your Wix site. - A description of what you have already tried. - Any error messages or screenshots showing the current pixel status. 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.

🔗 Fix 'No Project Associated' GSC Connection Error

🔍 Overview When connecting your Google Search Console (GSC) account to Search Atlas, you may see a message stating that your GSC account does not have any project associated with it. This error does not mean your GSC account is broken or that your permissions are incorrect. It simply means your GSC property has not yet been linked to a project inside Search Atlas. ⚠️ Why This Happens Search Atlas requires an active project to be associated with your connected GSC property before it can pull data. If no project is linked, the platform has nothing to map the GSC data to, and you will see the 'no project associated' error. This commonly occurs when: - You have just connected your GSC account for the first time and have not yet selected or created a project. - Your previously linked project was deleted or renamed. - You connected a new GSC property but skipped the project association step. ✅ How to Resolve This Error To fix this error, you need to make sure your GSC property is associated with a project in Search Atlas. Here is what to do: 1. Log in to your Search Atlas account. 2. Navigate to the GSC connection or integration settings within your account (the exact location may vary depending on your plan and interface version). 3. Check whether a project has been assigned to your connected GSC property. If no project is linked, look for an option to select or assign an existing project. 4. If you do not have a project yet, create one first — a project must exist before the association can be made. Make sure the project's domain matches the GSC property you are connecting. 5. Once you have selected or confirmed the correct project, save your changes and return to the GSC data view. The error should no longer appear and your data should begin populating. 📋 What to Check Before Starting To make sure the steps above go smoothly, confirm the following before you begin: - GSC account is connected: Your Google Search Console account must already be authorised inside Search Atlas. If you have not connected it yet, complete the GSC authorisation in your account settings first, then follow the steps above. - You have at least one project: A project must exist in Search Atlas for the association to work. If you do not have a project yet, create one before attempting to link your GSC property. - Correct GSC property: Make sure the GSC property you are connecting matches the domain of the project you are assigning it to. Mismatched domains will result in empty or incorrect data. 🛠️ If You Are Still Seeing the Error If you have followed the steps above and the error persists, it is best to contact our support team directly so they can verify your account configuration and GSC connection status. When reaching out, please have the following ready: - The name of the project you are trying to associate with your GSC property. - The GSC property URL (e.g. the domain or URL prefix you verified in Google Search Console). - A screenshot of the exact error message you are seeing, including any error codes or additional text displayed. 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.

🛠️ Fix OTTO Pixel Squarespace Installation Issues

🔍 Why Your OTTO Pixel May Show 'Not Installed Correctly' After adding the OTTO pixel to your Squarespace site, the verification check may still return a not installed correctly status. This is a common issue and is almost always caused by one of a few specific configuration mistakes in Squarespace's header injection settings. This article walks you through every step to confirm your pixel is placed and verified correctly. ⚙️ How the OTTO Pixel Verification Works When you click Verify inside Search Atlas, OTTO sends a request to crawl your live Squarespace site and look for your unique pixel code in the page source. If the pixel is missing, blocked, or placed in the wrong location, verification will fail. It does not check your Squarespace editor — it checks your published, live site. ✅ Step-by-Step: Correct Pixel Installation in Squarespace 1. Log in to your Squarespace account and open your site editor. 2. In the left sidebar, go to Settings → Advanced → Code Injection. 3. Paste your OTTO pixel snippet into the Header field only. Do not place it in the Footer or any other field. 4. Click Save in Squarespace before returning to Search Atlas. 5. In Search Atlas, navigate to OTTO SEO in the left sidebar, then open SEO Automation (URL: /seo-automation-v3). 6. Locate your connected site, then click Verify to re-run the installation check. 🚫 Common Reasons Verification Fails - Page not published: Squarespace only injects header code on published pages. If your site is in trial mode or password-protected, the crawler cannot access the pixel. - Password protection enabled: A site-wide or page-level password blocks the OTTO crawler. Temporarily disable password protection, verify the pixel, then re-enable it. - Changes not saved: Squarespace requires an explicit Save after adding code. Navigating away without saving discards the pixel. - Pixel placed in the wrong field: Placing the snippet in the Footer or a page-specific injection area instead of the global Header field can cause verification to fail. - Duplicate or edited pixel code: Copy the pixel directly from Search Atlas each time. Do not retype it or modify any characters — even a single extra space can break detection. - Caching delay: Squarespace may cache pages for a few minutes after saving. Wait 2–3 minutes after saving, then click Verify again. 🔎 How to Confirm the Pixel Is Live on Your Site Before clicking Verify in Search Atlas, manually confirm the pixel is visible in your published site's source code: 1. Open your live Squarespace site in a browser (not the editor). 2. Right-click anywhere on the page and select View Page Source. 3. Press Ctrl+F (or Cmd+F on Mac) and search for otto or the first few characters of your pixel snippet. 4. If you can find the pixel in the source code, your installation is correct — return to Search Atlas and click Verify. 5. If you cannot find the pixel, revisit the Code Injection steps above and ensure the snippet was saved in the Header field. 💡 Tips for a Smooth Verification - Always copy your pixel code fresh from the Search Atlas dashboard to avoid stale or corrupted snippets. - Use an incognito or private browser window when viewing your page source to avoid cached versions. - If your Squarespace plan does not include Code Injection (available on Business plans and above), you will need to upgrade your Squarespace plan before the pixel can be installed. - After a successful verification, avoid editing or removing the pixel code from Squarespace — doing so will disconnect OTTO from your site. 🆘 Still Showing 'Not Installed Correctly'? If you have followed every step above and verification still fails, there may be a plan-level restriction, a Squarespace-side caching issue, or a less common configuration conflict on your account. 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.

🔗 GoHighLevel Integration: Page Optimization Limit Errors

🧭 Overview If you recently connected your Search Atlas account through GoHighLevel (GHL) and immediately see a 'You've reached the limit to optimize this page' error, your account is most likely still being provisioned. This is a temporary condition that resolves on its own in most cases — no subscription upgrade is required. This article explains why the error appears, what to expect during setup, and the steps you can take right now to resolve it. ⚠️ Why This Error Appears on New GHL Accounts When you create a Search Atlas account through a GoHighLevel integration, your account goes through an automated provisioning process. During this window, your plan limits and feature entitlements are still being configured in the background. Until provisioning is fully complete, the platform may temporarily read your page optimization quota as zero — even on a paid plan — which triggers the limit error. This is a known behaviour specific to GHL-integrated accounts and is not a billing issue or a sign that your plan is incorrect. ⏱️ Typical Provisioning Timeline In the majority of cases, provisioning completes automatically within the following timeframes: - 5–15 minutes: Most accounts are fully provisioned and the error clears on its own. - 15–30 minutes: Accounts created during high-traffic periods may take slightly longer. - Over 30 minutes: If the error persists beyond 30 minutes, manual intervention may be needed (see the section below). We recommend waiting at least 30 minutes after account creation before taking further troubleshooting steps. 🛠️ Troubleshooting Steps 1. Wait and refresh. Allow 15–30 minutes after your account was created, then do a hard refresh of your browser (Ctrl + Shift + R on Windows or Cmd + Shift + R on Mac). 2. Log out and log back in. Sign out of Search Atlas completely, then sign back in. This forces the platform to re-read your current plan entitlements. 3. Clear your browser cache. Cached session data can sometimes cause outdated limit values to persist. Clear your cache, then log in again. 4. Try a different browser or incognito window. This rules out any local browser extension or cache conflicts. 5. Verify your plan in account settings. Confirm that your paid plan is showing correctly under your account profile. If the plan appears as free or inactive, your GHL provisioning may not have completed successfully. 6. Attempt the optimization again. Navigate to Left sidebar → Content → On-Page Audit, select your target page, and try running the optimization. If your account is now fully provisioned, the error will no longer appear. 📋 When to Contact GoHighLevel Support vs. Waiting Use the guidance below to decide whether to wait or escalate: - Wait it out if your account was created less than 30 minutes ago and you have not yet tried logging out and back in. - Contact GoHighLevel support if your account was created more than 30 minutes ago, you have completed all troubleshooting steps above, and your plan still appears inactive or incorrectly provisioned inside GHL's dashboard. GHL support can verify that the agency-level seat or sub-account was activated correctly on their end. - Contact Search Atlas support (via the chat widget below) if your GHL plan appears active and correct inside GoHighLevel but the limit error continues inside Search Atlas after 30 minutes and after completing all troubleshooting steps. ✅ Confirming the Issue Is Resolved Once provisioning is complete, you should be able to: - Run page optimizations from Left sidebar → Content → On-Page Audit without seeing the limit error. - See your correct plan quota reflected in your account settings. - Access all other content tools — including Content Planner, Meta Generator, AI Content Templates, and Topical Maps — in line with your paid plan. 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.

⏳ OTTO Pixel Not Detected After GTM Install

🔍 Overview If you have installed the OTTO pixel through Google Tag Manager (GTM) and can confirm it appears in your page source, but OTTO still shows the pixel as undetected, this is expected behavior in most cases. The initial site audit crawl can take some time before OTTO registers and confirms pixel detection. No additional troubleshooting is needed during this window. ⏱️ Why Detection May Be Delayed When OTTO is connected to a site for the first time, it runs a full site audit crawl before it begins processing pixel data. This crawl is required to map your site structure and establish a baseline. Until this initial audit is complete, OTTO will not reflect pixel detection status — even if the pixel is correctly installed and firing on your pages. This is normal, expected behavior and not an error. The delay applies to all new site connections, regardless of how the pixel was installed. ✅ How to Confirm Your Pixel Is Installed Correctly While you wait for the audit to complete, verify your installation is correct by checking the following: 1. Open your website in a browser and right-click anywhere on the page, then select View Page Source. 2. Use Ctrl+F (or Cmd+F on Mac) to search for your OTTO pixel ID or the pixel script snippet. 3. Confirm the script is present in the source code. 4. Open your GTM account and confirm the pixel tag is set to fire on All Pages (or the correct trigger for your setup). 5. Use the GTM Preview mode to verify the tag fires on page load without errors. If the pixel appears in your page source and fires correctly in GTM Preview, your installation is complete. You simply need to wait for the site audit crawl to finish. 📍 Where to Check Pixel Status in Search Atlas You can monitor your pixel detection status inside the Search Atlas platform by navigating to the OTTO section and locating your connected site. Once the initial audit completes, the status will update automatically — no manual refresh or resubmission is required. 🚩 When to Take Further Action In most cases, waiting for the initial audit to complete resolves the detection delay. However, take further action if any of the following apply: - A significant amount of time has passed and the pixel status still shows as undetected. - The pixel script does not appear in your page source after publishing your GTM container. - GTM Preview mode shows the tag is not firing or is returning an error. - You published changes in GTM but forgot to submit the container — unpublished GTM changes do not go live on your site. If the pixel is missing from your page source, return to GTM and verify your tag configuration, trigger settings, and that the container has been submitted and published. If you have confirmed the pixel is present and firing correctly but detection still has not updated after an extended wait, please reach out for support and have the following ready: your site URL, your GTM container ID, and a screenshot of the pixel tag firing in GTM Preview mode. 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.

Fix 404 Errors After SA Plugin Update

🔍 What Is Happening After activating or updating the Search Atlas WordPress plugin, some sites experience 404 errors on pages across the site. The rest of the site may appear to go offline even though no content has been deleted. This issue has been reported in connection with plugin updates, including v2.6.11. If you are seeing sitewide 404 errors following a Search Atlas plugin update, the steps below are the recommended starting points for resolving the problem. If self-service steps do not resolve the issue, please contact our support team for further investigation. ✅ Steps to Try The following steps address common causes of sitewide 404 errors in WordPress after a plugin update. Work through them in order. 1. Log in to your WordPress admin dashboard. 2. In the left-hand menu, go to Settings, then click Permalinks. 3. Without changing any settings, scroll to the bottom of the page and click Save Changes. 4. Reload any page on your site that was previously returning a 404 error to confirm it is now accessible. 5. If the issue persists, go to Plugins in your WordPress dashboard, deactivate the Search Atlas plugin, then reactivate it. Immediately re-save your permalink settings afterward (repeat steps 2–4). 6. If your site is on a managed WordPress host (such as WP Engine, Kinsta, or Flywheel), use your host's cache-clearing tool after saving permalink settings, as some hosts cache rewrite rules aggressively. 7. In your WordPress dashboard, go to Plugins and check the version number listed under the Search Atlas plugin. If an update is available, apply it and then re-save permalink settings. 🚫 What Not to Do - Do not delete and reinstall the plugin without first saving a note of your existing plugin settings, as reinstalling may reset your configuration. - Do not restore a full site backup unless all other steps have failed and support has advised it. 💬 Still Experiencing 404 Errors? If the steps above do not resolve the issue, please reach out to our support team with details about your hosting environment and the plugin version you are running. We're happy to investigate further.

🛠️ WordPress Plugin Update Breaking Site CSS or Layout

🔍 Overview Following certain Search Atlas WordPress plugin updates, some users have reported visual rendering issues on client sites — including disappearing CSS backgrounds, squished column widths, and homepage content not displaying correctly. These issues have been linked to specific plugin versions and have been resolved by the Search Atlas WordPress team in previous cases. ⚠️ Known Affected Scenarios - CSS background images disappearing after a plugin update - Column widths becoming distorted or compressed - Homepage content failing to render while the plugin is active - Layout changes occurring specifically when the Search Atlas plugin is enabled These issues have been documented and resolved in multiple engineering cases across various plugin versions. 🚀 Immediate Steps to Try First 1. Clear your site cache. After any plugin update, caching layers can serve outdated CSS. Clear your WordPress cache plugin, server-level cache, and CDN cache (if applicable), then reload the affected page. 2. Check which plugin version is installed. In your WordPress admin dashboard, go to Plugins → Installed Plugins and confirm you are running the latest available version of the Search Atlas plugin. If a newer version is available, update it. 3. Deactivate and reactivate the plugin. Deactivating the Search Atlas plugin temporarily will confirm whether it is the direct cause of the layout issue. If the layout restores after deactivation, the plugin is the source of the conflict. 4. Test on a staging environment first. Before applying any future plugin updates to live client sites, test the update on a staging or development copy of the site to catch CSS conflicts before they affect production. 📋 If the Issue Persists After Clearing Cache If clearing your cache and updating to the latest plugin version does not resolve the layout issue, the problem likely requires backend investigation by the Search Atlas WordPress team. To get this resolved as quickly as possible, have the following ready before contacting support: - The URL of the affected site or sites - The Search Atlas plugin version currently installed - A brief description of the visual issue (e.g., background missing, columns squished) - WordPress admin credentials so the team can access and diagnose the site directly - The approximate date the issue first appeared In previous cases, support agents accessed affected sites directly, escalated to the WordPress engineering team, and applied fixes — after which cache clearing resolved the remaining visual artifacts. 💡 Prevention Tips - Always test plugin updates on staging before deploying to live client sites, especially immediately after a new plugin version is released.

🔌 Fix WordPress Plugin UUID Error After Project Recreation

🧭 Overview If your Search Atlas WordPress plugin is showing an incorrect UUID error even though the UUID in your plugin settings matches the one shown in your Search Atlas dashboard, the issue is almost certainly caused by project deletion and recreation. When a project is deleted and a new one is created, the old UUID can leave behind an orphaned cache or backend state — causing the plugin to reject an otherwise valid UUID. This article walks you through the exact steps to clear that stale state and restore the connection. ⚠️ Why This Happens The standard UUID mismatch fix (copy-pasting the correct UUID) works when the two values genuinely differ. However, if you have recently deleted a project and recreated it, the new project receives a brand-new UUID. Even though you update the plugin with the new UUID, the plugin or platform backend may still be holding a cached reference to the old, now-deleted project. This causes the incorrect UUID error to persist despite both values appearing identical. ✅ Before You Begin Confirm the following before proceeding: - You have deleted a project in Search Atlas and created a replacement project. - You have already copied the new project UUID into your WordPress plugin settings. - The UUID shown in the plugin settings and the Search Atlas dashboard are visually identical. - The incorrect UUID error is still appearing. If all four points are true, follow the steps below. 🛠️ Step-by-Step Fix 1. Confirm the correct UUID in Search Atlas. Log in to Search Atlas and navigate to the project you want to connect. Copy the full UUID exactly as shown — including any hyphens. Do not copy from a saved note; always copy directly from the dashboard to avoid invisible characters. 2. Deactivate the Search Atlas WordPress plugin. In your WordPress admin panel, go to Plugins → Installed Plugins, find the Search Atlas plugin, and click Deactivate. 3. Clear all plugin data and cache. After deactivating, click Delete on the Search Atlas plugin. When prompted, confirm that you want to delete the plugin and its data. This removes any locally stored UUID cache or stale configuration tied to the old project. 4. Clear your WordPress site cache. If you are using a caching plugin such as WP Rocket, W3 Total Cache, or LiteSpeed Cache, purge all caches now. Also clear any server-level or CDN cache if applicable. 5. Reinstall the Search Atlas WordPress plugin. Download the latest version of the plugin from your Search Atlas dashboard or the WordPress plugin repository, and install it fresh. 6. Enter the new UUID. During setup, paste the UUID you copied in Step 1 into the plugin's UUID field. Save your settings. 7. Verify the connection. Check that the plugin status shows as connected and that the incorrect UUID error no longer appears. 🔄 If the Error Still Persists In rare cases, the stale backend state may need to be cleared on the Search Atlas side rather than the WordPress side. Try the following additional steps: - Disconnect and reconnect the project. Inside Search Atlas, navigate to your project settings and look for an option to disconnect or reset the WordPress integration, then reconnect it. - Wait 5–10 minutes. After reconnecting, backend cache propagation can take a few minutes. Refresh both the plugin settings page and the Search Atlas dashboard before testing again. - Try a different browser or incognito window. Browser-level caching can sometimes display outdated UUID values. Always confirm the UUID from a fresh session. 🚫 Common Mistakes to Avoid - Do not reuse UUIDs from deleted projects. Each new project generates a unique UUID. The old UUID is permanently invalidated when the project is deleted. - Do not update the UUID without deactivating the plugin first. Simply overwriting the UUID field in an active plugin may not flush the cached value. - Do not skip the cache-clearing step. This is the most frequently missed step and the primary reason the error continues after an apparent fix. 💬 Need More Help? 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.

🛠️ Fix OTTO Pixel Mobile Navigation Issues in GoHighLevel

🔍 Overview When the OTTO Pixel script is installed on a GoHighLevel (GHL) website, some customers notice that the mobile navigation bar disappears or stops working on the homepage. This happens because GoHighLevel's script loader can execute the OTTO Pixel asynchronously in a way that interferes with the page's navigation rendering. The fix is straightforward: adding the data-cfasync attribute to the OTTO Pixel script tag tells the page to handle the script correctly and prevents it from blocking or disrupting mobile navigation elements. ⚙️ Why This Happens GoHighLevel uses Cloudflare Rocket Loader to optimise page performance. Rocket Loader defers JavaScript execution to speed up load times. However, when it processes the OTTO Pixel script without proper instructions, it can interfere with scripts that control navigation menus — particularly on mobile viewports. Adding data-cfasync="false" to the OTTO Pixel script tag tells Cloudflare's Rocket Loader to skip deferring that specific script. This ensures the pixel fires correctly without disrupting other page elements like the navigation bar. 🚀 How to Fix the Issue 1. Log in to your GoHighLevel account and open the website or funnel where the OTTO Pixel is installed. 2. Navigate to the page settings or the custom code/header script section where your OTTO Pixel script tag is currently placed. 3. Locate the existing OTTO Pixel <script> tag. It will look similar to this: ​ Before (original script tag): <script src="https://your-otto-pixel-url.js"></script> After (corrected script tag): <script data-cfasync="false" src="https://your-otto-pixel-url.js"></script> 1. Add data-cfasync="false" as an attribute directly inside the opening <script> tag, before the src attribute. 2. Save your changes and publish the page. 3. Open the page on a mobile device or use your browser's mobile preview mode to confirm the navigation bar is displaying and functioning correctly. ✅ Where Exactly to Place the Attribute The data-cfasync="false" attribute must be placed inside the opening script tag of the OTTO Pixel — not in a separate tag, not above or below it. See the correct placement below: <script **data-cfasync="false"** src="https://your-otto-pixel-url.js"></script> If your OTTO Pixel script is an inline script (with the JavaScript code written directly between the tags rather than loaded from a URL), place the attribute the same way in the opening tag: <script **data-cfasync="false"**> /* your OTTO Pixel inline code here */ </script> 📊 Verify Your OTTO Pixel Is Still Active After making this change, confirm that the OTTO Pixel is still tracking correctly: - Go to Search Atlas and navigate to OTTO SEO in the left sidebar, then open SEO Automation inside it (or visit /seo-automation-v3). - Open the OTTO SEO dashboard for your connected website. - Check that the pixel status shows as Active or Connected. - If the status does not update within a few minutes, hard-refresh the page and check again. 💡 Tips to Avoid This Issue - Always add data-cfasync="false" to the OTTO Pixel tag at the time of installation on any GoHighLevel site. - If you manage multiple GHL sites with OTTO Pixel installed, audit each one to confirm the attribute is present. - Test your pages on mobile after any script changes to catch navigation issues early. - Rocket Loader is enabled by default on most Cloudflare-connected sites — this fix applies any time you see navigation disruption after adding a new script. 🆘 Still Seeing Issues? If your mobile navigation is still broken after adding the data-cfasync="false" attribute, or if the OTTO Pixel status is not showing as active, 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.

🔍 URL Indexation Batch Failures and Quota Refunds

🗺️ Overview If you submitted URLs for indexation and saw little to no results after several weeks, you are not alone. Indexation is influenced by factors both inside and outside Search Atlas, including Google's own crawl and index decisions. This article explains why batches can underperform, how our resubmission review process works, and how to get a resolution without losing quota unfairly. ⚠️ Why Did My Batch Produce So Few Indexed URLs? Submitting a URL for indexation does not guarantee that Google will index it immediately — or at all. Several factors can cause low indexation rates even after a successful submission: - Google's crawl budget: Google prioritises pages based on authority, site speed, and internal linking. Low-authority or thin pages are often deprioritised. - Content quality signals: Pages with duplicate, thin, or unoriginal content may be crawled but excluded from the index. - Technical issues: Noindex tags, canonicalisation conflicts, blocked robots.txt rules, or server errors can silently prevent indexation even after submission. - Google's processing queue: During periods of high demand, Google's indexing pipeline can take significantly longer than usual. Extended delays of several weeks or more are not uncommon. - Site-level trust: Newer domains or recently penalised sites face stricter scrutiny before pages are indexed. If your batch produced significantly fewer indexed URLs than expected over an extended period, your case may qualify for review under our resubmission and quota dispute process. 🔄 How the Resubmission and Quota Review Process Works Search Atlas reviews batches that underperform and handles quota disputes on a case-by-case basis. Here is what you should know: - Resubmission may be available: If your batch qualifies following review, our team can arrange a resubmission of the affected URLs. - Quota dispute review: If you believe quota was consumed incorrectly due to a batch failure, our support team can investigate and advise on the appropriate resolution. - Eligibility is assessed by our team: Cases where indexation results are significantly below expectations relative to the time elapsed are reviewed individually. Contact our team with your batch details to open a review. 🛠️ What to Have Ready When You Contact Support 1. Document your batch details. Note the batch submission dates, the number of URLs submitted, and the current number of indexed URLs (verify using Google Search Console or a site: search). 2. Check for technical blockers. Before resubmission, audit the affected URLs for noindex tags, canonical mismatches, robots.txt blocks, and server response codes. Fixing these issues first significantly improves resubmission outcomes. 3. Review your content quality. Ensure each submitted URL contains original, substantive content, as thin or duplicate pages are frequently excluded by Google regardless of submission status. 4. Gather your project name and any error messages. Having your project name, the exact batch or submission identifiers, and any error messages or notifications you received will help our team investigate your case efficiently. 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.

🏷️ Brand Vault Brands Missing or Duplicate Error

🔍 Overview Some users have reported that brands they previously added — such as custom domains or business names — no longer appear in Brand Vault. When attempting to re-add the missing brand, an error appears stating the brand already exists and to contact customer support. This article explains what causes this and what steps to take. ⚙️ What Causes This Issue This was a confirmed platform defect where Brand Vault brands that existed in the system were not being synced correctly to the brands page on load. As a result, brands appeared missing from your view even though the platform still held records for them — which is why re-adding them triggered a duplicate error. Engineering resolved this defect in a targeted fix that restores visibility of your existing brands. 🛠️ Steps to Resolve 1. Refresh your browser in incognito or private mode. Open a new incognito or private browsing window, log back into Search Atlas, and navigate to Brand Vault. This rules out any local browser caching as the cause. 2. Check whether your brands are now visible. Following the platform fix, your previously missing brands should appear in the Brand Vault list without any action needed on your part. Do not attempt to re-add a brand if the platform still returns the duplicate error — this will not create a new entry and may result in further confusion. 3. Wait a few minutes and hard-refresh if needed. If the brands do not appear immediately, wait two to three minutes, then do a hard refresh (Ctrl + Shift + R on Windows, Cmd + Shift + R on Mac) and check Brand Vault again. 4. Confirm the brands are fully functional. Once visible, verify that each brand is accessible and behaving as expected before resuming any work that depends on Brand Vault data. 📋 What to Expect Going Forward The underlying defect that caused brands to be hidden and blocked re-addition has been resolved. Your brands should now display correctly in Brand Vault without requiring any manual re-addition on your part. 💡 Still Seeing the Issue? If your brands are still missing or the duplicate error persists after following the steps above, this may indicate a separate account-specific issue that requires investigation. 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.

🔄 Fix Google Search Console Properties Not Connecting

🔍 Overview If you have connected your Google account to Search Atlas and can see your Google Search Console (GSC) properties listed, but are unable to select or connect the correct one, this is a known authentication state issue. The fix involves reconnecting your Google Search Console authentication in Search Atlas to trigger a fresh session. ⚠️ What Causes This Issue This problem occurs when your Google authentication session becomes partially stale or incomplete. Search Atlas can still read your property list from the existing session, which is why properties appear, but the connection required to link a specific property does not complete successfully. Simply reconnecting your Google account may not always reset this state — you may need to fully reauthenticate to establish a clean session. ✅ How to Fix It: Reconnect Your GSC Authentication 1. Log in to your Search Atlas account. 2. Navigate to the section of the platform where your Google Search Console connection is managed. 3. Disconnect or remove your existing Google Search Console connection. 4. Reconnect your Google account by going through the Google sign-in and permission flow again. When prompted, sign in with the Google account that owns or has access to the GSC property you want to connect. 5. Grant all requested permissions when prompted. Approving every permission Google lists helps ensure the connection completes successfully. 6. Once returned to Search Atlas, your properties should reload and you should now be able to select and connect the correct property. 💡 Tips to Ensure a Successful Connection - Use the correct Google account. Make sure you authenticate with the Google account that has verified owner or full user access to the GSC property. Restricted or delegated access accounts can sometimes cause partial failures. - Approve all permissions. If you skip or deny any permission during the Google OAuth flow, the connection may appear to succeed but will fail when selecting a property. - Avoid using browser autofill during OAuth. Autofill can pre-select the wrong Google account. Confirm the correct account is selected on Google's sign-in screen before proceeding. 🔁 Before Escalating If reconnecting your Google Search Console authentication does not resolve the issue, please have the following ready when you contact support: your Search Atlas project name, the GSC property URL you are trying to connect, the Google account email used during authentication, and a description of exactly where in the process the connection fails (for example, whether properties still do not appear, or whether a specific property still cannot be selected after reauthentication). 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.

🔄 CMS Connector Not Syncing Latest Article Versions to GHL

🔍 Overview If your CMS Connector is publishing older versions of your articles to GoHighLevel (GHL) — omitting recently added sections such as About the Author or Contact Us — you are not alone. This issue was reported by multiple users and was escalated to the Search Atlas engineering team for investigation. This article explains what to do if you are experiencing this problem and how to get further assistance if needed. ⚙️ What Caused the Problem Users reported that the CMS Connector was sending outdated article content to GHL, with recently added sections missing from the published output. This issue was escalated to the Search Atlas engineering team. If you are still experiencing this, please reach out to support so the team can investigate your specific account and configuration. ✅ Steps to Try 1. Open the affected article in Content Genius and confirm that all sections — including any recently added ones — are present and saved. 2. Republish the article to GHL using your usual publishing workflow. 3. Check the published result in GoHighLevel to confirm all sections are now appearing correctly. If the article now appears in GHL with all sections intact, the issue has resolved for your account. 🛠️ If You Are Still Experiencing the Issue If republishing does not resolve the problem and GHL is still receiving outdated content, try the following before contacting support: - Re-save your article: Open the affected article in Content Genius, make a minor edit and save it to ensure the latest version is recorded. - Republish: Attempt to publish to GHL again after saving. - Test with a new article: Create a short test article in Content Genius and publish it to GHL to determine whether the issue is isolated to specific articles or affects all publishing. 📋 Information to Have Ready If You Contact Support If the steps above do not resolve the issue, gathering the following details in advance will help the team investigate faster: - The name or URL of the specific article(s) affected - A screen recording or screenshots showing the article content in Content Genius versus what appears in GHL after publishing - The date and time you last republished the affected article Please reach out to the Search Atlas support team and we will be happy to assist you further.

🛠️ Fix WordPress Pixel Installation Error Messages

🔍 Overview If you see a "Pixel is not installed correctly" warning inside Search Atlas or OTTO, but your pixel appears to be pulling data successfully, this is almost always a verification timing issue — not a real installation problem. This article explains why this happens and what steps to take. 💡 Why This Warning Appears The pixel verification system runs an automated check to confirm your tracking pixel is live and properly placed on your WordPress site. This check can occasionally return a false-negative error due to the following reasons: - Caching: Your WordPress site or a caching plugin (such as WP Rocket, W3 Total Cache, or LiteSpeed Cache) may be serving an older cached version of your page that does not yet include the pixel code. - Verification delay: After installing the pixel, the system may need a few minutes to re-check and confirm the installation. The error message can persist briefly even when the pixel is live. - Plugin conflicts: Another WordPress plugin may be stripping or blocking third-party scripts before they render in the page source. - Cookie consent tools: If you use a cookie consent or GDPR compliance plugin, it may be blocking the pixel from firing until a user accepts cookies — causing the automated check to miss it. ⚙️ How to Troubleshoot Step by Step 1. Confirm data is flowing: If OTTO is already receiving data from your site, your pixel is functionally installed. The warning is likely a stale verification status. 2. Clear your site cache: Log in to your WordPress dashboard, open your caching plugin, and purge all cached files. If your hosting provider offers server-level caching (e.g., Kinsta, WP Engine), clear that cache too. 3. Check the pixel in your page source: Visit your website, right-click the page, and select View Page Source. Use Ctrl+F (or Cmd+F on Mac) to search for your pixel ID. If you can find it in the source code, the pixel is installed correctly. 4. Re-trigger the verification check: Inside Search Atlas, navigate to the pixel settings and click the option to re-verify or re-check your pixel installation. Allow 2–5 minutes for the system to complete the check. 5. Review cookie consent settings: If you use a GDPR or cookie consent plugin, make sure your pixel script is not categorised as a blocked or opt-in-only script. You may need to whitelist the Search Atlas pixel domain within your consent tool settings. 6. Deactivate plugins temporarily: To rule out a plugin conflict, temporarily deactivate other plugins one at a time (especially security or script-optimisation plugins) and re-check whether the pixel appears in your page source after each deactivation. 7. Check script placement: The Search Atlas WordPress plugin should automatically insert the pixel in the correct location. If you manually added the pixel code, verify it is placed inside the <head> section of your theme and not accidentally removed by a theme update. ✅ How to Confirm the Pixel Is Working Correctly Even while the error message is visible, you can confirm your pixel is operating normally by checking the following: - Data such as sessions, events, or conversion signals is actively appearing inside OTTO or your Search Atlas dashboard. - Your pixel ID is visible in the page source of your live website. - No JavaScript console errors related to the Search Atlas pixel appear when you open your browser's developer tools and visit your site. If all three conditions are true, your pixel is installed and working. The warning message will typically resolve itself once the automated verification re-runs successfully. 🚀 Prevent This Issue in the Future - Always clear your site cache immediately after installing or updating the Search Atlas WordPress plugin. - After any major WordPress update or theme change, re-verify your pixel inside Search Atlas to ensure nothing was disrupted. - Keep the Search Atlas WordPress plugin updated to the latest version to benefit from compatibility improvements. 🙋 Still Seeing the Error? If you have completed all the steps above and the "Pixel is not installed correctly" warning persists — especially if no data is flowing into OTTO — there may be a site-specific configuration issue that requires a closer look. 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.

Fix OTTO Pixel Not Detected After Installation

🧩 What Is the OTTO Pixel? The OTTO Pixel is a small JavaScript snippet that Search Atlas places on your website to verify site ownership and enable automated SEO actions. If the pixel is not detected, OTTO may be unable to activate certain features or run automatically. ⚠️ Why Diagnostics May Show "No Pixel Detected" Even when a webmaster believes the code has been added, diagnostics can still report no pixel for several reasons: - Partial deployment: The snippet was added to some pages but not all templates, so OTTO cannot confirm site-wide coverage. - Wrong placement: The code was not placed in the correct location as specified in the installation instructions. - Caching: A CDN, server cache, or plugin cache is serving an older version of the page that does not yet include the pixel. - Tag Manager misconfiguration: If installed via a tag manager, the tag may not be firing on all pages, or a cache issue is preventing the latest container from loading. - WAF or security plugin blocking: A Web Application Firewall or security plugin (e.g., Cloudflare, Wordfence) may be stripping or blocking the script before it reaches the browser. - Snippet placed inside a conditional block: The code is wrapped in a condition (e.g., logged-in users only) that prevents it from loading for crawlers. ✅ How to Verify the Pixel Is Installed Correctly 1. Locate your pixel snippet. Log in to Search Atlas and copy the pixel code provided for your site. 2. Check the page source. Visit your homepage in a browser, right-click, and select View Page Source. Press Ctrl+F (or Cmd+F) and search for otto or the first few characters of your pixel snippet. Confirm the code appears in the expected location. 3. Check a non-homepage URL. Repeat the page source check on an interior page (e.g., a blog post or service page). The pixel must be present on every page, not just the homepage. 4. Test in an incognito window. Caches and login states can hide issues. Open an incognito/private browser window and check the page source again to rule out browser caching. 5. Purge all caches. Clear your CDN cache, server-side cache, and any caching plugins (e.g., WP Rocket, W3 Total Cache). After purging, wait two to three minutes, then re-check the page source. 🏷️ Installing via a Tag Manager If your team used a tag manager instead of placing the code directly in the theme: - Confirm the OTTO Pixel tag is set to trigger on All Pages. - Publish the latest version of your container so the updated tag is live. - Clear any tag manager or CDN cache and verify the pixel appears in the page source. 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.

📧 Lead Notification Emails Missing Form Fields

🔍 Overview If you have set up custom recipient email addresses for lead notifications — for example, forwarding submissions to a client — you may notice that certain form fields (such as the type of service requested or the description a prospect filled in) are missing from the email body. You may also find that the link to view the full submission does not appear in emails sent to those custom recipients. This article explains why this happens and what has been done to resolve it. ⚙️ Why This Happens Lead notification emails were originally designed so that only the first two fields from a form submission are included in the email body. Any additional fields — regardless of how important they are to your workflow — were not carried through to the notification email. In addition, the View Full Submission link was only included in the email sent to you as the account owner. Custom recipients added to receive lead notifications did not receive this link, meaning they had no direct way to access the complete submission details. This was a platform-level limitation, not a configuration error on your account. It affected all custom recipient email addresses set up within the lead capture and notification system. ✅ What Has Been Fixed Our engineering team has addressed this issue. The resolution involved two specific improvements: - All form fields are now included in the email body of lead notifications, so recipients see the complete submission — including fields like type of service needed and any description the prospect provided. - The View Full Submission link is now available to custom recipients, not just the account owner, so everyone receiving a lead notification can access the full submission directly. If you were affected by this issue, your lead notification emails should now display all submitted fields and include the full submission link for every configured recipient. 🛠️ What You Should Do Now 1. Ask a prospect or a test contact to submit a form through your lead capture widget to generate a new notification email. 2. Check the inbox of each custom recipient address you have configured to confirm they now receive all form fields and the submission link. 3. If you are the account owner, verify that your own notification email is also complete and consistent with what custom recipients receive. 4. If any fields are still missing after a new test submission, note the specific field names and the recipient email address that did not receive them, then contact support using the instructions below. 💡 Tips for Custom Lead Notification Recipients - Only newly generated submissions (submitted after the fix was deployed) will reflect the updated email format. Older notification emails will not be retroactively updated. - If you manage multiple projects, test a form submission on each project that uses a custom recipient address, as settings can differ per project. - Ensure that custom recipient email addresses are correctly saved in your project settings to avoid notifications going to the wrong inbox. 🆘 Still Seeing Missing Fields? If you have tested with a new submission and fields are still absent from notification emails sent to custom recipients, the issue may be specific to your account configuration. 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.

🔧 How to Enable Meta Keywords CMS Sync

This article helps you resolve the issue where the meta keywords CMS sync toggle cannot be turned on. This is a specific setting that must meet a few conditions before it can be enabled, and the steps below walk you through each one so you can confirm the exact cause and get sync working. 🛠️ Step-by-Step 1. Confirm your CMS integration is connected and authenticated. CMS sync — for any field including meta keywords — requires an active, authorized connection to your CMS (e.g., WordPress, Shopify, or a custom integration). Open the top-right avatar → Settings → CMS Connectors and verify that your CMS integration shows a connected status with no authentication errors. If it shows disconnected or expired, reconnect it and try the toggle again. 2. Check that the meta keywords field is mapped in your CMS integration settings. Some CMS platforms do not expose a native meta keywords field, or the field may not be mapped in Search Atlas. In your CMS integration configuration, confirm that a meta keywords field is listed and mapped to a corresponding field in your CMS. If no mapping exists, add one — without a mapped field, the sync toggle will remain inactive. 3. Verify you have the correct permission level. CMS sync settings are typically restricted to account owners or admin-level users. If you are on a sub-user or collaborator seat, you may see the toggle but be unable to enable it. Ask your account owner to either enable the setting on your behalf or elevate your permission level. 4. Disable any conflicting sync rules. If another sync rule or automation is already managing the meta keywords field for the same content, the toggle may be locked to prevent conflicts. Review your active sync rules and disable or remove any that overlap with the meta keywords field, then attempt to enable the toggle again. 5. Save all pending changes before toggling. If you have unsaved edits open in the same content editor session, the sync toggle can appear unresponsive. Save or discard any pending changes first, then reload the page and attempt to enable the sync toggle. ✅ How to Confirm It Worked Once the toggle is successfully enabled, you should see it switch to an active or highlighted state without reverting when you navigate away. To verify end-to-end sync is working: save your content, then check your CMS directly and confirm the meta keywords field has been populated with the value from Search Atlas. If the field in your CMS remains empty after saving, re-examine the field mapping in your integration settings to ensure the correct destination field is selected. 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.

🔍 Verify OTTO Pixel on MoPro Sites

If you've installed the OTTO Pixel on a MoPro site and want to confirm it's working, this guide walks you through how to check the installation status, understand what each status means, and troubleshoot common issues. 🚀 What the OTTO Pixel Does The OTTO Pixel is a lightweight tracking script that connects your website to Search Atlas. It allows OTTO to monitor your site's SEO health, run automated optimizations, and report accurate data back to your dashboard. Without a verified pixel, OTTO cannot fully manage or analyze your site. ✅ How to Check Your Pixel Status To verify whether the OTTO Pixel is installed and detected on your MoPro site: 1. Log in to your Search Atlas account and navigate to your project. 2. Check whether the system has detected the pixel on your site. 3. If the pixel is not detected, follow the troubleshooting steps below. If your pixel is detected, it is installed correctly and no further action is needed. 🛠️ Understanding Detection Issues Sometimes the OTTO Pixel is installed but still shows as not detected. This can happen for several reasons: - Caching layers — CDNs like Cloudflare or other caching systems may serve a delayed or stale version of your pages. The pixel may be present but not yet reflected in the live scan. - Script-blocking plugins — Browser extensions or site security settings may block third-party scripts from loading. - Placement errors — The pixel code may have been added to the wrong section of your site or only on certain pages. - Recent installation — If you just added the pixel, it can take up to 30 minutes for the system to detect it. 🔧 Steps to Troubleshoot on MoPro If your pixel is not being detected, try the following steps: 1. Confirm the pixel code is placed correctly. Make sure the OTTO Pixel script is added in a location that loads on every page of your site. 2. Republish your site. After adding or adjusting the pixel code, republish your site to ensure the latest version is live. 3. Check for Cloudflare or CDN caching. If your site uses Cloudflare, purge the cache and wait 10–15 minutes before re-checking. 4. Use your browser's developer tools. Right-click on your live site, select Inspect, and search the page source for otto or your unique pixel key. If it appears in the HTML, the code is present. 5. Allow time for re-scan. After making changes, allow time for the system to re-scan your site and update the pixel status. 📝 Still Not Detected? If you have completed the troubleshooting steps above and the pixel is still not detected, our team can help investigate further. Please have the following information ready: - Your MoPro site URL - The date and time you installed the pixel - Any status messages or errors you are seeing 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.

⏳ OTTO Pixel Not Connected After Shopify Install

🔍 Overview After placing the OTTO Pixel code in the <head> section of your Shopify store, the Search Atlas dashboard may still display the pixel status as Not Connected. This is expected behavior in most cases and does not mean your installation failed. The most common reason for this is that Search Atlas needs to crawl your site before it can detect and confirm the pixel. Allow some time for the crawl to complete after installation before concluding there is an issue. ✅ How OTTO Pixel Detection Works When you install the OTTO Pixel, Search Atlas checks for it automatically on a schedule based on your project's age: every 15 minutes for projects under 2 hours old, every hour from 2 to 24 hours old, every 6 hours from 1 to 7 days old, and no automatic checks after 7 days. For a newly created project, a correctly installed pixel is normally detected within about 15 minutes. Until the next scheduled check runs, the dashboard may continue to show Not Connected even if your installation is perfectly correct. 🛠️ Step 1 — Confirm Your Installation Is Correct Before waiting for the next check, verify that the pixel is installed properly: 1. Open your Shopify store in a browser and navigate to any page. 2. Right-click anywhere on the page and select Inspect (or press F12). 3. Click the Elements tab and expand the <head> section. 4. Use Ctrl+F (or Cmd+F on Mac) to search for otto or your unique pixel ID. 5. Confirm the full OTTO Pixel script is present inside the <head> tag. If the script appears in the code inspection, your installation is correct. The status update is simply waiting on the next automatic pixel check. ⏰ Step 2 — Wait for the Next Automatic Check If your pixel code is confirmed in the page source, no further action is needed right away. For a new project, expect detection within about 15 minutes; older projects are checked less frequently (hourly between 2–24 hours, every 6 hours between 1–7 days, and not automatically after 7 days). 🔄 Step 3 — Still Showing Not Connected? If a reasonable amount of time has passed and the status still shows Not Connected despite confirming the pixel script is present in your page source, please reach out to our support team. When you do, have the following ready to speed up the investigation: - Your Shopify store URL - The project name as it appears in your Search Atlas dashboard - A screenshot or confirmation that the OTTO Pixel script is visible in your page source - The approximate date and time you completed the installation 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.

🔗 Connect GA4 to OTTO in Search Atlas

🔍 Overview OTTO SEO uses your Google Analytics 4 (GA4) data to power traffic insights and on-page recommendations. If OTTO cannot detect your website in GA4 — even when Google Search Console (GSC) is already connected — a separate GA4 authorization step is usually the cause. This article walks you through the full connection process and the most common fixes. ⚙️ Before You Begin Confirm the following before attempting to connect GA4: - You have a GA4 property (not a Universal Analytics property) set up for your website. - Your Google account has at least Viewer-level access to the GA4 property. - GSC is already connected to Search Atlas (GSC and GA4 use separate authorization flows — connecting one does not connect the other). 🚀 How to Connect GA4 to OTTO 1. In the left sidebar, click OTTO SEO, then open All Sites (OTTO SEO Projects). 2. Select the website you want to configure, then open its OTTO Settings. 3. Locate the Google Analytics 4 section and click Connect GA4. 4. A Google authorization window will appear. Sign in with the Google account that has access to your GA4 property and grant the requested permissions. 5. After authorization, use the dropdown to select the correct GA4 property that matches your website. 6. Click Save. OTTO will verify the connection and begin pulling in GA4 data. 🛠️ Troubleshooting: OTTO Is Not Detecting My Website in GA4 If OTTO still cannot find your website after following the steps above, work through the checks below one at a time. - Wrong property type: Make sure you are using a GA4 property, not a legacy Universal Analytics (UA) property. UA properties are no longer supported. - Multiple Google accounts: If you manage several Google accounts, ensure you authorized with the account that actually owns or has access to the GA4 property containing your site. Sign out of all other Google accounts in your browser, then repeat the authorization. - Property not yet populated: A brand-new GA4 property can take 24–48 hours to register data. If your property was created recently, wait and try again. - Domain mismatch: The domain configured in OTTO (e.g., www.axsysdental.com) must match the data stream URL inside your GA4 property. Open GA4 → Admin → Data Streams and confirm the stream URL matches exactly, including or excluding www. - Insufficient permissions: Ask the GA4 property owner to verify your Google account has at least Viewer access under GA4 → Admin → Account Access Management. - Re-authorize the connection: If the connection was previously attempted but failed, click Disconnect in OTTO Settings, then reconnect from scratch using the steps in the section above. 💡 Key Difference: GSC vs. GA4 in OTTO A common point of confusion is that Google Search Console and Google Analytics 4 are connected independently. Connecting GSC to Search Atlas does not automatically authorize GA4. OTTO requires both connections to be completed separately before it can access the full range of data needed for its recommendations. 📊 Verifying a Successful Connection Once GA4 is connected correctly, you should see the following: - A green "Connected" status next to Google Analytics 4 in OTTO Settings. - Traffic metrics populated in the OTTO dashboard within a few minutes (historical data may take up to 24 hours to fully load). - GA4-based insights appearing alongside your GSC data in OTTO SEO. 🙋 Still Need Help? 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.

🛠️ MCP v2 API Key Requests Hanging Indefinitely

🔍 What This Article Covers Some customers using the MCP (Model Context Protocol) endpoint with a valid v2 X-API-KEY header experienced requests that hung indefinitely — never returning a response, not even an error. At the same time, requests sent without an API key returned a fast 401 Unauthorized error, which confirmed the endpoint itself was reachable. This article explains what caused the issue, confirms it has been resolved, and tells you what to do if you still experience hanging requests. ⚙️ Root Cause: Redis Timeout During v1→v2 Migration This was a confirmed systemic issue, tracked internally as SPE-1065. During the migration from the legacy v1 API key system to the new v2 system, the allow-list check — the step that validates whether a key is permitted to access the MCP endpoint — relied on a shared Redis instance. A timeout in that Redis connection caused the allow-list check to stall on every MCP pod simultaneously. The result: any request carrying a v2 X-API-KEY header would pause at the authentication step and never complete. Requests with no key bypassed that check entirely and received an immediate 401, which is why those returned quickly. This was not caused by an invalid or revoked key. The key itself was valid — the authentication infrastructure was unable to verify it due to the Redis timeout. ✅ Current Status: Resolved The engineering team identified the root cause, reviewed the fix, and deployed it to production. MCP v2 API key authentication is now functioning correctly. The allow-list check is reachable from all MCP pods and no longer times out. 🚀 Steps to Take If You Are Still Experiencing Hanging Requests 1. Confirm you are using a v2 API key. Legacy v1 keys are no longer supported for MCP endpoint access. If you are unsure which version your key is, check your API key settings in your account. 2. Retry your request. Now that the fix has been deployed, a fresh request using a valid v2 X-API-KEY header should authenticate and respond correctly. 3. Check for any network-level timeouts on your side. If your client or infrastructure has a short timeout configured, ensure it is set high enough to allow the server to respond (a few seconds is typically sufficient). 4. Verify the key has not been revoked. If your key was deactivated or flagged, requests may fail. If you suspect your key status has changed, review it in your account settings or generate a new one. 5. Test with and without the header. If requests without the key still return a fast 401 but requests with the key still hang, this is a strong signal that something is still wrong server-side — not on your end. In this case, contact our team immediately (see below). 💡 What a Hanging Request Looks Like vs. a Normal Failure - Hanging request (the bug): Request with a valid v2 X-API-KEY header — no response, no error, connection stays open indefinitely. - Normal auth failure: Request without a key — fast 401 response, connection closes immediately. - Expected behavior (post-fix): Request with a valid v2 X-API-KEY header — authenticated successfully, response received within a normal timeframe. 📋 Information to Have Ready If You Need Support If you still experience hanging requests after the fix, gather the following before contacting our team — it will significantly speed up the investigation: - A description of the exact request being made (endpoint path, headers used — redact the key value itself) - Timestamps of when the hanging requests occurred - Whether requests without the key return a fast 401 at the same time - Any error messages or timeout messages from your client or logs - A screen recording or HAR file if possible 💬 Still Need Help? 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.

🔍 Fix WordPress Pixel Installation Status Delays

🧩 What Is This Issue? After installing the Search Atlas tracking pixel on your WordPress site, the platform may continue to show the pixel as not detected or unverified even though you have already added it correctly. This delay is most commonly caused by an active site audit crawl running in the background, which temporarily prevents the system from confirming the pixel's presence. 🔎 Why Does This Happen? Search Atlas verifies your pixel by crawling your website. If a site audit crawl is already in progress when you install or check the pixel, the verification process queues behind it. Until the crawl completes, the pixel status will not update — even if the pixel is installed perfectly. This is expected platform behaviour and not a sign that your installation is broken. ✅ How to Confirm Your Pixel Is Installed Correctly Before waiting for the platform to update, manually verify the pixel is live on your site by following these steps: 1. Open your WordPress site in a browser (for example, mipcare.com). 2. Right-click anywhere on the page and select View Page Source. 3. Press Ctrl + F (Windows) or Cmd + F (Mac) to open the search bar. 4. Search for your Search Atlas pixel ID or the pixel script snippet. 5. If the snippet appears in the source code, your pixel is installed correctly and the platform will confirm this once the crawl finishes. If the snippet does not appear in the page source, the pixel may not have been saved properly. See the reinstallation steps below. ⏱️ How Long Should I Wait? In most cases, pixel status updates within a few hours after the site audit crawl completes. If more than 24 hours have passed and the status still shows as unverified, proceed to the troubleshooting steps below. 🛠️ Troubleshooting Steps 1. Check the pixel is saved in WordPress. Go to your WordPress dashboard, navigate to the plugin or theme section where you added the pixel snippet, and confirm the code is still present and saved. 2. Clear your WordPress cache. If you use a caching plugin such as WP Rocket, W3 Total Cache, or LiteSpeed Cache, clear all cached files after installing the pixel. A cached version of your site may hide the pixel from the crawler. 3. Disable conflicting plugins temporarily. Security or performance plugins can sometimes block external crawlers. Temporarily disable them and re-trigger a pixel check. 4. Re-verify from the platform. Go to Left sidebar → OTTO SEO → SEO Automation (URL: /seo-automation-v3) and locate your site's pixel settings. Use the Re-verify or Check Again option if available to trigger a fresh verification crawl. 5. Confirm no site audit is running. Go to Left sidebar → Site Metrics (Site Explorer) (URL: /site-explorer/list) and check whether a crawl is currently active for your domain. If one is running, wait for it to finish before re-checking pixel status. 💡 Tips to Avoid This Issue in Future - Install or update your pixel outside of scheduled crawl windows to get faster verification. - Always clear your site cache immediately after adding or updating the pixel snippet. - Use the page source method described above as a quick first check before contacting support. 🆘 Still Need Help? If you have followed all the steps above and the pixel status is still not updating after 24 hours, 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.

🛠️ Fix Otto Pixel Plugin WordPress Checkout Conflicts

🔍 Overview When you activate the Search Atlas Otto pixel plugin on your WordPress site, you may notice that your checkout page or other page elements stop displaying correctly. This is a known compatibility issue caused by a conflict between the Otto pixel script and your WordPress theme or checkout plugin. This article explains why this happens and walks you through the steps to resolve it. ⚙️ Why This Happens The Otto pixel plugin injects a tracking script into your WordPress site to enable OTTO SEO automation and data collection. In some cases, this script can conflict with: - WooCommerce or other checkout plugins that load their own scripts on the checkout page - Page builder themes (such as Divi, Elementor, or Avada) that manage script loading in a custom way - Caching or performance plugins (such as WP Rocket or W3 Total Cache) that minify or defer JavaScript in a way that interferes with the pixel script - Security plugins that block or modify third-party scripts The result is often broken page layouts, missing checkout fields, or JavaScript errors that prevent customers from completing a purchase. 🛠️ How to Resolve the Conflict Follow these steps in order to identify and fix the issue: 1. Deactivate caching and minification temporarily. Go to your caching plugin settings and disable JavaScript minification and deferral. Then reload your checkout page to see if the issue is resolved. If it is, re-enable caching options one at a time to find the specific setting causing the conflict. 2. Exclude the Otto pixel script from optimisation. In your caching or performance plugin, add the Otto pixel script URL to the exclusion list so it is never minified, combined, or deferred. 3. Check your security plugin settings. If you use a security plugin such as Wordfence or iThemes Security, ensure it is not blocking external scripts. Add the Otto pixel domain to any allowlist or whitelist. 4. Test for theme conflicts. Temporarily switch to a default WordPress theme (such as Twenty Twenty-Four) and reload the checkout page. If the page displays correctly, the conflict is with your active theme. Contact your theme developer for guidance on loading third-party scripts safely. 5. Check for JavaScript errors. Open your browser's developer tools (press F12), go to the Console tab, and reload the checkout page. Note any error messages. These can help pinpoint which script or plugin is causing the conflict. 6. Update all plugins and your theme. Outdated plugins are a common cause of script conflicts. Ensure the Otto pixel plugin, your checkout plugin, and your theme are all running their latest versions. ✅ Verifying the Fix After completing the steps above, confirm everything is working correctly: - Visit your checkout page in a private or incognito browser window to bypass any cached version - Complete a test transaction from start to finish to confirm the checkout flow is fully functional - Check that your OTTO SEO data is still being recorded by navigating to Left sidebar → OTTO SEO → SEO Automation inside Search Atlas 🚀 Preventing Future Conflicts To avoid similar issues in the future, keep these best practices in mind: - Always test plugin activations on a staging site before deploying to production - Keep a record of any script exclusions you have added to your caching or security plugins - After updating any plugin — including the Otto pixel plugin — re-test your checkout page to confirm it remains functional 💬 Still Need Help? If you have followed all the steps above and your checkout page is still not working correctly, our team is ready to help. 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.

🛠️ Fix OTTO Pixel Disengaging on WordPress

🔍 Overview The OTTO Pixel is a small tracking script that connects your WordPress site to Search Atlas, enabling OTTO SEO to read your site's data and apply optimisations. If the Pixel keeps showing as Disabled in Search Atlas — even after you've re-engaged it — a conflict or configuration issue on your WordPress site is likely breaking the connection. This article walks you through the most common causes and how to fix them. ⚙️ How to Check the Pixel Status 1. In Search Atlas, click OTTO SEO in the left sidebar, then open SEO Automation (or go to /seo-automation-v3). 2. Locate your connected site and check the OTTO Pixel status indicator. 3. If it shows Disabled or Disengaged, continue with the steps below before re-engaging. ⚠️ Common Causes of Pixel Disengagement - Caching plugins overwriting the page — Plugins such as WP Rocket, W3 Total Cache, or LiteSpeed Cache can serve a cached version of your pages that does not include the Pixel script, causing Search Atlas to lose the connection. - Minification or script optimisation — JavaScript minification or deferred script loading can corrupt or delay the Pixel, preventing it from firing correctly. - Security or firewall plugins blocking the script — Plugins like Wordfence or iThemes Security may flag the Pixel as an unknown external script and block it. - CDN stripping scripts — A CDN such as Cloudflare may strip or defer third-party scripts, including the OTTO Pixel. - Theme or plugin conflicts — A recently updated theme or plugin may be interfering with script injection. - Multiple WordPress installs or staging environments — If the same Pixel ID is used across a live site and a staging site, the connection can become unstable. 🛠️ Step-by-Step Fixes 1. Clear all caches. Go to your caching plugin's settings and purge the entire site cache. If you use a CDN, purge the CDN cache as well. Then re-check the Pixel status in Search Atlas. 2. Exclude the OTTO Pixel script from minification and deferral. In your caching or performance plugin, find the JavaScript optimisation settings and add the OTTO Pixel script URL or handle to the exclusion list. Save and clear the cache again. 3. Whitelist the Pixel in your security plugin. Check Wordfence, iThemes Security, or any equivalent plugin for blocked scripts. Add the OTTO Pixel domain to the allowlist and ensure it is not being flagged as malicious. 4. Disable Rocket Loader in Cloudflare (if applicable). Log in to Cloudflare, go to Speed → Optimization, and turn off Rocket Loader. This prevents Cloudflare from deferring the Pixel script. You can also use a Page Rule to disable performance features for your site's key pages. 5. Test with plugins deactivated. Temporarily deactivate all plugins except the Search Atlas WordPress plugin, then re-engage the Pixel in Search Atlas. If it stays connected, reactivate plugins one by one to identify the conflicting plugin. 6. Verify the plugin is installed correctly. In your WordPress dashboard, go to Plugins → Installed Plugins and confirm the Search Atlas plugin is active and up to date. Deactivate it, then reactivate it, and re-engage the Pixel in Search Atlas. 7. Check for duplicate Pixel IDs. If you have a staging site, make sure it is using a separate connection or that the Pixel is disabled on staging. Two environments sharing the same Pixel ID can cause repeated disengagement. ✅ How to Re-Engage the Pixel After Fixing the Issue 1. In Search Atlas, click OTTO SEO in the left sidebar, then open SEO Automation. 2. Select your site and click the option to re-engage or enable the OTTO Pixel. 3. Reload your WordPress site's homepage in a new browser tab (not from cache) to trigger the Pixel. 4. Return to Search Atlas and refresh the page to confirm the Pixel status shows as Active. 💡 Tips to Keep the Pixel Stable - After any WordPress update, plugin update, or cache configuration change, verify the Pixel status in Search Atlas. - Set your caching plugin to exclude the OTTO Pixel script permanently from optimisation rules. - Avoid using the same Pixel ID on both your live site and any staging or development environment. 🆘 Still Disengaging After All Steps? If you have followed every step above and the OTTO Pixel continues to disengage, our support team can investigate further. 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.

🔌 Fix WordPress Plugin Status & Connect GSC

🔍 Overview Two issues commonly appear together when setting up a new project in Search Atlas: the WordPress plugin showing Not installed on the dashboard despite being active on your site, and Google Search Console (GSC) not yet linked to the project. This article walks you through resolving both quickly. 🛠️ Fix the 'Not Installed' WordPress Plugin Status Even if the Search Atlas plugin is installed, activated, and authenticated on your WordPress site, the dashboard may still show Not installed. This is almost always a sync or connection issue, not a plugin problem. Follow these steps in order: 1. Confirm the plugin is active in WordPress. Log in to your WordPress admin panel, go to Plugins → Installed Plugins, and verify the Search Atlas plugin is listed and activated. 2. Check your API key inside the plugin. In WordPress, navigate to the Search Atlas plugin settings and confirm the API key matches the one found in your Search Atlas account under Avatar Menu (👤) → Settings → API Keys. Copy and re-paste it if unsure, then save. 3. Force a re-sync from the Search Atlas dashboard. Open your project in Search Atlas, go to Settings → Integrations → WordPress, and click Reconnect or Re-authenticate if that option is available. This triggers a fresh handshake between your site and the platform. 4. Clear any caching on your WordPress site. If you use a caching plugin (e.g., WP Rocket, W3 Total Cache), clear the cache after saving your API key. Cached responses can block the verification ping Search Atlas sends to confirm installation. 5. Check for plugin conflicts. Temporarily disable other plugins one at a time to rule out conflicts, particularly security plugins that may block outgoing or incoming API requests. 6. Verify your site URL matches the project URL. In Search Atlas, confirm the domain entered for your project exactly matches your WordPress site's URL (including or excluding www). A mismatch will prevent the status from updating. After completing these steps, wait up to 5 minutes and then refresh your Search Atlas dashboard. The status should update to Installed. 📊 Connect Google Search Console to Your Project Linking GSC gives Search Atlas access to your site's real search performance data, which powers keyword tracking, ranking insights, and OTTO SEO recommendations. Here is how to connect it: 1. Make sure GSC is already set up for your domain. Before connecting, confirm your site is verified in Google Search Console at search.google.com/search-console. If your site is not verified there yet, complete that step first. 2. Open the GSC connection flow in Search Atlas. From the main dashboard, navigate to Site Metrics → Site Explorer → Manage Sites to reach the Manage Sites page. 3. Click 'Connect GSC Account'. On the Manage Sites page, click the Connect GSC Account button. You will be redirected to a Google authentication screen. 4. Sign in with the correct Google account. Use the Google account that has Owner or Full User access to the GSC property for your domain. Accounts with Restricted access cannot share data with third-party tools. 5. Grant the required permissions. Review and accept the permissions Search Atlas requests. These are read-only and allow the platform to pull impressions, clicks, and ranking data. 6. Select the correct GSC property. After authenticating, you may be asked to choose which GSC property to link. Select the property that matches your project domain exactly — note that https://beesmartbeeremoval.com and https://www.beesmartbeeremoval.com are separate properties in GSC, so pick the one where your data lives. 7. Save and confirm the connection. Once selected, click Save or Confirm. The integration status should update to Connected within a few minutes. ⚠️ Common Reasons GSC Connection Fails - You are signed into the wrong Google account during the OAuth flow. - The Google account used does not have sufficient permissions on the GSC property. - The domain in Search Atlas does not exactly match a verified property in GSC. - A browser extension (e.g., an ad blocker) is interrupting the Google authentication popup — try in an incognito window or a different browser. ✅ Confirm Everything Is Working After completing both steps, return to your Search Atlas project dashboard. You should see the WordPress plugin status show Installed and the GSC integration show Connected. Data from GSC may take up to 24 hours to begin populating in your reports, as Search Atlas syncs historical data in batches. 💬 Still Need Help? 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.

🔧 Fix WordPress Plugin "Unable to Sync" Error

Overview The "Unable to sync with your WordPress site" error appears when the Search Atlas plugin cannot establish or maintain a stable connection between your WordPress installation and the Search Atlas platform. This article explains what to check and what information to have ready so our team can resolve your issue as quickly as possible. Before You Begin Confirm the following baseline requirements are met before escalating: - You are using the latest version of the Search Atlas WordPress plugin (check your WordPress dashboard under Plugins → Installed Plugins). - Your WordPress site is publicly accessible (not under maintenance mode or password protection). - Your hosting account is active and your site is loading without errors. What to Try First 1. Deactivate and reactivate the Search Atlas plugin. In your WordPress dashboard, go to Plugins → Installed Plugins, deactivate the Search Atlas plugin, then reactivate it and attempt to sync again. 2. Re-enter your connection credentials. In Search Atlas, disconnect your WordPress site and reconnect it by re-entering your site URL and credentials exactly as required. Make sure there are no extra spaces or typos. 3. Check for plugin conflicts. Temporarily deactivate all other active plugins, then attempt to sync. If syncing succeeds, reactivate your other plugins one at a time to identify which one is causing the conflict. 4. Confirm your site is reachable over HTTPS. Make sure your site loads correctly in a browser without any SSL warnings or certificate errors, as connection issues can prevent syncing. When Contacting Support If the steps above do not resolve the issue, please have the following ready so our team can investigate efficiently: - Your WordPress site URL - The exact error message displayed (a screenshot is helpful) - The version of the Search Atlas plugin you are running - A list of any other active plugins on your WordPress site - The name of your hosting provider 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.

🔌 Fix SEO Plugin Conflicts Causing Wrong Meta Descriptions

🧭 Overview If Search Atlas is displaying a meta description that does not match what is actually live on your page, the cause is often a third-party SEO plugin conflict. Plugins such as Yoast SEO, Rank Math, and Airlift can override the meta descriptions managed by Search Atlas, creating a mismatch between what Search Atlas reads and what is actually served on your page. This article explains why this happens and how to resolve it. ⚙️ Why This Happens Search Atlas writes meta descriptions directly to your pages. However, several popular SEO plugins also control meta description output and may take priority over changes made by other tools. When multiple plugins try to manage the same meta field, one overrides the other — and Search Atlas ends up reading stale or incorrect data. Common plugins that cause this conflict include: - Yoast SEO — manages its own meta description output and can conflict with other tools - Rank Math — similarly manages meta output independently and may suppress changes made by other tools - Airlift — a performance and SEO plugin that may interfere with meta tag output - Any other plugin that outputs custom meta description tags The result is that your live page serves the plugin's meta description while Search Atlas reflects a different value, making it appear as though Search Atlas is showing incorrect information. It is reading the value it last wrote or retrieved, while a plugin is overriding it on the front end. 🔍 How to Confirm a Plugin Conflict 1. Open your page in a browser and right-click anywhere on the page, then select View Page Source. 2. Press Ctrl + F (or Cmd + F on Mac) and search for meta name="description". 3. Check whether the description shown in the source code matches what you set in Search Atlas. 4. If they differ, look just above or below the tag for a comment or plugin signature indicating which plugin is controlling the output. 🛠️ How to Resolve the Conflict Choose the approach that best fits your setup: Option 1 — Disable meta description output in the conflicting plugin (recommended) 1. Log in to your WordPress dashboard. 2. Navigate to the settings of the conflicting plugin and look for an option to disable or turn off meta description output. 3. Save your changes and re-check your page source to confirm that Search Atlas is now controlling the meta description. Option 2 — Remove or deactivate the conflicting plugin 1. If you do not rely on the conflicting plugin for other functionality, consider deactivating it entirely from your WordPress plugins list. 2. After deactivating, clear any caches and verify your page source again. Option 3 — Contact the plugin's support team If you are unsure how to disable meta description output within a specific plugin, reach out to that plugin's support team for guidance on preventing it from overriding external meta description values. 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.

🛠️ Fix Shopify Pixel Disconnection and Script Errors

🔍 Why Does My Shopify Connection Drop? Shopify pixel disconnections in Search Atlas are usually triggered by one of the following causes: - Shopify theme updates: When you update or switch your storefront theme, custom pixel scripts installed by third-party apps — including Search Atlas — can be removed or overwritten automatically. - App permission changes: If Search Atlas app permissions are revoked or expire inside your Shopify admin, the tracking pixel loses its authorisation to fire. - Shopify Customer Privacy API changes: Shopify periodically updates its consent and cookie APIs. If your store's consent banner or privacy settings change, pixels may be blocked from loading until re-authorised. - Script injection conflicts: Other marketing or analytics apps installed after Search Atlas can conflict with the pixel, causing it to silently fail. - Shopify store plan changes: Downgrading your Shopify plan can restrict access to certain script injection features, breaking the connection. ⚠️ How to Tell Your Connection Has Dropped You may notice the following signs inside Search Atlas when your Shopify pixel is disconnected: - A red or warning status indicator next to your Shopify store in the Integrations or Connected Sites section. - Missing or flatlined traffic and conversion data on your dashboard for the affected store. - Alerts or notification banners prompting you to reconnect your Shopify account. If you manage multiple stores — such as amberandhue.com.au and hyundaipower.com.au — a single theme update or permission change affecting one store can sometimes trigger disconnection flags across all linked properties simultaneously. Always check every connected store when you receive a disconnection alert. 🔧 Step-by-Step: Reconnect Your Shopify Store 1. Log in to Search Atlas and navigate to Settings > Integrations (or Connected Sites, depending on your plan). 2. Locate the disconnected Shopify store. You will see a warning icon or a Reconnect button next to the store URL. 3. Click Reconnect and follow the OAuth authorisation flow. You will be redirected to your Shopify admin to approve the permissions request. 4. Once redirected back to Search Atlas, confirm the store status changes to Connected (green indicator). 5. Repeat this process for each disconnected store individually. Reconnecting one store does not automatically restore others. 6. After reconnecting, navigate to your Shopify Admin > Online Store > Themes and confirm the Search Atlas script snippet is present in your active theme's theme.liquid file or via the Shopify Web Pixels Manager. If it is missing, proceed to the manual script step below. 📋 Manually Re-adding the Search Atlas Pixel Script If the pixel script was removed by a theme update, you may need to add it back manually: 1. In Search Atlas, go to Settings > Integrations and open your Shopify store details. Copy the unique pixel script snippet provided for your store. 2. In your Shopify Admin, go to Online Store > Themes. Click Actions > Edit Code on your active theme. 3. Open the theme.liquid file and paste the copied script immediately before the closing </head> tag. 4. Click Save. The pixel should begin firing within a few minutes. 5. Return to Search Atlas and verify that data is flowing by checking the real-time or recent activity panel for the store. 🛡️ How to Prevent Future Disconnections Follow these best practices to keep your Shopify connections stable: - Test in a staging theme first: Always preview theme updates on a duplicate theme before publishing. This lets you verify the pixel script survives the update. - Use Shopify Web Pixels where available: Shopify's Web Pixels Manager is more resilient to theme changes than script injection into theme.liquid. If Search Atlas supports this method for your plan, use it. - Review permissions after plan changes: Any time you change your Shopify subscription plan, revisit Search Atlas integrations to confirm permissions are still active. - Monitor your Search Atlas dashboard regularly: Check the Integrations status section at least once a week if you manage multiple stores. - Audit third-party apps before installing: Before adding new marketing or analytics apps to Shopify, check that they do not override or remove existing pixel scripts. 💬 Still Need Help? If you have followed the steps above and your Shopify store is still showing as disconnected, or if data is not appearing after reconnection, our team is ready to investigate. 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.

🔌 Wix CMS Connector: Common Failures and How to Fix Them

🛠️ Common failure modes and fixes 🔑 Auth error — connector marked as invalid Cause: Your Wix OAuth token has expired, or your Wix API Key is missing a required permission. A common case is the API Key lacking the Manage Blog permission, which surfaces as: Categories endpoint failed: Invalid or expired API Key. Please ensure your Wix API Key has the 'Manage Blog' permission enabled. Fix: Delete the connector in Avatar Menu (👤) → Settings → CMS Connectors and reconnect with a fresh OAuth authorization. Make sure you authorize all requested permissions, including Manage Blog. The connector now tracks and exposes its credential status, so an invalid or disconnected connector is flagged in the UI before publishing; use the reconnect flow to restore it. 🔍 Meta-site not found — sync fails resolving the Wix site Cause: The credential can't be matched to a valid Wix site (meta-site), shown as Categories endpoint failed: meta-site not found. Fix: Reconnect the connector and authorize the correct Wix site so the credential is bound to a resolvable meta-site. 👤 Missing member — publish fails with member_id required Cause: No author/member was selected in the connector settings. Fix: Edit the connector and select a valid Wix member as the default author. The member must exist in your Wix site's member list. ⏳ Rate limit — publish hangs Cause: Wix API rate limit hit during batch publishing. Fix: Handled automatically with retry logic. Wait a few minutes; the publish will complete on its own. ✅ Post-publish verification error codes - CONTENT_MISSING — article didn't appear; try republishing - PAGE_NOT_ACCESSIBLE — page is live but returns an error when accessed - CONTENT_MISMATCH — content on page doesn't match what was sent Contact support with the error code and article URL if the issue persists after republishing.

🛠️ Fix OTTO Pixel Detection on Toast Websites

🔍 Overview The OTTO Pixel is a small tracking script that allows OTTO SEO to monitor and automate optimizations on your website. When connected to a Toast website, the pixel can occasionally lose its connection or stop being detected — even if it was working before. This article explains why this happens and walks you through the steps to restore detection successfully. ⚠️ Why the OTTO Pixel Stops Being Detected Toast websites use a proprietary content management system that can overwrite or reset third-party scripts in the following situations: - A Toast platform update or template refresh was applied to your site. - You edited or republished your site through the Toast dashboard, which can clear injected scripts. - The script was added to a section of the page that Toast does not persist between sessions or publishes. - Browser caching caused Search Atlas to check a stale version of the page during detection. Because Toast manages its own code environment, standard reinstallation steps may appear to succeed but the pixel can still fail detection if placed in the wrong location. ✅ How to Correctly Reinstall the OTTO Pixel on a Toast Website 1. Get your OTTO Pixel snippet. In Search Atlas, go to OTTO SEO in the left sidebar and open SEO Automation (or navigate to /seo-automation-v3). Open your OTTO project and locate the pixel installation section. Copy your unique pixel code snippet. 2. Log in to your Toast website dashboard. Navigate to the section that controls custom code or scripts — this is typically found under Settings → Custom Code or a similar menu in your Toast admin panel. 3. Remove any previously installed pixel snippets. Before adding a fresh copy, delete all existing instances of the OTTO Pixel from your Toast site. Having duplicate or stale versions is a common cause of detection failures. 4. Paste the pixel in the <head> section only. Toast websites retain third-party scripts most reliably when they are placed in the global <head> section, not in the body or footer. Confirm you are pasting into the head-level custom code field. 5. Save and publish your changes. Make sure to fully publish or go live with the update — saving as a draft will not make the script visible to Search Atlas for detection. 6. Clear your browser cache and any site-level cache. After publishing, clear your browser cache. If Toast offers a cache-clearing option in the dashboard, use it as well. 7. Trigger pixel detection in Search Atlas. Return to your OTTO project under OTTO SEO → SEO Automation (/seo-automation-v3) and run the pixel detection check. For new projects, automatic checks run every 15 minutes, so detection is normally confirmed within about 15 minutes. 💡 Tips to Prevent Future Detection Loss - Avoid republishing your entire Toast site unless necessary — full republishes can reset custom code fields. - Check your pixel after any Toast platform update. Toast occasionally pushes automatic updates that may clear injected scripts. Make it a habit to verify detection after any changes to your site. - Only install the pixel once. Multiple copies of the pixel snippet can cause conflicts and failed detection. Always verify no duplicates exist before adding a new one. - Use the <head> placement every time. Footer or body placements are less reliable on Toast and may not be detected consistently. 🔎 How to Verify the Pixel Is Live on Your Site Before triggering detection in Search Atlas, you can manually confirm the pixel is present on your Toast website: 1. Open your live website URL in a browser. 2. Right-click anywhere on the page and select View Page Source. 3. Use Ctrl+F (or Cmd+F on Mac) to search for otto or a unique portion of your pixel snippet. 4. If the snippet appears in the source, the pixel is live. If it does not appear, return to your Toast dashboard and repeat the reinstallation steps above. 🆘 Still Not Being Detected? If you have followed all the steps above and the OTTO Pixel is still not being detected on your Toast website, our team can investigate further. 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. Additional Notes If you previously installed OTTO Pixel through a Google Tag Manager (GTM) container, or if GTM is active on your Toast site alongside a direct OTTO Pixel install, this conflict will prevent detection. Check your Toast custom code area for any GTM snippet (references googletagmanager.com) and remove it.

🔍 Fix Keyword Research API Quota Mismatch

🧭 Overview If your keyword research API returns a quota_exceeded error with a limit of 0, but your dashboard shows thousands of lookups remaining, your account may have experienced a temporary quota sync issue. This is a known platform behaviour that can occur when the quota system fails to write correctly. In most cases, the fix is quick and does not require a plan change. ⚠️ What Causes This A mismatch between your API-reported quota and your dashboard quota can happen when a background quota sync fails. Your actual entitlement remains intact on the account — the API simply reads an incorrect value at that moment. A recent engineering fix addressed a root cause of this type of failure, but transient sync issues can still occur. 🛠️ Steps to Resolve 1. Confirm your quota is genuinely available. Open the platform and check your keyword research usage. Navigate to the relevant section of your dashboard to verify that lookups are shown as available for your plan. 2. Wait 2–5 minutes, then retry your API call. Quota sync issues are often self-correcting within a short window. Re-send the same API request that returned quota_exceeded and check whether it succeeds. 3. Clear any cached API credentials or tokens on your end. If your integration caches authentication tokens or quota state locally, clear that cache and reinitialise the connection before retrying. 4. Retry the API call a second time. In the confirmed case underlying this article, the API began working correctly as soon as the customer tried again after the account was reviewed. No configuration change was required — the quota state corrected itself. ✅ Confirming the Fix A successful API response — returning keyword data rather than a quota_exceeded error — confirms that the quota is now syncing correctly. Your remaining lookups should continue to decrement as expected from that point forward. 📋 Additional Notes - This issue affects the keyword research API specifically and is not related to other Search Atlas API endpoints. - Your plan entitlement and purchased quota are not lost during a sync failure — the lookups are preserved on your account. - If you use CSV upload for keyword research and notice that a lookup was consumed but returned no data, this is a separate known issue. Contact support so the team can review and restore the affected quota. 💬 Still Seeing the Error? If retrying does not resolve the quota_exceeded error and your dashboard continues to show available lookups, a member of our team can review your account and manually trigger a quota correction. 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.

🔍 Why Aren't My Google Search Console Properties Showing in the Reports Dropdown?

In some accounts, Google Search Console is connected and your properties are visible in the integration view, yet the property selector in the reports builder stays empty — so you can't connect a Search Console property to a report. This affects team member seats, and it has a quick fix. 🔍 How to Recognize This Issue This is likely your situation if all of the following are true: - Your GSC integration shows as connected in Site Metrics → Site Explorer → 'Open Google Search Console' (Manage Sites page) (for example, it shows the number of sites found). - Clicking View properties in the integration shows your Search Console properties listed correctly. - Your data loads normally when you open Google Search Console directly. - But the property selector in the reports builder is empty and does not list your properties when you try to connect one to a report. You can still create and view reports — only the step of connecting a Search Console property to a report is blocked. 🧩 Why This Happens Your account is set up as a team member seat, and the reports builder requires each user to have their own Google account connected directly. When this per-user connection hasn't been completed for your login, your Search Console properties won't appear in the reports dropdown — even though the account itself already has GSC connected. 🛠️ How to Fix It While logged in with your own user: 1. Go to Site Metrics → Site Explorer → 'Open Google Search Console' (Manage Sites page). 2. Click Connect GSC Account. 3. Authorize with the Google account that has access to your Search Console properties. 📈 What to Expect After Connecting Once connected, your properties will sync and appear in the reports dropdown within a few minutes. You do not need to rebuild any reports you've already created. ✅ In Short Even though your Search Console connection looks complete at the account level, the reports builder needs your own Google account connected on your login. Once you complete that one-time connection, your properties sync within a few minutes and everything you've already built stays exactly as it is — so you can pick up right where you left off, no rework required.

🔧 Resolving Website Studio Import and MCP Connection Errors

🎯 Overview Website Studio occasionally encounters import resolution errors, particularly with the ErrorBoundary component, and MCP (Model Context Protocol) connection issues that can block your project from loading. This guide walks you through diagnosing and resolving these problems quickly. 🔍 What Causes These Errors? Import resolution errors typically occur when Website Studio cannot locate or properly load component dependencies. MCP connection issues arise when the platform loses communication with the backend services that power your project's functionality. Both can prevent your editor from loading or cause projects to break unexpectedly. ⚙️ How to Fix Import Resolution Errors Step 1: Clear Your Browser Cache Start by clearing your browser's cache and cookies for Search Atlas. This resolves many import errors caused by outdated cached files: - Open your browser settings - Navigate to Cache and Cookies - Clear data for the Search Atlas domain - Close and reopen Website Studio Step 2: Force a Hard Refresh After clearing cache, perform a hard refresh of the Website Studio page: - Windows/Linux: Press Ctrl + Shift + R - Mac: Press Cmd + Shift + R This ensures Website Studio loads the latest component files and dependencies from the server. Step 3: Check Your Project State Navigate to Website Studio from the left sidebar and open your project. If the ErrorBoundary error persists, try these actions: - Wait 30 seconds for the project to fully load - Refresh the page again if the error appears immediately - Check that your project was saved successfully in your last session 🌐 Resolving MCP Connection Issues Step 1: Verify Your Internet Connection MCP errors often stem from connectivity problems. Ensure your internet connection is stable and not being blocked by a firewall or VPN. Step 2: Check Service Status MCP connection failures can occur if backend services are temporarily unavailable. Wait a few minutes and try reconnecting. If the issue persists beyond 15 minutes, contact support. Step 3: Reconnect MCP If Website Studio shows an MCP connection error: - Close the Website Studio editor tab - Return to the main Search Atlas dashboard - Re-open Website Studio from the left sidebar - Allow 30-45 seconds for the MCP connection to re-establish Step 4: Check for Authentication Issues MCP connection errors can also indicate an authentication problem. If reconnecting doesn't work: - Log out of Search Atlas completely - Clear your browser cache again - Log back in and return to Website Studio 🚀 Preventing Future Errors To minimize import and MCP issues, follow these best practices: - Save regularly: Save your projects frequently to avoid losing work during unexpected errors - Monitor your connection: Keep your internet connection stable while working in Website Studio - Update your browser: Use the latest version of your browser for compatibility - Avoid multiple tabs: Don't open the same project in multiple browser tabs simultaneously - Check browser extensions: Some extensions can interfere with Website Studio; disable them if errors occur 💡 If These Steps Don't Work If you've followed all the steps above and your import or MCP error persists, the issue may require deeper investigation. 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. When you contact support, include: - The exact error message you're seeing - Your project name - Steps you've already tried - Your browser type and version - Whether the error occurs for all projects or just one 📋 Quick Reference Checklist Use this checklist to resolve issues quickly: 1. Clear browser cache and cookies 2. Perform a hard refresh (Ctrl+Shift+R or Cmd+Shift+R) 3. Wait 30 seconds for Website Studio to load 4. Check your internet connection 5. Close and reopen Website Studio 6. Log out and log back in 7. Contact support if errors persist

WordPress Plugin Dashboard Shows Login Despite Sync

What Is This Issue? After successfully connecting your WordPress site to Search Atlas, the plugin dashboard may display a login screen or prompt you to select a free trial — even though your account is active and the sync appears complete. If you are experiencing this behaviour, try the troubleshooting steps below. If the issue persists after working through them, please contact our support team so we can investigate further. Step 1: Re-Authenticate the Plugin The first thing to try is disconnecting and reconnecting your Search Atlas account inside the plugin. This refreshes the authentication tokens between your WordPress site and the platform. 1. In your WordPress admin, navigate to the Search Atlas plugin settings. 2. Disconnect or log out of your Search Atlas account from within the plugin. 3. Log back in using your Search Atlas credentials and complete the connection flow again. 4. Once reconnected, reload the plugin dashboard and check whether the login screen still appears. Step 2: Deactivate and Reactivate the Plugin If re-authentication alone does not resolve the issue, deactivating and reactivating the plugin can reset its internal state. 1. Go to Plugins in your WordPress admin panel. 2. Find the Search Atlas plugin and click Deactivate. 3. Once deactivated, click Activate to turn it back on. 4. Return to the plugin dashboard and test again. Step 3: Clear All Caches Cached data — from your browser, WordPress caching plugins, or your hosting provider — can cause the plugin to display outdated authentication states. - Clear your browser cache and cookies, then reload the page. - If you use a WordPress caching plugin (such as WP Rocket, W3 Total Cache, or LiteSpeed Cache), purge all cached files from within that plugin. - If your hosting provider offers server-level caching (for example, via a hosting dashboard), clear that cache as well. - After clearing all caches, navigate back to the Search Atlas plugin dashboard. Step 4: Uninstall and Reinstall the Plugin If the steps above have not worked, a clean reinstall removes any corrupted plugin files that could be causing the problem. 1. In your WordPress admin, go to Plugins and deactivate the Search Atlas plugin. 2. Click Delete to fully remove it. 3. Download the latest version of the Search Atlas plugin from the official source. 4. Install and activate it fresh, then reconnect your account. 5. Check the dashboard once more to see if the login prompt is gone. Step 5: Verify Your Plan Is Active In rare cases, a billing or subscription issue can cause the plugin to behave as if no plan is attached to your account. To rule this out, log in to your Search Atlas account directly in your browser and confirm that your plan is active and your site is listed as connected. If anything looks incorrect, contact our support team for assistance. Still Seeing the Issue? If none of the steps above resolve the problem, please reach out to our support team via the chat widget in your Search Atlas dashboard. Share a description of what you see in the plugin dashboard and any steps you have already tried, so we can investigate and resolve it for you as quickly as possible.

⏱️ OTTO Pixel GTM Detection Delay Explained

🔍 What This Article Covers After connecting the OTTO Pixel through Google Tag Manager (GTM), some customers expect the Verify button to turn green right away. This article explains why there is a normal detection delay, what to expect during that window, and how to tell the difference between a delay and an actual installation problem. ⏳ The 15–20 Minute Detection Window Is Normal Once you publish your OTTO Pixel tag in GTM and the tag fires on your website, OTTO does not detect the pixel instantly. OTTO requires 15 to 20 minutes to scan your site and confirm that the pixel is active. This is expected behavior, not a failure. During this window you may notice: - The Verify button remains unresponsive or does not turn green. - The pixel status shows as unverified or pending. - No confirmation message appears in the OTTO dashboard. This does not mean something is broken. The scan is running in the background and will complete automatically. ✅ What to Do Immediately After GTM Setup 1. In GTM, confirm your OTTO Pixel tag is published — not just saved or previewed. A tag that is only in Preview mode will not fire on your live site. 2. Visit your live website in a browser and load at least one page to trigger the tag. 3. Navigate to OTTO SEO in the left sidebar of Search Atlas (URL: /seo-automation-v3) and open your OTTO project. 4. Wait 15 to 20 minutes before clicking Verify. Clicking the button repeatedly before the scan completes will not speed up detection. 5. After 20 minutes, click Verify once to prompt OTTO to check the pixel status. 🟢 Why the Verify Button May Not Show Green Immediately The Verify button reflects the result of OTTO's most recent scan, not a real-time check. Until the first successful scan is complete, the button will appear inactive or unchanged regardless of how many times it is clicked. Once OTTO detects the pixel signal from your live site, the status updates automatically and the button will turn green on the next check. ⚠️ Normal Delay vs. Actual Installation Failure Use the table below to identify which situation applies to you. - Normal delay (wait it out): It has been fewer than 20 minutes since you published the GTM tag, the tag is published and firing on your live site, and the Verify button simply has not turned green yet. - Possible installation issue (action required): More than 20 minutes have passed, the Verify button is still not confirming the pixel, or you see a Pixel Incorrectly Installed alert inside OTTO. If you are in the second scenario, move on to the troubleshooting steps below before contacting support. 🛠️ If the Pixel Is Still Not Detected After 20 Minutes Work through these checks in order before assuming the installation has failed. 1. Confirm the GTM container is published. Open GTM, go to your workspace, and check that the version containing the OTTO Pixel tag has been submitted and published. A submitted-but-not-published container will not fire live. 2. Check that the tag is firing on the correct pages. In GTM Preview mode, load your website and verify that the OTTO Pixel tag appears under Tags Fired. If it appears under Tags Not Fired, review your trigger configuration. 3. Verify the GTM container snippet is on your site. Your website's <head> section must contain the GTM container snippet. If the snippet is missing, the OTTO Pixel tag will never fire regardless of GTM settings. 4. Check for tag sequencing or consent mode blocks. If your site uses a Consent Management Platform (CMP) or cookie banner, the OTTO Pixel tag may be blocked until a visitor consents. Temporarily check whether the tag fires in a consented state. 5. Hard-refresh the OTTO dashboard. Press Ctrl + Shift + R (Windows) or Cmd + Shift + R (Mac) to clear cached status and then click Verify again. 📋 Quick Reference Checklist - GTM tag is published to the live container — not just in Preview. - At least one page on the live site has been loaded after publishing. - 20 minutes have passed since publishing. - Verify button has been clicked once after the 20-minute window. - No consent or CMP block is preventing the tag from firing. - GTM container snippet exists in the site's <head>. 💬 Still Need Help? If you have followed all the steps above and the pixel is still not detected after 20 minutes, 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.

🛠️ Fix WordPress OTTO Plugin Integration Errors

🔍 What This Article Covers If your Search Atlas WordPress plugin displays an 'OTTO not found' error during integration, this guide walks you through the most common causes and how to fix them quickly. Follow each section in order until the issue is resolved. ✅ Before You Begin: Prerequisites Make sure the following conditions are met before troubleshooting: - You have an active Search Atlas account with OTTO SEO enabled. - You have administrator access to your WordPress site. - Your WordPress version is 5.6 or higher. - The Search Atlas WordPress plugin is installed and activated. ⚙️ Step 1 — Verify OTTO Is Activated in Search Atlas The most common cause of the 'OTTO not found' error is that OTTO SEO has not been activated for your site inside the Search Atlas platform. 1. Log in to your Search Atlas account. 2. In the left sidebar, navigate to OTTO SEO, then open SEO Automation (URL: /seo-automation-v3). 3. Confirm that your target website is listed and that OTTO has been activated for it. If you see a prompt to activate OTTO, complete that process first. 4. Once activated, return to your WordPress dashboard and retry the integration. 🔑 Step 2 — Check Your API Key Connection An incorrect or missing API key will prevent the plugin from locating your OTTO instance. 1. In your WordPress admin panel, go to Search Atlas → Settings. 2. Locate the API Key field and confirm it is not empty. 3. In Search Atlas, go to your account settings and copy your API key. 4. Paste the key into the WordPress plugin settings and click Save Changes. 5. After saving, click the Test Connection button (if available) to verify the link is successful. 🌐 Step 3 — Confirm Your Site URL Matches OTTO links to a specific domain. If the URL registered in Search Atlas does not exactly match your WordPress site URL, the integration will fail. - In Search Atlas under OTTO SEO V3, check the domain listed for your OTTO activation. - In WordPress, go to Settings → General and compare the WordPress Address (URL) and Site Address (URL) fields. - Both values must match the domain in Search Atlas exactly — including whether www is present and whether the site uses https. - If there is a mismatch, update the domain in Search Atlas or correct your WordPress URL, then retry. 🔄 Step 4 — Update or Reinstall the Plugin An outdated or corrupted plugin file can also trigger this error. 1. In WordPress, go to Plugins → Installed Plugins. 2. Check whether an update is available for the Search Atlas plugin. If so, update it now. 3. If no update is available and the error persists, deactivate and delete the plugin. 4. Get the latest Search Atlas plugin .zip from Search Atlas (the plugin is not listed in the WordPress plugin directory). 5. Reinstall and reactivate the plugin, then re-enter your API key and save. 🛡️ Step 5 — Check for Plugin or Firewall Conflicts Security plugins, caching tools, or server firewalls can block the API requests the plugin needs to communicate with Search Atlas. - Temporarily deactivate any security or firewall plugins (such as Wordfence or iThemes Security) and test the integration again. - Clear your site's cache using your caching plugin or hosting control panel, then retry. - If your hosting provider has a Web Application Firewall (WAF), ask them to whitelist outbound requests to the Search Atlas API domain. - Re-enable your security plugins once the integration is confirmed working. 💡 Quick Reference: Common Causes and Fixes - 'OTTO not found' error → OTTO is not activated in Search Atlas for that domain. Activate it under OTTO SEO V3 first. - Connection fails after entering API key → API key is incorrect or copied with extra spaces. Re-copy and paste carefully. - Integration works on staging but not production → The domain registered in Search Atlas does not match the live site URL. - Error returns after updating WordPress → Plugin may need updating to maintain compatibility. Check for a plugin update. 🆘 Still Seeing the Error? If you have followed all the steps above and the 'OTTO not found' error still appears, our support team can investigate your specific account configuration. 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.

🔧 Troubleshooting Meta Description Sync Issues WordPress

🧭 Overview If meta descriptions you have edited in Search Atlas are not appearing in your WordPress backend editor, this is a known issue that our team needs to investigate on a per-account basis. The root cause can vary depending on your site setup, and the resolution requires a manual review by a support agent. What to Do Because the exact cause of meta description sync failures depends on your specific WordPress environment and account configuration, there is no single self-serve fix that applies to all cases. The most effective step you can take right now is to contact the Search Atlas support team directly so an agent can look into your integration and resolve the issue for you. When you reach out, please have the following information ready so the team can investigate quickly: - The name of the Search Atlas project you are working in. - The URL of the WordPress site where meta descriptions are not appearing. - The specific page or post URL(s) where the meta description is missing from the backend editor. - The exact meta description text you entered in Search Atlas. - Any error messages or unusual behavior you have noticed in either Search Atlas or your WordPress dashboard. - The date and approximate time when you last attempted the update. 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.

⚡ OTTO Pixel on GoHighLevel: Installation & Crawl Troubleshooting

🧭 Overview After installing the OTTO pixel on your GoHighLevel (GHL) site, you may see a message indicating the pixel has not been detected. In many cases, this is related to a slow or in-progress site crawl rather than a pixel installation error. If you are experiencing this issue, the steps below can help you identify what to check and when to reach out for support. ⚠️ Pixel Not Detected After Installation If the OTTO pixel is not being detected after you have installed it on your GoHighLevel site, this may be related to a slow crawl running in the background. You do not necessarily need to reinstall the pixel if you have already added it correctly. - A slow or stalled crawl may delay pixel detection confirmation. - If the crawl appears to be taking an unusually long time with no progress, this may require escalation to the support team. - Do not reinstall the pixel multiple times while waiting — this will not speed up detection. 📋 General Pixel Installation on GoHighLevel If you need to verify or redo your pixel installation on GoHighLevel, follow these general steps: 1. Locate your OTTO pixel snippet within the Search Atlas platform. 2. Log in to your GoHighLevel account and open the relevant sub-account. 3. Navigate to your site's settings and find the area where you can add tracking or header scripts. 4. Paste your OTTO pixel snippet into the appropriate field. 5. Save your changes and publish or re-publish your site so the updated code goes live. ✅ Before Escalating Before reaching out to support, confirm the following: - Pixel is installed: The OTTO pixel snippet has been added to your GoHighLevel site's script or tracking code area. - Site is published: You have saved and re-published your GoHighLevel site after adding the pixel. - Sufficient time has passed: You have waited a reasonable amount of time after installation before expecting pixel detection to update. - Crawl status: Check whether a crawl is still running or appears stalled — a slow crawl may be the cause of the delay. 🚨 When to Escalate If your pixel remains undetected after confirming the above steps, or if your crawl appears stuck with no progress for an extended period, please contact support. When escalating, have the following ready: your project or site name, the domain where the pixel is installed, and any error messages or status indicators you are seeing. 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.

🔑 Fix a 401 Invalid API Token in Signal Genesys

🚨 What This Error Means When you attempt to publish a press release through Signal Genesys and see a 401 'API Token is invalid' error, it means Signal Genesys cannot authenticate your request. This is a credential issue, not a platform permission problem. The token you have entered is either incorrect, expired, or has not been saved properly. This error will always block publishing until the API token is corrected. A simple refresh or retry will not resolve it. 🔍 Common Causes - The API token was copied with an extra space at the beginning or end. - The token was regenerated in your press release distribution account but not updated in Signal Genesys. - The token was entered into the wrong field during setup. - The token has been revoked or expired by your distribution provider. - The integration was set up using a test token that is no longer valid in production. 🛠️ How to Fix the Error 1. Log in to your press release distribution account and navigate to your account settings or API / developer section to locate your current API token. 2. Copy the token carefully. Click the copy button if one is available, rather than selecting the text manually. This reduces the risk of including hidden spaces or missing characters. 3. Open Signal Genesys, the separate site connected to Search Atlas via API key. 4. Locate the API key or credential field within Signal Genesys where your distribution provider token is stored. 5. Clear the existing token completely before pasting. Do not paste over the old value, as residual characters can cause validation failures. 6. Paste your new token and check that no spaces appear before or after it. 7. Save your settings. 8. Attempt to publish your press release again. If the token is valid, the 401 error will no longer appear and your submission will proceed. ✅ How to Confirm Your Token Is Valid Before re-entering your token in Signal Genesys, verify it is active in your distribution provider's dashboard. Most providers display a status label such as Active, Enabled, or show a last-used date. If your token shows as expired, revoked, or is missing entirely, generate a new one from within that provider's platform and use the new value. If your provider requires you to set specific permissions for the token (such as publish or submit access), confirm those permissions are enabled. A token that exists but lacks the correct scope will still return a 401 error. 🔄 If You Recently Regenerated Your Token API tokens generated in your distribution provider's account must be manually updated in Signal Genesys — the integration does not refresh them automatically. Any time you regenerate or rotate your token on the provider side, repeat the steps above to update the value stored in Signal Genesys. 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.

⚡ Fix Search Atlas WordPress Site Crash After Plugin Activation

Overview If your WordPress site crashes or shows a critical error immediately after activating the Search Atlas plugin, the most likely cause is a PHP version incompatibility. Running the plugin on an unsupported PHP version can cause a fatal error and may take your site offline. This article walks you through confirming the root cause, recovering your site, and safely re-activating the plugin once your environment meets the requirement. Root Cause The Search Atlas WordPress plugin requires a minimum PHP version to function correctly. If your hosting environment runs an older PHP version than required, WordPress will throw a fatal error when the plugin initialises, making your site inaccessible through the browser. Step 1 — Check Your Current PHP Version Before making any changes, confirm which PHP version your server is running. The exact steps depend on your hosting provider. Common options include: - Hosting control panel (e.g., cPanel, Plesk): Look for a PHP or software configuration section within your control panel. Your hosting provider's documentation will show you exactly where this is located. - Managed WordPress hosting dashboards (e.g., Kinsta, WP Engine, SiteGround): Check your site's settings or environment section. Refer to your host's support documentation for the exact location. - No panel access: Contact your hosting provider directly and ask them to confirm the PHP version your site is running. If your PHP version does not meet the plugin's minimum requirement, that is the cause of the crash. Proceed to Step 2. Step 2 — Recover Your Site (If It Is Currently Down) Because the WordPress admin dashboard may be inaccessible when a fatal error is active, you may need to deactivate the plugin directly on the server. You can do this using FTP, SFTP, or your hosting provider's file manager tool. 1. Connect to your server using an FTP/SFTP client or open the file manager available in your hosting control panel. 2. Navigate to your WordPress plugins directory (typically found within the wp-content/plugins/ folder). 3. Locate the Search Atlas plugin folder. 4. Rename or remove the folder so that WordPress can no longer load the plugin. WordPress will automatically deactivate a plugin when its folder is no longer accessible. 5. Reload your website in a browser. Your site should now be accessible again. Once your site is back online, log in to your WordPress admin dashboard to confirm the plugin is shown as inactive. Step 3 — Upgrade Your PHP Version Contact your hosting provider and request that they upgrade your PHP version to one that meets the Search Atlas plugin's minimum requirement. Most managed hosting providers can do this quickly, and many allow you to change the PHP version yourself through their contro 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.

🛠️ Rank Math Compatibility and Deployment Troubleshooting

🔍 Overview Search Atlas is a powerful SEO platform that works alongside WordPress SEO plugins like Rank Math. While the two tools can coexist, there are important differences in how they handle on-page optimizations. Understanding this relationship will help you avoid conflicts and ensure your changes are deployed correctly to your site. ⚙️ How Search Atlas and Rank Math Interact Search Atlas does not directly integrate with Rank Math. Each tool manages SEO data independently, which means changes made in Search Atlas are not automatically synced to Rank Math, and vice versa. Specifically, you should be aware of the following: - Meta titles and descriptions: Rank Math controls these fields inside WordPress. If Rank Math is active, its meta settings will take priority over any conflicting values on the page. - Schema markup: Both tools can output schema. Running both simultaneously may produce duplicate or conflicting schema, which can negatively impact your search appearance. - Canonical tags: If Rank Math is managing canonicals, edits made elsewhere may be overridden on the front end. 🚀 Deploying Optimizations Correctly To ensure your Search Atlas recommendations are applied accurately to your site, follow these steps: 1. Identify which tool owns each element. Decide whether Rank Math or Search Atlas will be the source of truth for meta tags, schema, and canonicals. Avoid letting both tools control the same element. 2. Apply content recommendations manually. Use the content suggestions from Search Atlas — such as keyword placement, heading structure, and body copy improvements — and apply them directly inside your WordPress page or post editor. 3. Update meta data inside Rank Math. If Rank Math is active on your site, update your meta title and meta description directly within the Rank Math panel in the WordPress editor. Do not rely on Search Atlas to push these values automatically. 4. Disable duplicate features in Rank Math. If Search Atlas or another tool is handling schema, turn off the corresponding schema feature inside Rank Math to prevent conflicts. Navigate to Rank Math → Schema settings in your WordPress dashboard and disable any overlapping schema types. 5. Verify changes on the live page. After applying updates, use a browser or an SEO audit tool to inspect the live page source and confirm your meta tags, schema, and canonical tags are rendering as expected. 💡 Best Practices for Using Both Tools Together Following these best practices will help you get the most out of Search Atlas while keeping Rank Math running smoothly: - Use Search Atlas for keyword research, content briefs, rank tracking, and site-wide SEO analysis. - Use Rank Math for on-page WordPress-level controls such as meta fields, redirects, and sitemaps. - Perform a content audit after applying Search Atlas recommendations to confirm no Rank Math settings are overriding your changes. - Keep both plugins and platform accounts updated to benefit from the latest compatibility improvements. 📊 Checking Your Keyword and Ranking Data After deploying your optimizations, you can monitor performance directly inside Search Atlas: - To track keyword rankings, go to Left sidebar → Keywords → Rank Tracker. - To research new keyword opportunities, go to Left sidebar → Keywords. - To identify keyword gaps between your site and competitors, go to Left sidebar → Keywords → Keyword Gap. Allow 24–72 hours after deploying changes before evaluating ranking shifts, as search engines need time to recrawl and reindex updated pages. 🆘 Need More Help? 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.

🔗 Troubleshooting Common Link Lab Issues

🔍 Overview Link Lab is Search Atlas's managed link-building tool that lets you place articles on publisher sites to earn high-quality backlinks. Like any complex workflow, occasional technical issues can arise — from orders missing article content to submission errors. This article walks you through the most common Link Lab problems and how to fix them. ⚠️ Common Link Lab Issues and What They Mean Below are the most frequently reported issues in Link Lab and what typically causes them. - Order created but no article is shown for review: This can happen when an order is placed through the AI Agent and the article fails to attach correctly to the order record. The order exists, but the content is missing from the review screen. - Article submission not completing: The Content Genius to Link Lab bridge occasionally encounters errors when passing a drafted article into a Link Lab order. The article may appear complete in Content Genius but fail to transfer. - Missing "Replace Publisher" option: On some existing orders, the option to swap the publisher is not visible. This is a known issue that has been resolved for new orders, but older orders may still be affected. - Misleading post-completion guidance: After an order is marked complete, some users see edit prompts that no longer apply. This is a display issue and does not affect your order status. 🛠️ Step-by-Step Troubleshooting Work through these steps before contacting support. Most issues can be resolved without escalation. 1. Refresh the order page. Navigate away from the order and return to it. Some display issues resolve with a fresh page load. 2. Check your order status. In Link Lab, locate your order and confirm its current status. If the status shows as complete but no article is visible, the content may not have transferred correctly. 3. Verify the article in Content Genius. Go to Left sidebar → Content → Content Genius and check whether the article was saved there. If the article exists in Content Genius but did not appear in your Link Lab order, this confirms a transfer issue. 4. Re-submit the article manually. If the article is available in Content Genius, try re-initiating the submission to Link Lab from within the article editor. Look for the Link Lab submission option in the article actions menu. 5. Check for browser or cache issues. Hard-refresh your browser (Ctrl+Shift+R on Windows, Cmd+Shift+R on Mac) and try again. Try a different browser if the issue persists. 6. Note your order ID. If you still see a problem, make a note of your order ID (for example, a number such as 34611) before contacting support. This helps our team investigate quickly. 📋 Information to Have Ready Before Contacting Support If the steps above do not resolve your issue, our support team will need the following details to investigate efficiently. - Your order ID or order number (visible on the order detail page) - The publisher name associated with the order, if known - A brief description of what you expected to happen versus what actually occurred - Any error messages displayed on screen (a screenshot is helpful) - Whether the order was created manually or via the AI Agent 💡 Tips to Avoid Link Lab Issues - Always review your article fully in Content Genius before submitting it to Link Lab. Incomplete drafts can cause transfer failures. - Avoid closing the browser tab immediately after placing an order. Wait for the confirmation screen to fully load. - If using the AI Agent to create Link Lab orders, double-check the order page shortly after the agent completes the task to confirm the article is attached. - For older orders missing the "Replace Publisher" option, create a new order with your preferred publisher rather than editing the existing one. 💬 Still Need Help? If you have followed the steps above and your Link Lab issue is not resolved, our team is ready to assist. 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.

🛠️ Fix WordPress Plugin Performance Issues

🔍 Overview The Search Atlas WordPress plugin is designed to run efficiently in the background, but in some configurations it can contribute to slower page load times. This article helps you identify whether the plugin is contributing to a slowdown and explains what information to gather before escalating to our team for investigation. ⚡ Common Causes of Plugin-Related Slowdowns Before diving into troubleshooting, it helps to understand what typically causes a WordPress plugin to slow down a site: - Conflicting plugins: Another active plugin may be interfering with how Search Atlas processes data on the page. - Outdated plugin version: Running an older version of the Search Atlas plugin can introduce inefficiencies that have since been fixed. - Shared or low-resource hosting: Hosting environments with limited CPU or memory can amplify the performance impact of any active plugin. - Heavy page builders or themes: Resource-intensive themes can compound the load added by plugins. 🧪 Step 1 — Confirm the Plugin Is the Source Before making any changes, verify that the Search Atlas plugin is actually responsible for the slowdown. 1. Use a free tool such as GTmetrix or Google PageSpeed Insights to run a baseline speed test on your site with the plugin active. 2. Temporarily deactivate the Search Atlas plugin from your WordPress dashboard under Plugins → Installed Plugins. 3. Run the same speed test again and compare the results. 4. If load times improve significantly with the plugin deactivated, the plugin is a contributing factor and you should proceed to the steps below. 🔄 Step 2 — Update the Plugin Always ensure you are running the latest version of the Search Atlas plugin. Updates frequently include performance improvements and bug fixes. 1. In your WordPress dashboard, go to Plugins → Installed Plugins. 2. If an update is available for Search Atlas, click Update Now. 3. After updating, clear your site cache and run another speed test to check for improvement. 📋 Step 3 — Gather Information for Escalation Because WordPress plugin performance issues often require backend investigation by our team, it is important to collect the following details before reaching out so we can investigate as quickly as possible: - Your site URL: The full URL of the affected WordPress site. - Plugin version: The exact version of the Search Atlas plugin currently installed (visible under Plugins → Installed Plugins). - Speed test results: Screenshots or URLs from GTmetrix or Google PageSpeed Insights showing the slowdown, ideally with the plugin both active and deactivated. - When the issue started: Note the approximate date and time you first noticed the performance degradation. - Other active plugins: A list of any other plugins running on your site at the time of the issue. - Hosting environment: Your hosting provider and plan type (e.g., shared, VPS, managed WordPress). - Any recent changes: Note any updates, installations, or configuration changes made around the time the slowdown began. Our team will use this information to investigate the root cause and identify the appropriate fix for your environment. 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.

🛠️ Fix WordPress 'None Response' Publishing Errors

🔍 What Is the 'None Response' Error? When you attempt to publish an article directly to WordPress from Search Atlas, you may see an error message that reads None Response. This means Search Atlas sent the publish request to your WordPress site but received no valid reply in return. The connection was either blocked, timed out, or rejected before it could complete. This is almost always caused by a configuration issue on your WordPress site rather than a problem with Search Atlas itself. ⚙️ Common Causes of This Error - REST API is disabled: Search Atlas uses the WordPress REST API to publish content. If a plugin or server setting has disabled it, all publish requests will fail. - Incorrect API credentials: An invalid username, password, or Application Password will cause the connection to be rejected silently. - Security plugins blocking requests: Plugins like Wordfence, iThemes Security, or Cloudflare WAF rules can block external API calls from Search Atlas. - SSL certificate issues: An expired or misconfigured SSL certificate on your WordPress domain can prevent a secure connection from being established. - Server timeout or resource limits: Shared hosting environments with low memory or execution time limits may drop the request before a response is sent. 🚀 Step-by-Step Resolution 1. Verify your WordPress connection settings. In Search Atlas, go to the top-right avatar → Settings → Integrations / CMS Connectors and confirm that the WordPress site URL, username, and Application Password are all entered correctly. The URL must be a valid domain URL (for example, https://example.com). 2. Confirm the REST API is active. Open a new browser tab and navigate to yoursite.com/wp-json/wp/v2/posts. If you see a JSON response with post data, the REST API is working. If you see an error or blank page, the REST API is disabled and needs to be re-enabled in your WordPress settings or by deactivating the plugin that is blocking it. 3. Regenerate your Application Password. In your WordPress dashboard, go to Users → Profile, scroll to the Application Passwords section, delete the existing entry for Search Atlas, and create a new one. Copy the new password immediately and update it in Search Atlas. 4. Temporarily disable security plugins. Deactivate plugins such as Wordfence, All In One WP Security, or similar tools one at a time. Attempt to publish again after each deactivation to identify which plugin is blocking the request. Once identified, add Search Atlas IP addresses to the plugin's allowlist or whitelist. 5. Check your SSL certificate. Visit whatsmycertificate.com or a similar tool and enter your domain to confirm the SSL certificate is valid and not expired. An invalid certificate will cause secure API calls to fail silently. 6. Contact your hosting provider. If none of the above steps resolve the issue, ask your hosting provider to confirm that outbound REST API requests are permitted and that execution time and memory limits are sufficient to handle publishing requests. 💡 Tips to Prevent This Error in Future - Use a dedicated Application Password for Search Atlas rather than your main account password. - Avoid using security plugins that blanket-block all REST API requests unless you can configure per-application exceptions. - Keep your WordPress core, plugins, and themes updated to reduce conflicts that can affect API behavior. - Test your WordPress connection inside Search Atlas after any major site update or hosting migration. 📊 Challenge Access Eligibility Some Search Atlas features, including certain publishing challenges or content campaigns, require your WordPress integration to be fully verified and active before you can participate. If you are seeing a message indicating you are not eligible for a challenge, the most likely reason is that your WordPress connection has not been successfully established or has recently disconnected due to one of the errors described above. To restore eligibility, resolve the None Response error using the steps above, then re-verify your WordPress connection inside Search Atlas. Once the connection returns a successful status, challenge access should be restored automatically within a few minutes. 🆘 Still Need Help? If you have followed all of the steps above and the error persists, 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.

🔌 Webflow CMS Connector: Common Failures and How to Fix Them

🛠️ Common failure modes and fixes 🔑 Authentication error — connector marked invalid Click Reconnect and complete Webflow provider sign-in in the new tab. If the provider sign-in was cancelled or expired, start the reconnect flow again and wait for the connection status to update. 📁 Missing collection — publish fails immediately Edit the connector and select a valid Webflow collection before publishing. Confirm that the collection still exists in Webflow. 🧩 Custom field schema mismatch — publish fails Make sure the Webflow collection fields match the connector mapping. If fields were renamed, removed, or retyped, update the mapping and republish. ⏳ Rate limit — publish hangs or times out Search Atlas retries temporary Webflow rate-limit errors automatically. Wait 5–10 minutes and check the publish status. If the job remains pending, reconnect the connector and retry. 🖼️ Featured image missing Confirm the source image is accessible, then re-upload it in Content Genius and republish. If the connector still fails after reconnecting, open the chat widget in the bottom-right corner of the platform and type human teammate.

🛠️ Fix Search Atlas Conflicts With Rank Math

🔍 Overview Some customers notice issues with the Rank Math WordPress plugin — such as schema editor errors or broken SEO settings — and disrupted Google Search Console or Google Analytics connections shortly after installing the Search Atlas WordPress plugin. This article explains why this happens and how to resolve it quickly. ⚙️ Why This Happens Search Atlas and Rank Math are both powerful SEO tools, and when they run on the same WordPress site, they can compete over certain resources. Known conflict triggers include overlapping plugin functionality, Google integration interference, and script loading issues in the WordPress admin environment. ✅ How to Resolve the Conflict Follow these steps in order. Most customers resolve the issue after completing Steps 1 and 2. 1. Disable overlapping schema features in one plugin. Choose which plugin will own your schema output — Search Atlas or Rank Math — and disable schema generation in the other. Refer to your chosen plugin's official documentation for the exact setting location, as menu paths may vary by version. 2. Reconnect your Google integrations. After adjusting schema settings, disconnect and reconnect your Google Search Console and Google Analytics accounts in both plugins, one at a time. Reconnect Search Atlas first, confirm the data loads, then reconnect Rank Math. 3. Deactivate plugins one by one to isolate conflicts. If the Rank Math settings panel is still broken, temporarily deactivate Search Atlas, clear your browser cache, and reload the Rank Math editor. If it works, the conflict is confirmed. Re-enable Search Atlas and contact support for further guidance. 4. Check for plugin and WordPress core updates. Outdated plugin versions are a common trigger for compatibility issues. Update both Search Atlas and Rank Math to their latest versions, then update WordPress core if an update is available. 5. Clear caching layers. If you use a caching plugin (e.g., WP Rocket, W3 Total Cache) or a CDN, purge all caches after making any changes. Stale cached files frequently cause errors to persist even after the root conflict is resolved. 🚫 What to Avoid - Do not run two SEO plugins with identical features both fully active at the same time without disabling the overlapping functionality in one of them. - Do not attempt to authenticate the same Google account in both plugins simultaneously without first disconnecting one, as this can cause token conflicts. 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.

⚡ OTTO Cloudflare Worker Double-Encoding Special Characters Fix

What Happened A confirmed bug in the OTTO Cloudflare worker script caused double-encoding of special characters such as & and ' on sites connected via Cloudflare (including Webflow sites). Instead of rendering correctly, these characters appeared as raw HTML entities (for example, & or ') visible to visitors on the frontend. This issue affected headings, page copy, and other injected content anywhere the OTTO Cloudflare worker script was active. How to Check If Your Site Is Affected Review the pages where OTTO is active and look for raw HTML entities such as & or ' appearing visibly in headings or body copy on the frontend. If your site uses a caching layer (Cloudflare cache or Webflow's CDN), perform a hard refresh or clear your cache to ensure you are viewing the latest version of your pages before concluding the issue is present. What to Do 1. Disengage OTTO from your site immediately to stop further character corruption. In your Search Atlas dashboard, navigate to OTTO SEO → All Sites (SEO Automation) and disengage the connection for the affected site. 2. Clear your Cloudflare worker script. In your Cloudflare dashboard, go to Workers & Pages, locate the OTTO worker script associated with your site, and delete or disable it. 3. Clear your site cache. In Cloudflare, go to Caching > Configuration and select Purge Everything to ensure no cached version of the corrupted content is served. If you are on Webflow, also purge the Webflow CDN cache from your Webflow project settings. 4. Verify the characters render correctly on your frontend by performing a hard refresh (Ctrl+Shift+R or Cmd+Shift+R) and checking the previously affected headings and copy. 5. Reconnect OTTO once the fix has been confirmed. Return to your Search Atlas dashboard, navigate to OTTO, and re-engage the connection for your site using the latest worker script provided. This ensures the patched version of the script is installed rather than the previous bugged version. If You Previously Disengaged OTTO If you already disengaged OTTO to prevent further character corruption, follow steps 2 through 5 above to clear the old worker script, verify the frontend, and safely reconnect using the updated script. When to Contact Support Reach out to the Search Atlas support team if any of the following apply: - Special characters are still displaying as raw HTML entities after completing the steps above - You are unable to locate or remove the Cloudflare worker script - You are unsure whether your site is affected by this bug You can contact the Search Atlas support team via live chat only — use the chat widget in the bottom-right corner of the platform and type human teammate to reach a member of the team.

🛠️ Fix Missing WordPress Plugin Element Removal Checkbox

🔍 Overview When managing your website through the Search Atlas WordPress plugin, you may notice that a checkbox previously used to remove a specific plugin element has disappeared. This is a known UI behaviour that occurs under certain conditions. This article explains why it happens and walks you through the steps to restore and use the checkbox successfully. ❓ Why Does the Checkbox Disappear? The element removal checkbox is conditionally displayed based on the current state of your plugin settings and the detected elements on your page. The checkbox may no longer appear if: - The target element has already been removed or is no longer detected on the page. - A settings save or page refresh has caused the UI to re-evaluate which controls are relevant. - The plugin has been updated and the interface has changed slightly. - Your browser has cached an outdated version of the plugin admin panel. 🛠️ How to Restore the Element Removal Checkbox Follow these steps in order to bring the checkbox back and remove the desired plugin element from your website. 1. Clear your browser cache. An outdated cache is the most common cause. In your browser settings, clear cached images and files, then reload the WordPress admin panel. 2. Deactivate and reactivate the Search Atlas plugin. In your WordPress dashboard, go to Plugins > Installed Plugins, deactivate the Search Atlas plugin, wait a few seconds, then reactivate it. This resets the plugin state and often restores missing UI elements. 3. Navigate back to the correct settings screen. Go to the Search Atlas plugin settings page where the element removal option was previously displayed. Some controls only appear when you access the specific sub-section they belong to rather than the top-level settings page. 4. Check whether the element is still present on your site. Visit the front end of your website and confirm the element you want to remove is still visible. If it has already been removed, the checkbox will not appear because there is nothing left to act on. 5. Re-save your plugin settings. On the relevant settings screen, click Save or Save Changes without making any other edits. This forces the plugin to re-evaluate your configuration and redisplay all applicable controls, including the element removal checkbox. 6. Disable conflicting plugins temporarily. Another active plugin may be interfering with the Search Atlas admin interface. Temporarily deactivate other plugins one by one, refreshing the page after each, to identify any conflicts. ✅ Confirming the Element Has Been Removed Once the checkbox is visible again and you have selected it: - Click Save or Save Changes to apply the removal. - Visit the front end of your website in a new private or incognito browser window to confirm the element no longer appears. - If you use a caching plugin (such as WP Rocket or W3 Total Cache), purge your site cache after saving to ensure visitors see the updated version of your pages. 🚫 Still Not Seeing the Checkbox? If you have completed all of the steps above and the element removal checkbox is still missing, it is possible that: - Your version of the Search Atlas plugin is outdated. Go to Plugins > Installed Plugins and check for available updates. - A theme or custom code on your site is hiding the admin panel element. - The feature requires a specific plan or permission level that may not be active on your account. 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.

Fix Twitter/X OAuth Integration Login Loop

🔍 Overview Some users experience a login loop when attempting to connect their Twitter/X account in Search Atlas. Instead of completing the connection, the platform repeatedly redirects to a sign-in page even when you are already logged in to Twitter/X. This issue requires investigation and resolution by our support team directly on your account. ⚠️ What This Looks Like - You click the option to connect your Twitter/X account. - You are redirected to a Twitter/X sign-in or authorization page. - After signing in (or if you are already signed in), the page loops back and requests sign-in again. - The account never successfully links and you cannot proceed. ✅ Steps to Resolve 1. Contact our support team and describe the loop you are experiencing. Because this issue requires back-end investigation on your specific account, reach out to our support team so they can examine the OAuth connection directly and get your Twitter/X account linked. To contact support, use the live chat widget in the bottom-right of the platform. 2. Provide your account details when you reach out. Share the email address associated with your Search Atlas account and confirm which Twitter/X account you are trying to connect. This allows the team to locate your account and investigate the OAuth issue promptly. 3. Our team will investigate and resolve the OAuth connection on your behalf. Once the team has reviewed the back-end state of your account's Twitter/X integration, they will apply the necessary fix and confirm when your account has been successfully linked. 💡 While You Wait - Make sure you are fully logged in to your Twitter/X account in your browser, as an active session may assist the team's investigation. - Do not attempt to disconnect or reconnect the account repeatedly, as this may complicate the back-end state our team needs to review. 🆘 Still Experiencing the Loop? If your Twitter/X connection loop is still occurring after contacting us, please reply to your existing support conversation so we can continue investigating. You can also reach our support team using the live chat widget in the bottom-right of the platform.

SA Plugin Breaking WordPress Navigation Menu

Overview Some WordPress sites experience a navigation menu that becomes fully expanded or visually broken immediately after activating the Search Atlas (SA) plugin. Deactivating the plugin restores the menu, which confirms the plugin is involved. This appears to be a plugin-related conflict, though the exact underlying cause may vary by site configuration. This article explains how to immediately restore your site, steps you can try to resolve the conflict yourself, and how to escalate if self-serve steps do not fully resolve the issue. Is This Your Issue? You are likely experiencing this issue if all of the following are true: - You recently installed or activated the Search Atlas WordPress plugin on a site. - The site's navigation menu is unexpectedly expanded, distorted, or broken in appearance. - Deactivating the SA plugin immediately restores the navigation menu to normal. - Reactivating the plugin causes the problem to return. Self-Serve Steps to Restore Your Site and Resolve the Conflict Follow these steps in order. Many users are able to reduce or resolve the conflict without needing to keep the plugin deactivated. 1. Deactivate the Search Atlas plugin from your WordPress admin panel by going to Plugins → Installed Plugins, locating Search Atlas, and clicking Deactivate. This immediately restores your navigation menu and keeps your site functional for visitors while you troubleshoot. 2. Confirm the fix by visiting your site's front end and verifying the navigation menu appears correctly after deactivation. If it does, the SA plugin is confirmed as contributing to the issue. 3. Check for plugin conflicts by temporarily deactivating all other plugins except Search Atlas, then reactivating them one at a time. If the menu breaks again when a specific plugin is reactivated alongside Search Atlas, that combination is likely the source of the conflict. Note which plugins are active when the problem occurs and include this information if you need to contact support. 4. Switch to a default WordPress theme temporarily (such as Twenty Twenty-Three) to determine whether your active theme is contributing to the conflict. If the menu displays correctly with Search Atlas active and a default theme in use, the conflict may be theme-specific. Contact your theme developer with these findings. 5. Document what you observe — including your theme name, active plugins, and WordPress version — so you can provide full context if you need to escalate. When to Contact Support If you have worked through the steps above and the navigation menu remains broken whenever the Search Atlas plugin is active, please reach out to the Search Atlas support team. Share the details you gathered — your theme, active plugins, and WordPress version — so the team can investigate and escalate to engineering if needed. To get help, use the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔌 Fix OTTO Pixel WordPress Authentication & Communication Errors

🧭 Overview If your OTTO pixel shows as Connected inside the WordPress plugin but the Search Atlas dashboard cannot communicate with it — and you see an Authentication credentials were not provided error — this is a known authentication sync failure between the OTTO WordPress plugin and Search Atlas. Cache clearing and reinstalling the plugin alone will not resolve this type of error. Because the exact steps to fix this depend on your specific account and site configuration, the most reliable path is to contact our support team directly so an agent can investigate and resolve it on your account. ⚠️ What This Error Typically Indicates - The API credentials stored in the plugin are missing, expired, or out of sync with Search Atlas. - The plugin installation itself is generally not the root cause. - A mismatch between the site URL registered in Search Atlas and the live WordPress site URL may contribute to the failure. - Security plugins, firewalls, or caching layers on the WordPress side can sometimes interfere with authentication requests. 📋 Before You Contact Support — What to Have Ready To help our team resolve this as quickly as possible, please have the following information available when you reach out: - The exact error message you are seeing (e.g., Authentication credentials were not provided). - The domain/URL of the affected WordPress site. - The name of the Search Atlas project or site the OTTO pixel is connected to. - The date and approximate time the error first appeared. - Whether any recent changes were made — such as regenerating an API key, switching from HTTP to HTTPS, installing a new security or caching plugin, or migrating the site. - Any other active WordPress plugins that handle security, firewalls, or HTTP authentication. 🛠️ While You Wait You can take the following general steps to rule out common environmental causes before an agent reviews your account: - Confirm that the site URL registered in Search Atlas exactly matches your live WordPress site URL — including the same protocol (https://) and the same trailing slash convention. - Temporarily deactivate any security or firewall plugins on your WordPress site to test whether they are stripping authentication headers from outgoing requests. - Clear any server-side or CDN cache layers so that requests are not being served stale or blocked responses. - Do not reinstall the plugin or regenerate your API key until an agent confirms this is the correct next step — doing so without guidance can complicate diagnosis. 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.

🔌 Fix WordPress Plugin Pixel Not Connected Error

Overview After installing the Search Atlas WordPress plugin and completing the authorization flow, some users see a "pixel not connected" status message. Because the source of this issue can vary by site configuration, our support team will need to investigate your specific setup to identify and resolve the root cause. What This Article Covers This article explains what the error means and helps you prepare the information our team needs to resolve the issue as quickly as possible. It does not contain self-serve troubleshooting steps, because the correct resolution depends on details that must be reviewed by a support teammate. What "Pixel Not Connected" Means This status message indicates that Search Atlas has not been able to confirm that the pixel is active and communicating correctly on your site. This can occur for a number of reasons related to your WordPress environment, and diagnosing it requires a review of your account and site configuration. What to Have Ready Before Contacting Support To help our team resolve this as quickly as possible, please gather the following information before reaching out: - The website URL (property) showing the "pixel not connected" status in your Search Atlas account. - The WordPress version your site is running. - The version of the Search Atlas plugin currently installed. - Confirmation of whether you completed the authorization step after installing the plugin. - Any error messages displayed in the plugin settings page or in the Search Atlas platform, copied exactly as they appear. - The date and approximate time when you first noticed the status message. 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.

🔧 Fix SMTP/IMAP Email Authentication Failures

🔍 What Is This Error? When connecting your email account to Search Atlas, you may encounter an SMTP authentication failed error or an IMAP connection failure. This typically appears when linking a Google (Gmail or Google Workspace) account and prevents outgoing or incoming email from syncing correctly. This error is not caused by your browser cache or cookies. It is almost always related to account security settings or app permissions. Follow the steps below to attempt to resolve it. ⚙️ Step 1: Check Your Google Account Security Settings Google has strict security controls that block connections from third-party apps using basic username and password authentication. To allow Search Atlas to connect, you need to verify the following: - Two-Factor Authentication (2FA): If 2FA is enabled on your Google account, you may need to use an App Password instead of your regular password (see Step 2). - Account permissions: Confirm the Google account you are connecting is the same one you use to sign in to Search Atlas. 🔑 Step 2: Generate a Google App Password An App Password is a 16-character code that can give Search Atlas secure access to your Google account without exposing your main password. To create one, navigate to your Google Account security settings, locate the 2-Step Verification section (you must have 2FA enabled), and look for the App passwords option. Follow Google's on-screen prompts to generate a password for use with Search Atlas. Once you have your App Password, return to your email connection settings in Search Atlas and re-enter your credentials using this App Password in place of your regular password. 📋 Step 3: If the Issue Persists, Contact Support Because SMTP/IMAP authentication failures in Search Atlas can stem from account-specific configuration details that vary by setup, some cases require hands-on assistance from our team. Before reaching out, please have the following ready to help us resolve your issue as quickly as possible: - The exact error message you are seeing - The email address you are trying to connect - Whether your account uses standard Gmail or Google Workspace - Whether two-factor authentication (2FA) is enabled on the account - Any steps you have already tried 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.

🔧 Fix OTTO Pixel UUID Sync Issues in WordPress

Overview The OTTO Pixel UUID is a unique identifier that connects your WordPress site to your Search Atlas project. When the UUID fails to sync correctly, OTTO cannot activate or apply SEO changes to your site. This article explains what to check if you are experiencing UUID synchronization issues between your WordPress site and your Search Atlas project. What to Check First If your OTTO Pixel UUID is not syncing correctly between your WordPress site and Search Atlas, try the following steps: 1. Confirm you are using the correct UUID. Open your Search Atlas dashboard and locate the OTTO Pixel UUID for the specific project you are working with. Make sure you are not using a UUID from a different project. 2. Re-copy and re-enter the UUID. Copy the UUID directly from Search Atlas, then paste it into the UUID field in your Search Atlas WordPress plugin settings and save. Avoid copying from formatted documents, as this can introduce invisible characters. 3. Clear your caches. After updating the UUID, clear your WordPress plugin cache, any active caching plugins, and your browser cache, then check whether the sync resolves. 4. Ensure your Search Atlas WordPress plugin is up to date. An outdated plugin version may affect how the UUID is handled. Check for available plugin updates in your WordPress admin panel and install them if present. If the Issue Persists If you have followed the steps above and the UUID still fails to sync, our support team can investigate further. When reaching out, please have the following ready: - The name of the Search Atlas project you are trying to connect - The OTTO Pixel UUID you are using (or a screenshot of the UUID field in your plugin) - A description of exactly what you see — for example, whether the plugin shows an error, no status, or a mismatch message - Any steps you have already tried 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. Additional Notes Deactivate/reinstall step: In WordPress, go to Plugins → Installed Plugins, click Deactivate then Delete next to OTTO Pixel, copy pixel key again from Search Atlas (OTTO SEO → All Sites (SEO Automation) → [Site] → Installation Guide), reinstall plugin, re-enter key. Also: after saving, wait up to 60 seconds for Search Atlas to detect the connection.

🔄 Fix Twitter/X Account Stuck in Login Loop

🔍 What This Article Covers Some users experienced an issue where connecting a Twitter/X account in Search Atlas would repeatedly reload the login screen without ever completing the connection. This article explains what caused the issue and what to do if you still see it. ⚙️ What Was Causing the Problem This was a platform-level bug — not an issue with your Twitter/X credentials or account settings. The root cause involved two separate technical problems: - A restricted API field was returning a 403 error from Twitter/X during the authentication handshake, causing the connection to fail silently. - A stale authentication error was not being cleared after you attempted to reconnect, so every retry failed even if your credentials were valid. Both issues have been fully resolved by the Search Atlas engineering team and the fixes are live in production. ✅ Steps to Connect Your Twitter/X Account Now 1. Log in to your Search Atlas account. 2. Navigate to the social media integrations section of the platform. 3. Locate the Twitter/X integration and begin the connection process. 4. When the Twitter/X login screen appears, enter your credentials and authorise access as prompted. 5. If you had previously attempted to connect and seen the loop, use the reconnect or retry option — this now correctly clears any stale authentication state and starts a fresh connection. 6. Once authorised, your Twitter/X account should link successfully and you will be returned to the platform. 🛠️ If the Loop Still Appears The engineering fixes have been confirmed live, and the issue is resolved for the vast majority of users. However, if you are still experiencing the login loop, try the following before reaching out: - Clear your browser cache and cookies, then attempt the connection again in a fresh browser session. - Try a different browser or an incognito/private window to rule out a local session conflict. - Disconnect any existing partial connection to Twitter/X in your account settings before attempting to reconnect. If none of the above resolves the issue, it is important to let our team know so we can investigate further on your specific account. 💬 Still Need Help? 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.

🔌 Fix Shopify CMS Connector Authentication Failures

🔍 Overview The Search Atlas Shopify CMS Connector links your live Shopify store to the platform so you can publish and manage SEO content directly. Authentication failures prevent this connection from forming. This article explains what to expect when authentication fails and how to prepare your case for our engineering team to investigate. ⚠️ About Shopify CMS Connector Authentication Failures When the Shopify CMS Connector fails to authenticate, the connection between Search Atlas and your Shopify store cannot be established. This type of failure occurs at the integration level and typically requires backend investigation to resolve. The exact cause can vary and must be confirmed by our team after reviewing your specific case. 📋 What to Have Ready When You Escalate Because Shopify CMS Connector authentication failures require investigation at the integration level, please have the following information ready when you contact support: - Your Shopify store domain (for example, yourstore.myshopify.com) - The exact error message you see when the authentication fails - The date and time when the failure first occurred and any subsequent attempts - A description of the steps you took when the error appeared (for example, whether you were connecting for the first time or reconnecting an existing store) 📋 If Your Case Has Already Been Escalated If you have already reported this issue and were told it is under review, our engineering team is investigating the authentication failure at the integration level. No additional action is required from you at this stage. You will be updated as soon as a resolution or next step is available. 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.

🔗 Fix ClickUp Connector Stuck After OAuth Approval

🔍 What Is This Issue? When connecting ClickUp to your Search Atlas Coworker workspace, you may encounter a situation where the OAuth authorization window appears, you approve the connection, and then the screen shows a waiting or loading state with no further progress. The connector does not complete setup, and ClickUp remains disconnected. ⚠️ Why This Happened This was a confirmed bug in the ClickUp integration within the Coworker connector flow. The issue was reproduced by our support team and escalated to engineering. The root cause involved problems with the OAuth handling and real-time notification delivery during the connection attempt. Engineering resolved this through a series of backend fixes, including updates to the ClickUp OAuth flow, improved timeout handling, and real-time status notifications for connector attempts. ✅ Current Status This issue has been resolved. The engineering fixes have been deployed, and the ClickUp connector should now complete the OAuth authorization flow successfully. No action is required on your end beyond attempting the connection again. 🛠️ Steps to Reconnect ClickUp 1. Log in to your Search Atlas account and navigate to the Coworker section. 2. Go to the Connectors area and locate the ClickUp integration. 3. Start the connection process. The OAuth authorization window will open. 4. Approve the requested permissions in the ClickUp authorization window. 5. Wait a few seconds for the platform to confirm the connection. The connector should now show as connected without hanging. 6. If the connector shows as connected, you are all set and can begin using ClickUp within Coworker. 🔄 If the Issue Still Occurs While this bug has been marked resolved, if you are still experiencing a hanging or stuck state after completing OAuth approval, try the following before contacting support: - Refresh the page after approving access and check whether the connector status has updated. - Clear your browser cache and cookies, then attempt the connection again in a clean browser session. - Try a different browser to rule out a browser-specific compatibility issue. - Check your pop-up blocker settings to ensure the OAuth window is not being silently blocked or interrupted mid-flow. - Revoke the Search Atlas app permissions in your ClickUp account settings, then retry the connection from scratch to start with a clean authorization state. 💬 Need More Help? If you have followed all the steps above and the ClickUp connector is still not connecting, our team wants to hear from you so we can investigate further. 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.

🛠️ Search Atlas Plugin Incompatibility With Enfold Avia Builder

🔍 Overview If you are using the Search Atlas WordPress plugin alongside the Enfold theme and its built-in Avia Builder, you may find that you cannot type text into any field on your website. This is caused by a known conflict between the Search Atlas plugin and Enfold/Avia Builder. A fix for this incompatibility has been identified and deployed by the Search Atlas engineering team. If you are still experiencing this issue, follow the steps below. ✅ Is This Your Issue? You are likely affected if all of the following are true: - You have the Search Atlas plugin installed and active on your WordPress site. - Your WordPress theme is Enfold and you use the Avia Builder page editor. - You are unable to type letters or text into fields on your website's front end or within the builder. - The problem disappears when you deactivate or uninstall the Search Atlas plugin. ⚙️ What Caused This? The Search Atlas engineering team confirmed that a specific incompatibility existed between the Search Atlas plugin and the Enfold theme's Avia Builder. This conflict interfered with keyboard input across the site. A fix was developed, reviewed, and deployed to resolve this. 🚀 Steps to Resolve 1. Update the Search Atlas plugin. Log in to your WordPress admin dashboard, navigate to the Plugins section, and check whether an update is available for the Search Atlas plugin. If an update is available, install it immediately, as it contains the fix for this incompatibility. 2. Reactivate the plugin if you disabled it. If you deactivated or uninstalled the Search Atlas plugin as a workaround, reinstall it from the WordPress plugin repository or your account, then activate it. 3. Clear your WordPress and browser cache. After updating, clear any caching plugins you use as well as your browser cache to ensure the latest version of the plugin is fully loaded. 4. Test your site. Open a page that uses Avia Builder and confirm you can now type into text fields normally. 💡 If the Issue Persists If you have updated the plugin and are still unable to type on your site, our team will need to investigate further. To help us resolve this as quickly as possible, please be ready to provide: - Your WordPress admin login credentials (shared securely through the chat). - The version of the Search Atlas plugin currently installed. - The version of the Enfold theme you are using. - A screen recording or description of exactly where and when the typing issue occurs. 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.

🔧 Fix Cloudflare Worker API Token Validation Failures

Overview API token validation errors in the SearchAtlas Cloudflare Worker typically trace back to one of two root causes: the Worker script was not deployed correctly, or the API token is missing the required permissions. This article explains what to check and what information to have ready so our team can resolve the issue quickly. Step 1: Confirm You Have the Correct Worker Script Before troubleshooting token validation, confirm you are using the official SearchAtlas Worker script — not a generic Cloudflare template or an outdated version from a previous installation. - Log in to your SearchAtlas account and locate the Cloudflare Worker integration section to retrieve the current Worker script. If you are unsure where to find this in your account, our support team can point you to the exact location. - Do not use a script obtained from a third-party source or one that predates your current SearchAtlas account, as a mismatched script is a common reason token validation fails. Step 2: Deploy the Script in Cloudflare Once you have the correct SearchAtlas Worker script, deploy it through your Cloudflare dashboard. Replace any existing Worker code with the latest SearchAtlas script in full, then save and redeploy. Running an outdated script version can cause token validation to fail even if your token permissions are otherwise correct. After deploying, note the Worker's URL — you will need it when configuring the integration in SearchAtlas. Step 3: Review Your Cloudflare API Token Permissions Cloudflare API tokens are permission-scoped. A token that lacks the required permissions will fail SearchAtlas validation. When creating or reviewing your token in the Cloudflare dashboard, ensure it includes the permissions necessary for Cloudflare Worker script deployment and API token validation as required by the SearchAtlas integration. If you are unsure which permissions are needed, or if the token continues to fail validation after reviewing your setup, our support team can assist you directly. What to Have Ready When Contacting Support If you are unable to resolve the validation failure on your own, please have the following information ready before reaching out: - Your SearchAtlas project name - The exact error message you are seeing during token validation - A timestamp of when the error first occurred - A brief description of any changes made to your Worker script or API token before the issue began 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.

Fix Shopify Connector Error 400 Fast

What Is Error 400 on the Shopify Connector? A 400 Bad Request error on the Shopify connector means the connection request was rejected and could not be processed. This error has been observed when attempting to add a co-worker to a connected Shopify store inside Search Atlas. Because this error requires investigation on the backend, it cannot be resolved through self-serve steps alone — it needs to be escalated to the Search Atlas technical support team. What to Expect Once you report the issue, the technical team will investigate the connector configuration on the backend and work to resolve the error. You do not need to disconnect or reconnect your Shopify store, and you should avoid making changes to your connector settings while the investigation is in progress, as this may complicate the troubleshooting process. What to Have Ready Before Escalating To help the technical team resolve your issue as quickly as possible, please gather the following information before reaching out: - Your Search Atlas account email address - The name of the Shopify store affected by the error - The email address of the co-worker you were attempting to add when the error occurred - The exact error message displayed (a screenshot is ideal) - The date and approximate time the error first occurred 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.

🛠️ How to Fix WordPress Blog Display After Plugin Conflict

This article helps you fix a broken blog post display caused by a conflict between the WordPress block editor (Gutenberg) and Elementor. This is the most common reason a newly published post looks visually broken or unstyled on your live site — even though it appeared fine inside the editor. 🔍 Common Causes - Gutenberg vs. Elementor conflict: Content created or modified in one editor can break when rendered by the other. This happens when a post is partially built with Gutenberg blocks and partially with Elementor widgets, causing layout and style collisions. - Search Atlas WordPress plugin interaction: The plugin injects SEO metadata and schema markup at publish time, which can surface a pre-existing editor conflict that was previously hidden in draft mode. - Cached broken output: Your site may be serving a cached version of the broken layout even after you make corrections. 🛠️ Step-by-Step 1. Identify which editor built the post. Open the post in your WordPress dashboard. If you see a blue Edit with Elementor button at the top, Elementor owns the layout. If you see only the standard block editor toolbar, Gutenberg owns it. Do not mix both on the same post. 2. Choose one editor and rebuild if needed. If the post was accidentally opened and saved in Gutenberg after being built in Elementor (or vice versa), the layout data from the other editor may have been overwritten. Open the post exclusively in your chosen editor — either click Edit with Elementor or stay in the block editor — and review whether the content and layout are intact. Rebuild any sections that appear empty or collapsed. 3. Disable Elementor on posts you want to use with Gutenberg only. If you prefer to use the block editor for this post, open the post in Gutenberg, go to your post settings panel, and look for an Elementor-related option (sometimes labeled Elementor under the post's sidebar settings or document settings). Disable or remove Elementor data for that post so Gutenberg renders it cleanly. 4. Check the Search Atlas WordPress plugin settings. Open your WordPress admin dashboard and navigate to your installed plugins. Locate the Search Atlas plugin and open its settings. Confirm that any content injection or schema options are enabled only for the post types and templates you intend — an unexpected injection on a custom Elementor template can disrupt rendering. 5. Clear all caches. After making editor or plugin changes, clear your WordPress caching plugin cache (e.g., WP Rocket, W3 Total Cache, or LiteSpeed Cache) and, if applicable, your hosting-level cache and any CDN cache. Then reload the post on your live site in a private/incognito browser window. 6. Re-publish the post. In WordPress, open the post, make a minor edit (such as adding and removing a space), and click Update to force a fresh publish cycle. This ensures the Search Atlas plugin re-processes the post with the corrected layout intact. ✅ How to Confirm It Worked After completing the steps above, visit your live blog post URL in a private or incognito browser window (to bypass your local browser cache). Confirm the following: - The post content is fully visible, styled, and matches what you see inside the editor. - No raw block markup (e.g., <!-- wp:paragraph -->) appears on the page. - Images, headings, and any custom Elementor sections render in the correct positions. - Scrolling through the full post shows no collapsed, missing, or unstyled sections. If the page still appears broken after a hard refresh in incognito mode, the conflict may be at the theme or template level rather than the post level — proceed to the next step or contact support. 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.

🛠️ Fix ws_bulk_send_message HTTP 403 WebSocket Errors

🔍 Overview When using the Search Atlas AI agent via the Model Context Protocol (MCP), you may encounter a situation where the ws_bulk_send_message tool returns an HTTP 403 Forbidden error on the Website Studio WebSocket channel — even though all other MCP calls complete successfully and your project container appears healthy. This article explains what this error indicates and what information to have ready when escalating to the support team. ⚠️ What the Error Looks Like You may see error output similar to the following when the MCP agent attempts to send messages through the Website Studio WebSocket channel: - Error: ws_bulk_send_message failed — HTTP 403 - Context: WebSocket connection to the SearchAtlas agent channel is rejected - Scope: Only affects ws_bulk_send_message; other MCP tools (such as create_project or read operations) may appear to work normally - Container status: The project container reports as healthy 💡 Why This Happens An HTTP 403 on the ws_bulk_send_message WebSocket channel indicates an authentication or authorization failure during the WebSocket handshake in the Website Studio MCP integration. Because this error occurs at the infrastructure level, it cannot be resolved through client-side configuration changes alone and requires investigation by the support team. ✅ Steps to Take If you are experiencing this error, take the following steps: 1. Refresh your session: Log out of Search Atlas and log back in to clear any stale authentication state that may be cached in your browser or MCP client, then retry the operation. 2. Note your project name: Record the exact name of the Website Studio project you were working in when the error occurred. 3. Capture the exact error message: Copy the full error output returned by ws_bulk_send_message, including any error codes or stack trace details visible in your MCP client. 4. Record the timestamp: Note the date and time (including timezone) when the 403 error occurred so the support team can correlate it with server-side logs. 5. Escalate to support: If the error persists after refreshing your session, contact the support team with your project name, the exact error message, and the timestamp of the failure. This information is required for the team to investigate the WebSocket authentication failure on the backend. 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.

⚡ WordPress Plugin PHP Compatibility and Content Sync Alternatives

Overview The Search Atlas WordPress plugin requires a minimum PHP version to function correctly. If your hosting provider runs an older or unsupported PHP version, the plugin may not install or work as expected. This article explains how to check compatibility and how to continue working with your content if the plugin cannot be installed. PHP Version Compatibility Before installing the Search Atlas WordPress plugin, confirm the PHP version your hosting environment is running. You can usually find this information in your hosting control panel (e.g., cPanel, Plesk) under PHP Configuration or Software Settings. If your host is running an unsupported PHP version, the plugin will not be compatible. In that case, we recommend one of the following steps: - Upgrade your PHP version — Most hosting providers allow you to switch PHP versions from the control panel at no extra cost. Check your host's documentation or support resources for guidance on upgrading. - Contact your hosting provider — If you are unsure how to upgrade, ask your host's support team to update your PHP version on your behalf. - Use an alternative content sync method — If upgrading PHP is not possible, you can still use Search Atlas to create and manage content and then transfer it to WordPress manually. Alternative Method: Copy and Paste Content Manually You can write and optimise content fully inside Search Atlas and then manually transfer it to WordPress without the plugin. 1. Use the relevant Search Atlas content tools to create or optimise your content within the platform. 2. Once your content is complete, select and copy the text from the Search Atlas editor. 3. Paste it directly into the WordPress block editor or classic editor on your site. 4. Apply headings, formatting, and meta details as needed within WordPress before publishing. This method requires no plugin and works regardless of your hosting PHP version. When to Contact Support If you are unsure which PHP version your host requires, or if you encounter errors when attempting to install the plugin, please reach out to our team. When escalating, have the following ready: - Your current PHP version (found in your hosting control panel) - The exact error message displayed when attempting to install the plugin - Your WordPress version - Your hosting provider's name 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.

Fix WordPress Sync, CSS & GSC Issues

What This Article Covers This guide addresses three common questions related to WordPress integration, CSS styling during sync, and Google Search Console connection stability. Each of these issues may require backend investigation, so the steps below explain what is happening and what information to have ready when contacting support. WordPress Sync — Un-Syncing a Page If you need to disconnect a specific page from WordPress sync so that future edits in Search Atlas no longer push to your live site, this typically requires backend investigation. WordPress sync behavior can vary depending on plugin version and site configuration, so our team will need to review your specific setup. What to have ready when escalating: - The project name and the specific page or article URL you want to un-sync. - A description of what you expected versus what happened. - The approximate time you noticed the sync issue. Once a page is un-synced, the content already published on WordPress remains in place unless you manually delete it there. If sync is re-enabled later, Search Atlas may treat the page as a new deployment and overwrite the live WordPress version. Always review your content before re-syncing. OTTO CSS — Why H1 Styling May Change After Sync When Search Atlas deploys content to WordPress, it sends structured HTML including headings, paragraphs, and links. In some cases the H1 and other heading elements may appear differently on your live site after a sync. Search Atlas syncs heading text, body content, and links; it does not directly control your theme's CSS. The visual presentation depends on how your WordPress theme applies its own styling rules to those elements. What you can check: - Open the live WordPress page and inspect the H1 element using your browser's developer tools to see which CSS classes are applied. - Compare the CSS classes on the synced heading to what your theme normally assigns (for example, entry-title or post-title). - If the expected class is missing, you may be able to add it manually in the WordPress editor after sync, or ask your developer to add a CSS rule in your theme's stylesheet that targets the heading output. If the issue persists or you suspect a duplicate H1 tag is being generated, escalate with a screenshot of the affected page, the article title in Search Atlas, and the live WordPress URL so the team can investigate. Google Search Console — Reconnection Issues If your Google Search Console connection has dropped or is showing a disconnection error, this may require backend attention to restore the integration. What to have ready when escalating: - Your Search Atlas project name. - The Google Search Console property URL. - The exact error message or status shown in the platform. - The approximate time the disconnection occurred. 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.

🔧 Troubleshooting Meta Keywords Blocking CMS Sync

This article explains what to do if the CMS sync toggle appears stuck or unresponsive in relation to your meta keywords settings. 🔍 What Is Happening In some cases, settings related to meta keywords can prevent the CMS sync toggle from turning on. Because no self-serve resolution steps have been documented for this specific issue yet, our support team will need to investigate your account directly to identify and resolve the underlying cause. 🛠️ How to Get This Resolved To help our team resolve this as quickly as possible, please have the following information ready before reaching out: - The exact name of the content item where the CMS sync toggle is not responding. - The meta keywords you have entered (or attempted to enter) in that content item. - A description of what happens when you try to enable the toggle — for example, whether it stays off, flips back, or shows any message. - Any error messages you see, including the exact wording and where they appear. - The approximate date and time when you first noticed the issue. Having these details ready will allow our team to investigate your specific configuration and provide a targeted fix. 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.

🛠️ Fix OTTO Pixel Installation and Custom CMS Setup

🔍 Overview Two common setup questions arise when connecting OTTO SEO to a site that uses a custom or unsupported CMS: why the integration dropdown shows limited options, and why OTTO displays Engaged but not Installed after the Pixel script has been added. This article explains both issues and walks you through the steps to resolve them. 🌐 Why Only Certain CMS Options Appear in the Integration Setup Search Atlas currently offers native one-click integrations for a curated list of supported platforms. If your site runs on a custom or proprietary CMS — for example, an in-house-built solution — it may not appear in the integration dropdown. This is expected behaviour and does not prevent OTTO from working on your site. For custom CMS platforms, you bypass the dropdown entirely and install the OTTO Pixel manually by adding the script directly to your site's code. Follow the steps in the section below to do this correctly. ⚙️ How to Manually Install the OTTO Pixel on a Custom CMS 1. In Search Atlas, navigate to the OTTO SEO section. 2. Open your OTTO project and go to the settings or setup area for your site. 3. Copy the OTTO Pixel script snippet provided in the dashboard. 4. Paste the snippet into your site's base HTML template so it loads on every page of your site. 5. Publish or deploy the change through your CMS or deployment pipeline. 6. Return to Search Atlas and allow a few minutes for OTTO to detect the Pixel. Important: The Pixel must load on all pages, not just the homepage. ❓ Why OTTO Shows "Engaged" but Not "Installed" These two statuses mean different things: - Engaged means OTTO has been activated for your project inside Search Atlas and is ready to work. - Installed means the OTTO Pixel script has been detected live on your website. If your status shows Engaged but not Installed, it means Search Atlas cannot yet detect the Pixel on your site. Common reasons include: - The script was added to only one page (e.g., the homepage) instead of the global template. - The deployment or publish step was not completed after adding the script. - A caching layer or CDN is serving an older version of the page without the script. - The script snippet was modified or truncated when pasting. ✅ How to Verify the Pixel Is Installed Correctly 1. Open any published page of your site in a browser. 2. View the page source and search for the OTTO Pixel script to confirm it is present. 3. Check that the script appears on multiple pages, not only the homepage. 4. If you recently deployed, clear your cache or wait for your CDN to propagate the update, then recheck the status in Search Atlas. If the status still does not update to Installed after confirming the above, please reach out to our support team with your project name and a description of your CMS setup so we can investigate further. 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. Additional Notes Verify the script is live: Open your website in a browser, right-click anywhere on the page, and select View Page Source. Search for your Pixel script tag to confirm it is present in the rendered HTML.

Atlas Agent 'Page Does Not Exist' Error Fix

What This Article Covers After working in Atlas Agent, some users find that returning to a previous session — or browsing all sessions — triggers a 'page does not exist' error, even after refreshing the browser or clearing the cache. This article explains why this happens and what steps to take. What Causes This Error This error is associated with a known platform-side bug that affects how Atlas Agent loads existing chat sessions and the Browse All sessions view. When this occurs, previously created sessions cannot be retrieved correctly, resulting in a broken page instead of your saved work. Because this is a backend issue, standard browser-level fixes alone may not fully resolve it — the Search Atlas support team will need to investigate and restore access to the affected session on your behalf. Steps to Take If You See This Error 1. Note the session name or the report you were working on. This detail is the most important piece of information you can provide, as it allows the support team to locate the affected session quickly and restore your access. 2. Do not attempt to recreate the session from scratch before contacting support, as the original session data may still be recoverable on the backend. 3. Contact the Search Atlas support team and share the session name and any relevant details (e.g., when the error first appeared, what you were doing at the time). The support team will investigate the backend state of your session and restore access where possible. What to Expect Because this is a known bug requiring backend investigation, the support team will review your specific session and work to restore access. Resolution timelines depend on the complexity of the session state, but the team will keep you updated throughout the process. Tips to Avoid Issues in the Future - Keep your browser updated to the latest stable version for the best compatibility with the platform. - If Atlas Agent behaves unexpectedly after a long working session, save or export your work before closing the tab. Still Seeing the Error? If you are still encountering the 'page does not exist' error, please reach out to our support team with your session name and details so we can investigate and restore your access. You can contact us through the Search Atlas Help Center or by starting a new conversation with the support team.

🔌 Fix GSC and GA Connection Issues in Search Atlas

🧭 Overview If your Google Search Console (GSC) or Google Analytics (GA) accounts are not appearing in the Search Atlas connection wizard, the most common cause is an expired or incomplete authentication session. This article explains what typically causes this problem and what to have ready when contacting our team for assistance. ⚠️ Why Accounts May Not Appear in the Connection Wizard When GSC or GA accounts are missing from the connection wizard, it is almost always caused by one of the following: - Your Google authentication session has expired or was revoked. - The Google account connected to Search Atlas does not have access to the properties you are trying to add. - A previous connection attempt was interrupted, leaving the integration in an incomplete state. - You have recently added new properties to your Google account but Search Atlas has not refreshed the token to reflect those changes. The primary fix for all of these scenarios is reauthentication — disconnecting the existing Google account link and reconnecting it fresh. 🔄 Before Reaching Out: Things to Check First Before contacting support, please verify the following, as these checks will help our team resolve your issue faster: - Confirm that the Google account you are using to connect is listed as an Owner or Full User on the GSC and GA properties you want to add. Restricted users may not be visible in third-party integrations. - Make sure you are signing in with the correct Google account — the one that actually has access to the missing properties. - Try disconnecting and reconnecting your Google account from within Site Metrics → Site Explorer → Open Google Search Console (Manage Sites / Connect GSC Account, page: 'Your connected GSC Accounts'), granting all requested permissions during the OAuth flow. If you skip any permission, some properties may still not appear. - If you have recently added new properties to Google Search Console or Analytics, allow a short period for Google to propagate the changes before reconnecting. 📂 Consolidating Duplicate Projects If you ended up with duplicate projects because you attempted multiple connection setups, our support team can help you consolidate your data into a single core project. To make this process as smooth as possible, have the following ready when you reach out: - The exact name or URL of the project you want to keep as your primary project. - The names of any duplicate projects you would like to merge or remove. - A note on which project currently has your GSC and/or GA data connected. 🛠️ What to Have Ready When Escalating If the issue persists after the checks above, our support team will need the following information to investigate: - Your Search Atlas project name and the domain you are trying to connect. - The Google account type you are using for authentication. - A description of what you see in the connection wizard and at what step the issue occurs. - Any error messages displayed during the OAuth flow. 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.

🔄 Fix WordPress CMS Sync Not Implementing Changes

🔍 Overview When WordPress CMS sync is enabled, changes you make in Search Atlas — such as meta titles, descriptions, and content updates — should automatically apply to your connected WordPress site. If those changes are not going live, the steps below outline what our support team recommends checking. ✅ Before You Begin Confirm the following before troubleshooting: - You have administrator access to your WordPress site. - The Search Atlas WordPress plugin is installed and active. - You are logged in to Search Atlas with an account that has sufficient permissions. 🛠️ Step 1 — Verify the Plugin Is Active Confirm that the Search Atlas WordPress plugin is installed and enabled on your site. 1. Log in to your WordPress admin dashboard. 2. Go to Plugins → Installed Plugins. 3. Locate the Search Atlas plugin and confirm it shows as Active. 4. If it is deactivated, click Activate. 🔑 Step 2 — Check Your API Key Connection Confirm that the API key entered in the Search Atlas plugin settings in WordPress matches the key in your Search Atlas account. An incorrect or outdated key can prevent changes from syncing. 1. Retrieve your API key from your Search Atlas account settings. 2. In your WordPress admin, open the Search Atlas plugin settings. 3. Re-enter or confirm the API key and save your changes. 4. Attempt a sync again to see if the issue is resolved. 🚨 If the Issue Persists If you have worked through the steps above and WordPress CMS sync is still not applying your changes, please reach out to our support team. To help us investigate, please have the following ready: your WordPress site URL, the name of the Search Atlas account, a description of the specific changes not being applied, and any error messages you have observed. 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.

⏳ OTTO Pixel Shows Not Installed After Squarespace Setup

🔍 Why You're Seeing This Message After installing the OTTO pixel in your Squarespace header and clicking Verify, you may still see a not installed correctly status. This does not necessarily mean your installation failed — there is often a delay before the platform reflects the updated verification state. ✅ What to Check in Squarespace Before contacting support, confirm the following in your Squarespace account: - Go to your Squarespace dashboard and open Settings → Advanced → Code Injection. - Confirm the OTTO pixel script is pasted in the Header field, not the Footer field. - Make sure the script tag is complete and unmodified — no missing brackets, extra spaces, or line breaks. - Save your changes and publish your site if it is in draft or preview mode. If all of the above looks correct, your pixel script is in place. Allow some time for the platform to process the verification before assuming there is a technical issue. 🛠️ If the Status Does Not Update If you have confirmed the pixel script is correctly placed in the Squarespace Header via Code Injection and the status still shows not installed correctly after waiting, escalate to the support team. When you reach out, have the following ready: - Your project or site name in Search Atlas - The exact status message you are seeing - Confirmation that the pixel script is saved in the Header field in Squarespace Code Injection - A screenshot of your Code Injection header field if possible 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.

🛑 Stop Emails from Deleted Client Accounts

🔍 Overview Some customers receive citation movement emails for domains they have already removed from their account. For example, you may get a notification about a site like crystalclearfl.com even though that client no longer appears in your dashboard. This article explains why this happens and what steps you can take right now. ⚙️ Why This Happens When a client project is deleted or deactivated, the platform's email notification system does not always register the change immediately. Specifically, the system that sends citation movement emails and report-ready emails was not checking whether a project was still active before dispatching notifications. This means emails can continue to be sent for projects that are no longer part of your account. Our engineering team has identified this issue and is working on a backend fix to prevent deactivated and deleted projects from triggering automatic email alerts. If you are still receiving these emails, the steps below will help you manage the situation in the meantime. 🛠️ What You Can Do Right Now 1. Confirm the project is fully removed. Navigate to your project list in the platform and verify that the client domain no longer appears. If it does, open the project settings and delete it. 2. Check for duplicate or shared access. If another team member or sub-account still has the project active, emails may continue to flow. Coordinate with your team to ensure the project is removed across all accounts. 3. Mark emails as handled. Until the fix fully propagates across all accounts, you can safely ignore or filter these emails — they do not indicate any active billing, data collection, or reporting on your account. 4. Monitor your inbox over the next 1–2 billing cycles. After a project is confirmed deleted, citation emails for that domain should stop within a short period as the system sync completes. 📊 What Our Team Is Fixing Our engineering team has identified the root cause of this issue and is actively working to resolve it. The fix involves ensuring the platform checks whether a project is still active before sending citation movement and report-ready emails, so that deleted or deactivated projects no longer generate automatic email alerts. 💡 Tips to Prevent This When offboarding a client, fully delete the project from your account rather than simply deactivating it, and confirm with any team members who share access that they have done the same. This reduces the likelihood of stale notifications continuing after removal. 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.

🔍 Cloud Stacks API: Why cs_list Shows 0 Providers When cs_get Shows Active Stacks

🤔 What is happening When using the Search Atlas MCP or API, cs_list returns all cloud stacks for the currently selected OTTO project. If you have cloud stacks in Project A but your dashboard is set to Project B, cs_list returns Project B's stacks — which may show 0 deployed providers. Meanwhile, cs_get fetches a specific stack by ID regardless of the active project — so it correctly shows your active providers. ✅ This is not a bug The discrepancy between cs_list and cs_get is a project selection mismatch, not a data error. Your stacks and providers are intact. 🛠️ How to fix it 1. In your Search Atlas dashboard, check which OTTO project is currently active in the project selector 2. Switch to the correct OTTO project that contains your cloud stacks 3. Re-run cs_list — it should now return the correct stacks 🔌 If you are using the MCP or API When calling cs_list via the MCP server or REST API, pass the project_id parameter explicitly if available, or verify your session is authenticated to the correct project context. 🚨 If switching projects doesn't fix it If you have confirmed the correct OTTO project is active and a provider still shows as not deployed, the deployment itself may have failed rather than the data being missing. Cloud Stack provider calls do not currently retry automatically, so a single network interruption during deployment can cause that provider to fail permanently (Linear AB-547, status: Canceled — an automatic retry with exponential backoff was proposed but not implemented). In that case, re-deploy the affected provider. Separately, if the Cloud Stack AI agent suggested fewer providers than you expected, this was a known issue where the agent's prompt wording anchored on a fixed count (~14–15) instead of the live provider list (Linear AIAGENT-2101, status: Done — now resolved). Cloud Stacking supports 40+ publishing destinations, including REST API providers such as Netlify, Neocities, Firebase, and Tiiny Host.

Fix WordPress Plugin Connection and Missing Meta Data

🔍 Overview If your WordPress plugin appears connected in Search Atlas but keeps reverting to Disconnected, or your blog pages are missing meta titles and descriptions, you are likely experiencing a known sync issue between the Search Atlas platform and the WordPress plugin. This article explains what causes the problem and what to do next. ⚠️ Why This Happens There are two related issues that can occur together or independently: - False "Connected" status: Search Atlas may display your WordPress connector as Connected even when the plugin has been deactivated, uninstalled, or is failing. The platform does not always re-validate the live plugin state in real time. - Missing meta data: Because the connection status is not accurate, meta titles and descriptions that should be synced from your WordPress pages may not appear in Search Atlas — even though everything looks fine on the surface. 🛠️ What to Expect This is a known bug that may require investigation and action from our support team. The connection reverting and missing meta data issues are related and typically need to be resolved on the backend. Our team will need to look into the specific state of your WordPress connector to identify the root cause and apply a fix. 📋 What to Have Ready When You Contact Support Please reach out and have the following information ready so we can investigate quickly: - Your project name in Search Atlas - The WordPress site URL associated with the connector - The exact status message shown in your connector settings (e.g. "Connected", "Disconnected", or any error text) - A description of which pages are missing meta titles or descriptions - Approximately when the issue started or when you first noticed the status reverting 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.

🔌 Fix WordPress Plugin Connection Timeout Issues

🔍 Overview When adding a new project and connecting your WordPress site to Search Atlas, the plugin may time out during installation or fail to authenticate. This article explains what causes the issue and how to resolve it by regenerating your API key and reauthenticating the plugin. ⚠️ What Causes This Issue This timeout or authentication failure typically occurs when the API key used by the WordPress plugin becomes invalid or revoked. This can happen after account changes, reconnection attempts, or a platform update. Once the key is no longer valid, the plugin cannot complete the handshake with Search Atlas, causing it to stall or time out. 🛠️ How to Resolve It 1. Regenerate your API key. Log in to your Search Atlas account and navigate to your account or API settings. Locate your existing API key and regenerate it to create a new, active key. Copy the new key carefully. 2. Reconnect the plugin in WordPress. Log in to your WordPress admin dashboard. Navigate to the Search Atlas plugin settings. Remove or disconnect the existing API key, then enter the newly generated key and save. This reauthenticates the plugin with your Search Atlas account. 3. Test the connection. Once the new key is saved, attempt to complete the project setup in Search Atlas. The plugin should now connect without timing out. 4. Confirm everything is working. Verify that your WordPress project appears correctly in Search Atlas and that the plugin is active and communicating as expected. 💡 Tips to Avoid This in the Future - If you ever revoke or regenerate your API key for any reason, always update it in the WordPress plugin immediately to prevent authentication failures. - Avoid clicking the connect or authenticate button multiple times during setup — repeated attempts can create conflicting key records and worsen the timeout issue. - If the connection fails after a fresh key entry, wait a few minutes before retrying, as key propagation can occasionally take a moment. 🚨 If You Still See a 500 Error In some cases, the authentication popup may return a 500 error even after regenerating the API key. This is a known issue currently being investigated by the engineering team. If regenerating the key does not resolve the problem for you, please do not attempt multiple additional regenerations, as this can make the issue harder to diagnose. 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.

🔌 Fix Google Search Console Not Showing in Search Atlas

🔍 Overview If your Google Search Console (GSC) account appears connected but data is not showing inside Search Atlas, the most common cause is an expired or misconfigured integration at the account level. In most cases, you can fix this yourself by disconnecting and reconnecting GSC. This article explains how, and what information to have ready if you still need to contact support. ✅ Step 1: Verify Your GSC Integration Status Before reaching out, check whether your GSC connection is active inside your Search Atlas account settings. Look for an area that manages third-party integrations and confirm whether Google Search Console shows as connected or disconnected. If the connection appears active but data is still missing, note the current status displayed so you can share it with support. 🔄 Step 2: Try Re-Authenticating Your Google Search Console Account If your connection has expired or shows an error, attempt to disconnect and reconnect your Google Search Console integration from within your account settings. During reconnection, use the Google account that has appropriate access to the GSC property you want to use, as accounts with insufficient permissions may appear to connect without error but will not return data. 🛠️ Still Not Working? After reconnecting, data can take some time to repopulate because it syncs in the background. If reconnecting fails, the property is missing or not verified in GSC, or data is still missing after reconnecting and the next sync, our support team can investigate the issue on your account directly. When reaching out, please have the following ready: - Your Search Atlas account email address - The GSC property URL you are trying to connect - The Google account email used to authenticate GSC - A description of the current integration status shown in your account settings - Any error messages you have seen during the connection process 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.

🔧 Fix OTTO Pixel UUID Mismatch on Lovable

🧭 Overview If you have followed the OTTO pixel installation guide, entered your UUID, and cleared your cache but the pixel still does not appear active, a duplicate or conflicting UUID in your Lovable project files may be the cause. This article explains what to check and what information to have ready if you need to escalate to our support team. 🔍 What Causes a UUID Mismatch? A UUID mismatch typically occurs when the OTTO pixel script has been inserted into your Lovable project more than once — for example, in multiple template or layout files — and the UUID values in those entries do not all match. Only one correctly formatted, consistent UUID should be present across all instances of the pixel script in your project. 🛠️ What You Can Try 1. Confirm the exact UUID you should be using by locating it in your OTTO setup within Search Atlas. Make sure you copy it precisely — UUIDs are case-sensitive and contain no spaces. 2. Review the files in your Lovable project where the OTTO pixel script has been inserted. Check that every instance of the script uses the same UUID and that the script does not appear more than once in the same file or across overlapping layout files. 3. Remove any duplicate or mismatched script entries so only one correct instance of the pixel script remains. 4. Save your changes and reload your site to allow the pixel to re-register. If after reviewing your project files you are unsure which entry is incorrect, or if the pixel still does not activate after removing duplicates, our support team can investigate the specific UUID and project configuration on your behalf. 📋 What to Have Ready When Escalating To help our team resolve this as quickly as possible, please have the following information ready before reaching out: - Your project name in Lovable and the URL of the affected site - The UUID you believe is correct, copied directly from your OTTO setup in Search Atlas - A brief description of where the pixel script was inserted in your project (e.g., which files or components) - Any error messages or symptoms you are seeing (e.g., pixel not detected, activation status unchanged) 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.

📡 Fix Signal Genesys Publishing Integration Errors

📋 Overview When distributing a press release through Search Atlas to outlets like USA Today, the platform uses a third-party service called Signal Genesys to handle distribution. If the connection between Search Atlas and Signal Genesys becomes out of sync, you may see errors such as: - "Signal Genesys: The selected client ID is invalid" - "API Token is invalid" - A press release that appears to fail but is actually published This article explains what causes these errors, what to do when you see them, and how our team resolves them. ⚠️ Why This Error Happens The Signal Genesys integration relies on an API token and client ID that link your Search Atlas account to the distribution network. These credentials can become invalid for several reasons: - The API token has expired or been rotated on the Signal Genesys side - The client ID associated with your account has changed - A temporary sync issue between Search Atlas and Signal Genesys has occurred This is an integration-level issue and cannot be resolved by changing settings inside your Search Atlas account. It requires our technical team to re-sync the connection on the backend. 🔍 What to Check Before Contacting Support Before reaching out, take a moment to confirm the following: 1. Check if your press release was actually published. In some cases, the error message appears even though the press release was successfully distributed. Check the status of the submission in question within your press releases section to see if it shows as published. 2. Check your distribution quota. Failed press releases do not consume your quota. If you see a failed status, your quota should remain intact and you can safely attempt to republish once the integration is fixed. 3. Note the exact error message. Copy the full error text so our team can identify the specific cause quickly. 🛠️ How to Resolve the Error Because this issue requires a backend fix, the resolution steps are straightforward: 1. Do not repeatedly attempt to republish while the error is active. Multiple failed attempts can create duplicate submissions once the integration is restored. 2. Contact our support team using the chat widget described at the bottom of this article. Provide the press release title, the outlet you were publishing to, and the exact error message you received. 3. Our team will re-sync the Signal Genesys integration on your account. This typically involves refreshing the API token and verifying the client ID. 4. Once the fix is confirmed, return to your press releases section and republish the affected press release. Your quota will not have been affected by the failed attempt. 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.

🔧 Pixel Troubleshooting After CMS Migration

Overview Migrating your store to a new platform is one of the most common reasons the Otto site pixel stops firing. The migration process can change your site's structure and data layer in ways that silently break an otherwise correctly installed pixel. This article explains what to expect and how to get support if your pixel stops working after a CMS migration involving Google Tag Manager (GTM). Why Migration May Break Your Pixel When you migrate to a new platform, several types of changes can disrupt pixel tracking: - GTM container not republished: Your GTM container may still reference old trigger conditions that no longer apply on the new platform. - Data layer differences: Different platforms structure their data layers differently, so variables used by your pixel tags may no longer be available or may have different names. - GTM snippet missing from new theme: The new platform's theme may not include the GTM snippet, so no tags fire at all. - URL structure changes: Page-specific triggers may now point to different URL paths on the new platform. - Cookie and consent settings reset: A new domain or subdomain can affect previously stored consent, blocking the pixel from firing. What to Do If Your Pixel Stops Firing After Migration Because the specific steps to reconfigure your pixel depend on your platform and GTM setup, we recommend contacting our support team directly so they can review your container configuration and guide you through the correct fix for your setup. To help us resolve your issue as quickly as possible, please have the following ready when you reach out: - Your GTM container ID (formatted as GTM-XXXXXXX) - The platform you migrated from and the platform you migrated to - A description of what the pixel was tracking before the migration - Any error messages or unexpected behavior you have observed - The approximate date the migration took place 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.

🛠️ Fix WordPress Hero Image Sync and Duplication Issues

🔍 Overview When you publish a blog post from Search Atlas directly to WordPress, you may notice two things: a second hero image appearing in the published post that you never added, and the blog URL not appearing immediately in your Search Atlas dashboard. These are known issues related to the WordPress integration. This article explains what to expect and how to get help resolving them. 🖼️ Duplicate Hero Image After Publishing Some users experience a duplicate hero image appearing in their published WordPress post after sending content from Search Atlas. This is a known bug in the WordPress integration. The content itself is not corrupted, but the extra image may affect the appearance of your post. Because the root cause involves the integration between Search Atlas and your WordPress environment, the fix requires investigation by our support team. To help us resolve this quickly, please have the following ready when you reach out: - The exact URL of the affected WordPress post. - The name of the article or project in Search Atlas. - A screenshot showing the duplicate image as it appears on the published post. - The date and approximate time you published the post from Search Atlas. ⏱️ Blog URL Not Appearing in Search Atlas After Publishing After publishing, some users find that the live blog URL does not appear in their Search Atlas dashboard right away. This is a known sync issue tied to the WordPress integration. In many cases it resolves on its own, but if the URL remains missing, our team will need to investigate. When contacting support about this issue, please have the following ready: - The name of the article or project in Search Atlas. - The WordPress site URL where the post was published. - The date and approximate time you published the post. - Confirmation of whether the post is live and publicly accessible on your WordPress site. 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.

GoHighLevel Integration: Image Duplication and Alphanumeric Naming

🖼️ Why Does the Featured Image Appear Twice? When you publish an article from Search Atlas to GoHighLevel, you may notice the featured image appears twice in the published blog post. This is a known behavior related to how GoHighLevel processes content received from external integrations. If you experience this, you can resolve it by editing the post directly inside GoHighLevel after publishing and removing the duplicate image from the article body. The featured image will continue to display correctly once the duplicate is deleted. ✅ How to Remove the Duplicate Image To fix the duplicate image, log in to your GoHighLevel account, navigate to your blog posts, open the affected article for editing, locate and delete the extra image from the body of the post, and then save or republish the article. 🔤 Why Is There an Alphanumeric Suffix in the Blog Name? When an article is published to GoHighLevel, the blog post slug or name may include a short alphanumeric suffix — for example, my-article-title-a1b2c3. This suffix is added by GoHighLevel and is not controlled by Search Atlas. If you need to clean up the slug, you can do so by editing the post inside GoHighLevel after publishing. Look for the slug or URL field within the post's editing options, update it to your preferred value, and save your changes. Tip: Before editing the slug, check that no other post in your GoHighLevel blog already uses the same URL, as a conflict may cause a suffix to be re-added. Archive or delete any duplicate posts first if needed. ⚙️ Can Search Atlas Prevent These Issues Automatically? These behaviors occur on the GoHighLevel side after content is published. If you continue to experience issues with image duplication or alphanumeric suffixes that cannot be resolved through post editing in GoHighLevel, please reach out to our support team with your project name and a description of the issue so we can investigate further. 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.

🔧 Fix Recurring 403 Error on WordPress Plugin Sitemap

🛠️ Root Cause The 403 error occurred because the plugin previously generated static sitemap files on disk. On certain server configurations (especially nginx), file permissions or rewrite rules prevented public access to these files after updates, triggering a 403 Forbidden response. 🚀 Permanent Solution The engineering team has released a fix that switches sitemap generation to virtual-only mode with regenerate-on-miss. This eliminates static file writes entirely — sitemaps are now served dynamically via WordPress rewrite rules, bypassing file permission issues. 1. Log in to your WordPress admin dashboard. 2. Navigate to the Plugins page and locate the Search Atlas plugin. 3. If an update is available, click Update Now to install version 2.6.11 or later. 4. After updating, visit your sitemap URL (typically /sitemap.xml) to confirm it loads without a 403 error. No additional configuration is required — the virtual-only mode activates automatically upon update. ✅ Verification Once updated, the sitemap should return a valid XML response with HTTP 200. You can also verify in Google Search Console that the sitemap is fetched successfully. 📋 Related Improvements This fix also resolves related issues where sitemaps returned 404 on the frontend despite showing as generated in admin, and prevents plugin activation from causing 404s on all pages except the home page. 💬 Need Help? 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.

Atlas Brain Looping and WordPress Plugin 505 Error

Overview Some users have experienced two related issues: Atlas Brain AI campaigns entering a loop and applying incorrect fixes instead of resolving the flagged problem, and the Search Atlas WordPress plugin returning a 505 error when attempting to authenticate or sync. This article explains what these issues mean and what you can do when you encounter them. What These Issues Look Like - Atlas Brain looping: The AI campaign fixer runs continuously and applies the wrong fix rather than correctly resolving the issue identified in your campaign. - WordPress plugin 505 error: When linking the Search Atlas plugin to your WordPress site, the connection fails with a 505 server error, preventing authentication and data sync. What to Do Both of these issues — Atlas Brain looping in an AI campaign and the WordPress plugin returning a 505 sync error — require investigation on the Search Atlas side to identify and apply the correct fix for your account. There are no self-service steps that reliably resolve either issue without support involvement. If you are experiencing either or both of these issues, please contact our support team right away so we can look into the root cause and resolve it for you. You can reach us by clicking the chat icon in your Search Atlas dashboard. Please include the following information when you reach out: - A description of which issue you are experiencing (Atlas Brain looping, plugin 505 error, or both). - The name of the affected campaign or the WordPress site URL. - Any error messages or screenshots you are able to capture.

Fix the WordPress Plugin Wrong UUID Error

🧩 What Is the Wrong UUID Error? The Wrong UUID error appears when the Search Atlas OTTO SEO WordPress plugin cannot match the unique identifier (UUID) stored in your plugin settings with the one linked to your Search Atlas account. This mismatch prevents the plugin from communicating with the platform and must be corrected before OTTO SEO features will work. What to Do If You See This Error Because the exact steps to resolve a Wrong UUID error depend on your specific plugin version, account configuration, and WordPress environment, there is no single universal self-serve fix confirmed for all cases. If you encounter this error, the most reliable path is to contact our support team directly so an agent can look up the correct UUID associated with your account and guide you through re-entering it in the right location within your setup. Before reaching out, please have the following information ready so the agent can resolve your issue as quickly as possible: - Your Search Atlas account email address - The URL of the WordPress site where the plugin is installed - The version of the Search Atlas OTTO SEO plugin you have installed (visible in your WordPress Plugins list) - A screenshot or exact text of the error message you are seeing - Any recent changes you made to the plugin settings or your Search Atlas account before the error appeared Having these details ready will allow the support team to identify the correct UUID for your account and walk you through exactly where to enter it in your environment. 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.

🔧 Fix WordPress Plugin Dashboard & GSC Indexation Issues

Overview If buttons inside the Search Atlas WordPress plugin dashboard are unresponsive, or if your Google Search Console (GSC) instant indexation connection is failing to configure, our support team can investigate and resolve this for you directly. What to Expect Non-functional plugin dashboard buttons and GSC instant indexation connection failures are known issue types that require investigation by our support team. Because the root cause can vary depending on your specific WordPress environment and account configuration, our team will need to look into your setup directly to identify and apply the correct fix. How to Get Help To help our team resolve this as quickly as possible, please have the following ready when you reach out: - Your WordPress site URL - The exact buttons or features that are not responding (e.g. which dashboard section or action) - A description of the GSC issue, if applicable — including whether you have already verified your site in Google Search Console - Any error messages you are seeing, copied exactly as they appear - The timestamp of when the issue started or was first noticed - Your Search Atlas account email or project name 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.

🛠️ Fix Shopify CMS Connector 400 OAuth Error

🔍 Overview Search Atlas connects to Shopify in two distinct ways. CoWorker uses a Shopify connection for SEO automation tasks, while the CMS Connector is a separate integration that allows Search Atlas to publish and manage content directly inside your Shopify store. These two connections serve different purposes and each requires its own dedicated setup. If you encounter a 400 OAuth token exchange error during CMS Connector setup, this article explains what is happening and how to get it resolved. ⚙️ Why You Need a Separate CMS Connector Even if your Shopify store is already connected through CoWorker, you must complete a separate CMS Connector setup. The two integrations are independent of one another and both can run simultaneously without conflict. 🚨 What Is a 400 OAuth Token Exchange Error A 400 error during the OAuth token exchange means that Shopify was unable to complete the authorisation process during CMS Connector setup. This is a known issue that our team needs to investigate on a case-by-case basis. 🛠️ How to Escalate This Issue Because this error requires backend investigation, please do not attempt workarounds that are not confirmed by our support team. Instead, contact us and have the following information ready so we can resolve it as quickly as possible: - Your project name in Search Atlas - The exact error message you are seeing (a screenshot is helpful) - The Shopify store URL you are trying to connect - The steps you took before the error appeared - The date and approximate time when the error occurred 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.

🛠️ Search Atlas Troubleshooting Hub

Search Atlas is a powerful platform built on interconnected systems: SEO data, AI workflows, automation engines, integrations, and real-time insights. When everything is working together, results compound quickly. But when something breaks—or simply doesn’t behave as expected—it can interrupt your workflow, delay outcomes, and create confusion. This troubleshooting hub is designed to eliminate that friction.

🔧 Fix UK Google Search Console Connection Issues

🧭 Overview Some customers with UK-based Google Search Console (GSC) properties experience a frustrating issue: the property appears to connect successfully, but after saving, the status reverts to Disconnected. This is a known issue our team is actively investigating. 🔎 Why This Happens This issue has been identified with UK-based GSC properties that revert to a disconnected status after an apparently successful connection attempt. The exact cause is under investigation by our engineering team. ⚠️ What to Have Ready When Escalating Because this issue requires backend investigation, please have the following information available when you contact support: - The name of the affected Search Atlas project. - The exact UK GSC property URL as it appears in Google Search Console. - The timestamp (date and approximate time) when the disconnection was last observed. - Any error messages displayed on screen during or after the connection attempt. - The Google account email used to authorise the GSC connection. 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.

🛠️ Fix Rank Math and Google Search Console Conflicts

🔍 What Is Happening? After installing the Search Atlas WordPress plugin, some customers notice the following issues: - Rank Math throws errors or conflicts with Search Atlas. - Google Search Console connections appear disconnected or stop reporting data. These issues are caused by a known conflict between the Search Atlas plugin and Rank Math SEO. ⚠️ Why This Happens When both Search Atlas and Rank Math are active on the same WordPress site, a conflict can occur that may disrupt Rank Math's functionality and interfere with Google Search Console connections. ✅ What to Do This is a known bug that requires backend investigation. If you are experiencing this conflict, please have the following information ready when contacting support: - Your WordPress site URL - The exact error message or behavior you are seeing in Rank Math - Whether your Google Search Console connections are affected - A timestamp of when the issue began 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.

🏷️ GHL API Keys Page Branding Fix

A branding inconsistency in the API Keys page has been resolved for GoHighLevel (GHL) users. The SearchAtlas name was incorrectly appearing in description text on that page, and it has now been corrected to reflect the proper white-label branding. ✨ What's New The API Keys page description text in GHL environments was displaying SearchAtlas branding instead of the expected white-label branding. This fix ensures that the platform identity remains consistent and fully white-labeled throughout the GHL experience, including the API Keys section. 📋 What to Expect GHL users will no longer see any SearchAtlas branding references within the API Keys page description text. All other areas of the platform that rely on white-label branding are unaffected by this change. No action is required on your part — the update is applied automatically. 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.

🔄 Restoring Your ChatGPT MCP OAuth Connection

💡 What This Article Covers If you previously connected the Search Atlas MCP server to ChatGPT and the connection has stopped working — for example, ChatGPT no longer pulls your Search Atlas data, or the connector shows as disconnected — this guide explains why it happens and walks you through restoring it. 🔍 Why the Connection Drops The Search Atlas MCP integration uses OAuth 2.1 to link your ChatGPT account with your Search Atlas workspace. The connection can drop for a few common reasons: - Expired access token: OAuth tokens have a limited lifetime. Normally they refresh automatically, but occasionally the stored token becomes stale and ChatGPT stops recognizing the connection. - Revoked permissions: If access was revoked from your Search Atlas account or from your ChatGPT connector settings, the link breaks. - Workspace changes: Switching plans, changing account roles, or re-authenticating your Search Atlas login can invalidate the existing token. - ChatGPT connector cache: ChatGPT sometimes keeps a cached (stale) credential even after a token expires, which blocks reconnecting until the connector is fully removed and re-added. 🛠️ How to Reconnect in a Few Steps In most cases, fully removing and re-adding the connector fixes the problem: 1. Open ChatGPT and go to Settings → Connectors (sometimes labeled Apps). 2. Find Search Atlas in your list of connected connectors. 3. Open the options menu next to it and choose Remove or Disconnect. This clears the stale cached token. 4. Wait about a minute, then re-add the connector: search for Search Atlas in the connector directory, or re-enter the Search Atlas MCP server URL if you originally added it manually. 5. Complete the OAuth sign-in: you will be redirected to log in with your Search Atlas credentials and asked to authorize the connection. 6. Return to ChatGPT and confirm the connector shows as Connected. Important: Simply clicking Reconnect without first removing the connector often fails, because ChatGPT reuses the stale token. Always fully remove the connector first, then re-add it. ✅ Verifying the Connection Works After reconnecting, test it with a simple request such as: - "List the Search Atlas tools you can access." - "Pull my connected site's OTTO SEO overview." If ChatGPT responds with live data from your workspace, the connection is restored. ⚠️ Known Issue With a Fix in Progress We are aware of an issue where OAuth discovery endpoints return a 403 error on stale bearer tokens, which can prevent ChatGPT from reconnecting even after a fresh sign-in. A fix is being prepared for release. Until then, the full remove-and-re-add process above is the reliable workaround. If the 403 error appears immediately after re-adding the connector, wait 10–15 minutes and try once more. 🚧 If It Still Won't Connect Work through this quick checklist: - Confirm you are logging into the same Search Atlas account you originally connected. - Check that your Search Atlas subscription is active and that your role allows integrations. - Sign out of ChatGPT, clear your browser cache, sign back in, and retry. - Try the OAuth flow in a different browser or an incognito window to rule out cached cookies. - If ChatGPT reports a timeout right after authorization, wait a few minutes for the token to settle, then test again. 💬 Still Need Help? 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.

🔑 Fix Search Atlas MCP ChatGPT Authentication Errors

🧭 Overview The Search Atlas MCP (Model Context Protocol) server lets you connect Search Atlas tools directly to AI assistants like ChatGPT. However, setting it up for the first time — or after an API key change — can produce authentication errors or a 'no actions available' message. This article walks you through the correct setup process and the most common fixes. ⚙️ How the Search Atlas MCP Works with ChatGPT Search Atlas uses OAuth 2.1 to authenticate your ChatGPT connection. When you link the MCP server, ChatGPT receives a signed JWT (JSON Web Token) that grants it access to your Search Atlas tools — including GSC data, keyword research, and LLM Visibility features. Important things to know before you begin: - The Search Atlas MCP server is a standard remote MCP server that works with any MCP client, ChatGPT included. Whether a given ChatGPT app or plan lets you add a custom MCP connector is decided on ChatGPT's side. - Your Search Atlas account must be on a plan that includes MCP/AI Agent access. - JWT tokens are tied to your current API key. If you rotate your API key or disconnect a site, you must re-authenticate — existing tokens are not automatically invalidated but will stop working correctly. 🚀 How to Install the Search Atlas MCP in ChatGPT 1. In your ChatGPT-connected environment (e.g., ChatGPT desktop app or a GPT Action setup), open the plugin or action configuration panel. 2. Select Add an action or Connect an MCP server, then paste in the Search Atlas MCP Server URL. 3. When prompted for authentication, choose OAuth login (an active subscription is required), or alternatively authenticate with a Search Atlas API key from Settings → API Keys passed via the X-API-Key header. 4. If using OAuth, ChatGPT will redirect you to a Search Atlas login screen — sign in with your account credentials to complete the OAuth handshake. 5. Once authorised, return to ChatGPT. Your Search Atlas tools should now appear as available actions. 🛠️ Fixing 'No Actions Available' Errors If you see a 'no actions available' message after connecting, work through these steps in order: 1. Confirm your ChatGPT app and plan support custom MCP connectors. Custom MCP connector availability depends on the customer's ChatGPT app and plan (ChatGPT's side). 2. Re-check your authentication. Confirm you completed OAuth login with an active subscription, or that the Search Atlas API key from Settings → API Keys you provided in the X-API-Key header is valid. 3. Complete the OAuth flow fully. The connection only activates after you sign in on the Search Atlas authorisation page. If you closed that window early, disconnect and reconnect the integration to restart the flow. 4. Check your plan permissions. MCP access is not available on all plans. Verify that your subscription includes AI Agent or MCP features under Avatar (top-right) → Billing (Plans & Top-ups). 5. Rotate your token after an API key change. If you recently rotated your Search Atlas API key or disconnected a site, your previous JWT may be stale. Disconnect the MCP integration in ChatGPT, then reconnect it using fresh credentials from Search Atlas. 6. Wait up to two minutes. After a successful OAuth handshake, ChatGPT may take a short moment to load available actions. Refresh or restart the session before concluding there is a problem. 🔐 Understanding Token Behaviour Search Atlas issues signed JWT tokens during the OAuth flow. Keep these points in mind to avoid future authentication issues: - Tokens are valid for a set period. If your session expires, you will need to re-authorise the connection. - Rotating your Search Atlas API key does not automatically revoke existing JWTs. However, those tokens will lose access to protected data. Always reconnect after a key rotation. - Disconnecting a site from Search Atlas does not instantly invalidate tokens linked to that site. Reconnect the MCP integration after any major account change to ensure your tokens are fresh and correctly scoped. ❓ Frequently Asked Questions - Can I use the Search Atlas MCP in the ChatGPT web app? The Search Atlas MCP server works with any MCP client, ChatGPT included. Whether you can add a custom MCP connector depends on your ChatGPT app and plan (ChatGPT's side). - How many tools does the MCP give me access to? When correctly authenticated, the MCP unlocks tools across GSC data, keyword research, and LLM Visibility — over 70 actions in total. - Do I need to reconnect if I change my Search Atlas password? Changing your password alone does not affect your MCP token, but if you reset your API key you should reconnect the integration. 💬 Still Need Help? 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.

🔌 Restore Your ChatGPT MCP Connection

🔍 What This Article Covers If you previously connected Search Atlas to ChatGPT through MCP and the connection has stopped working — for example, ChatGPT no longer pulls your data or keeps asking you to sign in — this guide explains why it happens and how to restore the connection in a few minutes. ⚠️ Why the Connection Drops Search Atlas MCP uses OAuth 2.1 to authorize ChatGPT, and access tokens expire on a schedule for security. A dropped connection is usually temporary and easy to fix. Common causes include: - Expired token: The authorization token between ChatGPT and Search Atlas timed out and was not refreshed automatically. - Stale bearer token: A known issue can cause a 403 error on our discovery endpoints when an old token is cached. A permanent fix is rolling out now; until it reaches your account, reconnecting manually is the reliable workaround. - Disconnected app: The Search Atlas connector was removed in ChatGPT settings, either by you or by a workspace admin. - Account changes: A password reset, plan change, or workspace switch on the Search Atlas side can invalidate an existing session. 🛠️ How to Reconnect Step by Step The fastest fix is to fully remove the old connection and authorize it again. Follow these steps: 1. Open ChatGPT and go to Settings. 2. Open the Apps and Connectors section (name may vary slightly by ChatGPT version). 3. Find Search Atlas MCP in your list of connected apps and select Remove or Disconnect. This clears the stale token. 4. Re-add the connector using the same Search Atlas MCP listing or server URL you used originally. 5. Complete the sign-in screen with your Search Atlas account email and password — use the same account you use inside the Search Atlas platform. 6. Approve the permission prompts to finish authorizing the connection. 7. Return to your ChatGPT conversation and test the connection using the steps below. If ChatGPT shows a 403 error during the reconnect attempt, sign out of Search Atlas in your browser, sign back in, and repeat the steps above. This forces a fresh token to be issued. ✅ Confirm the Connection Works After reconnecting, verify everything is active: - In ChatGPT settings, the Search Atlas connector shows a Connected status. - Ask ChatGPT a simple question that requires your Search Atlas data, such as pulling details for one of your OTTO SEO sites or running a visibility check. - If the tool responds with live data from your account, the connection is restored. 💡 Tips to Avoid Future Disconnects - Reconnect promptly whenever ChatGPT shows a sign-in or authorization prompt — delaying can leave a stale token in place. - Use the same Search Atlas account in both the platform and ChatGPT to avoid session conflicts. - Keep an active Search Atlas subscription; a lapsed plan can interrupt the authorization. - After any password reset or workspace change, remove and re-add the connector to refresh the token. 🚀 Known Issue and Upcoming Fix Our engineering team is releasing a fix for the bug that causes 403 errors on stale bearer tokens during MCP reconnection. Once deployed, ChatGPT will refresh expired tokens automatically and manual reconnects should no longer be needed. Until the fix reaches your account, the remove-and-reconnect steps above will restore access every time. 🙋 Still Need Help? 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.

🔄 Fix WordPress Articles Not Syncing Automatically

🧭 Overview When Search Atlas generates an article, it does not automatically publish it to your WordPress website. Syncing is a separate step you must trigger — either one article at a time or in bulk. This article explains why articles stay in a generated state, how to push them to your site, and what to check if the sync fails. ❓ Why Doesn't the Article Appear on My Website? Search Atlas separates the content creation process from publishing. A status of Generated means the article exists inside the platform but has not yet been sent to your connected WordPress site. This design gives you control over what gets published and when. To make the article live, you need to sync it manually or enable the bulk sync feature. 🖱️ How to Manually Sync a Single Article 1. In the left sidebar, click Content to expand the section. 2. Navigate to the tool where your article was created (for example, Content Planner or AI Content Templates). 3. Locate the generated article in your list. 4. Click the Synchronization option for that article. 5. Select the website page you want to associate with the article. 6. Change the article status to Posted. 7. Confirm the action. The article will be pushed to your connected WordPress site. After a few moments, visit your WordPress dashboard to confirm the post has appeared. It may be saved as a draft or published depending on your sync settings. ⚡ How to Use Bulk Sync for Automatic Synchronization If you manage a large volume of content and want articles to sync without repeating the manual steps each time, the Bulk Sync feature is available. 1. Go to Content → Content Genius in the left sidebar. 2. Select multiple articles using the checkboxes next to each item (these appear for Restore Deleted Articles). 3. Look for the Restore Articles bulk action in the toolbar that appears. 4. Choose your target website and preferred publish status. 5. Confirm the bulk sync. All selected articles will be queued and pushed to WordPress. Bulk sync is especially useful when you have generated a batch of articles through Content Planner and want to push them to your site in one action rather than syncing individually. 🔍 Common Causes of Sync Failures If an article fails to sync or does not appear on WordPress after you trigger the sync, check the following: - WordPress connection is disconnected: Your site may have become unlinked from Search Atlas. Reconnect it by verifying your WordPress integration settings inside the platform. - Incorrect website selected: During the sync step, confirm you selected the correct website from the dropdown. If you manage multiple sites, it is easy to push to the wrong one. - Plugin not installed or deactivated: The Search Atlas WordPress plugin must be installed and active on your site. Log in to your WordPress admin panel and check that the plugin is enabled. - User permissions: The WordPress account connected to Search Atlas must have Administrator role to connect the plugin. - Article status not set to Posted: If you skipped the step of changing the status to Posted, the article remains in a pending state and will not be pushed. - Network or timeout error: Occasionally a sync request may time out. Wait a few minutes and try the sync again. ✅ Quick Checklist Before Contacting Support - WordPress plugin is installed and active on your site. - Your WordPress site is connected in the platform integration settings. - You clicked Synchronization and selected the correct website page. - You changed the article status to Posted and confirmed. - The WordPress user role is Administrator. - You have checked your WordPress dashboard under both Published and Drafts. 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.

🔌 Fix WordPress Plugin 'Not Installed' Status & Connect GSC

🧭 Overview This article covers two common setup issues in Search Atlas: your WordPress plugin showing Not Installed on the dashboard even though it is active and authenticated, and how to connect a domain's Google Search Console (GSC) account to a project. Both issues are straightforward to resolve once you know where to look. 🔍 Why the Plugin Shows 'Not Installed' The Search Atlas dashboard determines plugin status by checking for a specific tracking script on your website — not just whether the plugin is activated in WordPress. If that script is missing or blocked, the dashboard will display Not Installed even if the plugin is authenticated and synced correctly. Common reasons the script may not be detected include: - The Search Atlas script has been removed or overwritten by a theme or plugin update - A security plugin (e.g., Wordfence, iThemes) is blocking external scripts from loading - A caching layer is serving an older version of your page without the script - The plugin was deactivated and reactivated without a proper resync ✅ Step 1 — Verify the Script Is Present on Your Site Before clearing any caches, confirm whether the Search Atlas script is actually present in your page source. This tells you immediately whether the issue is a script problem or a cache problem. 1. Open a browser and navigate to your website's homepage. 2. Right-click anywhere on the page and select View Page Source. 3. Press Ctrl+F (or Cmd+F on Mac) and search for searchatlas or search-atlas. 4. If the script appears in the source, the issue is likely a caching problem — proceed to Step 2. 5. If the script does not appear, the issue is that the script is not being output by the plugin — proceed to Step 3. 🗂️ Step 2 — Clear Caches (If Script Is Present) If the script is visible in your page source but the dashboard still shows Not Installed, a cached response is preventing the dashboard from reading the live version of your page. 1. Log in to your WordPress admin panel. 2. Navigate to your caching plugin (e.g., WP Rocket, W3 Total Cache, LiteSpeed Cache) and clear all caches. 3. If you use a CDN such as Cloudflare, purge the CDN cache for your domain as well. 4. Return to your Search Atlas dashboard and wait up to five minutes, then refresh the plugin status page. 🔧 Step 3 — Reinstall or Resync the Plugin (If Script Is Missing) If the script is not present in your page source, the plugin is not outputting it correctly. Follow these steps to restore normal operation. 1. Log in to your WordPress admin panel. 2. Go to Plugins → Installed Plugins and deactivate the Search Atlas plugin. 3. Reactivate the plugin immediately. 4. In WordPress, go to Search Atlas → Settings and verify the Search Atlas API Key and Plugin Auth Token fields are populated correctly. 5. Repeat the page source check from Step 1 to confirm the script now appears. 6. If a security plugin is installed, temporarily disable it and recheck. If the script appears after disabling it, add the Search Atlas script domain to your security plugin's allowlist before re-enabling it. 📊 How to Connect Google Search Console to Your Project Connecting GSC gives Search Atlas access to your real impressions, clicks, and keyword ranking data for a domain. Follow these steps to link a property. 1. Log in to Search Atlas and open the project for the domain you want to connect (for example, beesmartbeeremoval.com). 2. Go to Site Metrics → Site Explorer and click Open Google Search Console. 3. On the Manage Sites page, click Connect GSC Account. 4. You will be redirected to a Google authentication screen. Sign in with the Google account that has access to the GSC property for your domain. 5. Grant Search Atlas the requested read permissions when prompted. 6. After authentication, a dropdown will display all GSC properties available to that Google account. Select the property that matches your domain exactly (e.g., https://beesmartbeeremoval.com/ or the sc-domain: version if you verified as a domain property). 7. Click Save or Confirm. GSC data will begin populating within 24–48 hours depending on the volume of historical data. Important: You must be signed in to a Google account that is listed as a verified owner or full user on the GSC property. If you do not see your domain in the dropdown, ask the GSC property owner to add your Google account as a user in Google Search Console → Settings → Users and permissions. ⚠️ Quick Troubleshooting Reference - Dashboard still shows Not Installed after rescanning: Allow five minutes after any change before rechecking, as the dashboard scan is not instant. - Script present but status still wrong after cache clear: Contact support using the instructions below for a manual status refresh. - GSC property not appearing in the dropdown: Confirm the correct Google account is connected and that it has at least Full User access in GSC. - GSC data shows zero after connecting: Wait 24–48 hours. If data is still absent, disconnect and reconnect the integration. 💬 Need More Help? 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.

🔌 Fix Duplicate Plugin Warnings in Search Atlas

🧐 Why Duplicate Warnings Appear Search Atlas detects a duplicate when your WordPress site sends two separate tracking signals at the same time. This happens when both installation methods are active simultaneously: - The Search Atlas WordPress plugin — installed and active in your WordPress dashboard - The manual tracking script — added directly to your theme files, a header/footer plugin, or Google Tag Manager Because each method independently reports data to Search Atlas, the platform flags the account as a duplicate to prevent inflated metrics and reporting errors. Simply clearing cache or running a scan will not remove the warning unless the underlying duplicate installation is fully resolved first. 🗑️ Step 1 — Remove One Installation Method You only need one active installation method. Choose the option that best fits your workflow and fully remove the other. Option A: Keep the WordPress plugin, remove the manual script 1. Log in to your WordPress dashboard. 2. Navigate to Appearance → Theme File Editor (or open your child theme's header.php file). 3. Locate the Search Atlas tracking script — it typically begins with a comment such as <!-- Search Atlas --> or contains your unique site token. 4. Delete the entire script block and save the file. 5. If you added the script via a header/footer plugin (e.g., Insert Headers and Footers, WPCode), go to that plugin's settings and delete the Search Atlas script entry. 6. If you used Google Tag Manager, open your GTM workspace, find the Search Atlas tag, and either pause or delete it, then publish the updated container. Option B: Keep the manual script, remove the WordPress plugin 1. Log in to your WordPress dashboard. 2. Go to Plugins → Installed Plugins. 3. Locate the Search Atlas plugin. 4. Click Deactivate, then click Delete and confirm. 5. Verify no plugin files remain under wp-content/plugins/search-atlas/ via FTP or your hosting file manager if needed. 🗄️ Step 2 — Clear Your Cache After removing one installation method, clear all cache layers so the change is reflected immediately. Follow the steps for your environment: - WP Rocket: Go to Settings → WP Rocket and click Clear Cache. - W3 Total Cache: Go to Performance → Dashboard and click Empty All Caches. - LiteSpeed Cache: Go to LiteSpeed Cache → Dashboard and click Purge All. - WP Super Cache: Go to Settings → WP Super Cache → Delete Cache. - Cloudflare: Log in to Cloudflare, select your domain, go to Caching → Configuration, and click Purge Everything. - SiteGround (SG Optimizer): Go to SG Optimizer → Supercacher and click Flush Cache. - WP Engine: In your WP Engine portal, click Flush All Caches from the site's overview page. - Kinsta: In the Kinsta dashboard, select your site, go to Tools, and click Clear Cache. If you are unsure which caching layer is active, clear caches at the plugin level, the hosting level, and the CDN level to be thorough. ✅ Step 3 — Verify the Duplicate Warning Is Resolved Clearing cache alone does not confirm the fix. Complete these verification steps to ensure the duplicate warning is fully removed: 1. Log in to Search Atlas and open the affected client account. 2. Check whether the Duplicate label is no longer displayed next to the account name. Allow up to 10–15 minutes for the platform to re-evaluate the installation after cache is cleared. 3. Go to your WordPress site's front end and open your browser's developer tools (F12 → Network tab or Sources tab). Reload the page and search for Search Atlas in the loaded scripts. Confirm only one instance of the tracking script or plugin output is present. 4. Return to Search Atlas, navigate to the affected account's settings, and run a fresh site scan if the option is available. Confirm the scan completes without a duplicate flag. 5. If you manage multiple client accounts, repeat steps 1–4 for each account showing the duplicate label, as each WordPress site requires its own fix. ⚠️ Common Mistakes to Avoid - Deactivating the plugin without deleting it — an inactive plugin can still register with the platform in some configurations. Always delete it if you are switching to the manual script method. - Clearing only one cache layer when multiple are active — caches stack, so an old cached page can still serve duplicate scripts. - Assuming the warning clears instantly — the platform may take up to 15 minutes to update after the duplicate is resolved. 💬 Still Seeing the Duplicate Warning? If you have followed all the steps above and the duplicate label persists after 15 minutes, there may be a secondary script injection point (such as a page builder, third-party plugin, or server-side include) that is not yet resolved. 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.

🔧 Fix GHL Connector Errors and Insert Blog Links

Overview This article covers two common issues you may encounter in Search Atlas: a 400 error when connecting a GoHighLevel (GHL) connector, and how to insert internal or external links into your blog posts. Follow the sections below for guidance on each issue. Part 1: GHL Connector — 'Request Failed with Status Code 400' A 400 error when adding a GHL connector means the platform rejected the request before a connection could be established. This is most commonly caused by expired, revoked, or incorrectly entered GHL credentials. How to Fix the GHL 400 Error Try the following steps to resolve the issue: 1. Go to your GoHighLevel account settings and verify that your API key or access token is still active and has not been revoked. 2. In Search Atlas, navigate to Settings > CMS Connectors (via the top-right Avatar Menu (👤)) and remove the existing GHL connector. 3. Re-add the GHL connector by entering your credentials fresh — do not reuse a previously copied key without confirming it is current. 4. If your GHL account uses location-level API keys, make sure you are using the key for the correct sub-account or location. 5. Save and test the connection again. If the 400 error persists after re-entering valid credentials, the issue may require investigation on the backend. When escalating, please have the following ready: - Your Search Atlas account email - The exact error message (a screenshot is helpful) - The timestamp when the error first occurred - The GHL credentials or API key details you have already tried Part 2: Inserting Links into Blog Posts You can insert internal or external links into your blog posts directly within the Search Atlas content editor. Follow these steps: 1. Open the blog post you want to edit in the Search Atlas content editor. 2. Highlight the anchor text — the word or phrase you want to turn into a link. 3. With the text highlighted, click the link icon in the editor toolbar (it looks like a chain or paperclip icon). 4. In the link dialog that appears, paste the URL you want to link to — this can be an internal page on your site or any external URL. 5. Confirm or save the link. The highlighted text will now be clickable. To remove a link, highlight the linked text and click the link icon again, then select the option to remove or unlink. 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.

🛠️ Fix Divi Theme CSS Conflicts With Search Atlas Plugin

🔍 Overview Some customers using the Search Atlas WordPress plugin alongside the Divi theme have reported visual conflicts, including unexpected changes to text styles, header and footer rendering, and carousel behaviour. This article explains why these conflicts occur and what to prepare when reaching out to our team for help. ⚙️ Why This Conflict Happens The Search Atlas plugin injects CSS to support its on-page SEO features. Divi also outputs a large volume of its own inline styles and scripts. In some configurations, these stylesheets can interfere with each other, causing: - Font sizes or text styles changing unexpectedly across pages - Header and footer elements rendering incorrectly - Divi carousels or sliders behaving erratically or breaking entirely - Layout shifts on pages that use Divi's Visual Builder This is a CSS specificity and load-order conflict — it occurs because both tools compete to apply styles to the same HTML elements. 🛠️ Before Escalating: Steps to Try 1. Update both the Search Atlas plugin and Divi to their latest versions. Compatibility improvements are released regularly. Always start here before making any other changes. 2. Deactivate the Search Atlas plugin temporarily. Go to WordPress Admin → Plugins, deactivate the Search Atlas plugin, and reload the affected page. If the design issue disappears, the conflict is confirmed. Note this result — it will help our team diagnose the issue faster. 3. Clear all caches after any change you make. Cached stylesheets are a common reason a fix appears to have no effect. Clear any server-side or CDN cache you have in place before testing. 📋 How to Escalate to Our Team Because this is a confirmed bug category, our team will need to investigate your specific environment. To help us resolve this as quickly as possible, please have the following ready before you contact us: - Your WordPress version and the exact version numbers of both the Search Atlas plugin and the Divi theme - The URL(s) of the affected page(s) where the conflict is visible - A description of the visual issue — e.g. which elements are broken (fonts, carousel, header/footer) and when it started - Screenshots or a screen recording showing the conflict - Result of the deactivation test — whether disabling the Search Atlas plugin resolved the visual issue - A list of any other active plugins that interact with your site's front-end CSS or caching 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.

🔌 Troubleshooting Yoast SEO Fields Missing After Search Atlas Plugin Install

This article explains why Yoast SEO fields may disappear or become inaccessible after installing the Search Atlas WordPress plugin, and walks you through the steps to restore full Yoast functionality including indexing controls. 🔍 Common Causes When the Search Atlas plugin is activated alongside Yoast SEO, the following issues can cause fields to go missing: - Plugin conflict: Both plugins may attempt to control the same meta fields or SEO output, causing one to suppress the other's interface elements. - OTTO SEO activation: If OTTO SEO features are enabled within Search Atlas, they may take over on-page SEO management, which can hide or override Yoast's meta fields in the post editor. - Script or asset loading conflict: The Search Atlas plugin may interfere with how Yoast loads its editor sidebar components in WordPress. 🛠️ Step-by-Step 1. Check whether OTTO SEO is active for your site. Inside your Search Atlas project, open your site's settings and look for an OTTO SEO section. If OTTO SEO is currently enabled and managing on-page SEO for your WordPress site, it may be intentionally suppressing Yoast fields to avoid conflicts. Decide which tool you want to manage on-page SEO — you should only run one at a time. 2. Disable OTTO SEO on-page control if you prefer Yoast. In your Search Atlas project settings, locate the OTTO SEO configuration area and turn off any option that pushes meta tags, titles, or indexing directives directly to your WordPress site. Save your changes. 3. Deactivate and reactivate the Search Atlas plugin in WordPress. In your WordPress admin panel, go to Plugins → Installed Plugins, deactivate the Search Atlas plugin, then reactivate it. This forces both plugins to reinitialise and can resolve asset loading conflicts. 4. Check Yoast SEO plugin status. Still in Plugins → Installed Plugins, confirm that Yoast SEO is active and up to date. If a pending update is available, apply it before testing further. 5. Open a post or page in the WordPress block editor. Navigate to Posts → All Posts (or Pages), open any existing entry, and check whether the Yoast SEO sidebar panel now appears on the right-hand side or at the bottom of the editor screen. 6. Restore indexing control in Yoast if fields are visible again. Within the Yoast SEO panel on a post or page, click the Advanced tab to access the robots meta settings. Confirm that your preferred indexing directives (index/noindex, follow/nofollow) are set correctly for each page type you need to control. 7. If fields are still missing, test with only Yoast SEO active. Temporarily deactivate the Search Atlas plugin and reload the post editor. If Yoast fields reappear, this confirms a direct plugin conflict. Re-enable Search Atlas and contact support to report the specific pairing so the team can investigate further. ✅ How to Confirm It Worked You will know the issue is resolved when all of the following are true: - The Yoast SEO meta box or sidebar panel is visible when editing a post or page in WordPress — it should display tabs for SEO, Readability, and (if applicable) Schema and Social. - The Advanced tab inside the Yoast SEO panel shows the robots meta dropdown, allowing you to set indexing and follow directives without the field being greyed out or hidden. - Changes you save in Yoast (such as a custom meta title or a noindex instruction) are reflected correctly when you inspect the page source or use a browser SEO extension — confirm the relevant <meta name="robots"> tag appears in the page <head> with your intended value. - No duplicate or conflicting robots meta tags appear in the page source that would indicate both Yoast and OTTO SEO are outputting directives simultaneously. 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.

🔌 Fix External API 403 Scope Errors Fast

🔍 What This Article Covers If every call to the Search Atlas External API — including the token/validate endpoint — returns an HTTP 403 error with the message "Invalid scope provided. Check API Key permissions on your Press Releases account!", your API key is missing the press-release scope. This article explains what causes this error and the exact steps to resolve it. ⚠️ Understanding the 403 Error The 403 error means the API key you are using does not have permission to access the Press Releases (External API) scope. This is not a network issue or a bug in your integration code — it is a permissions configuration issue on your Search Atlas account. Until the correct scope is enabled, every API call, regardless of endpoint, will be rejected with this message. Common situations where this happens: - You recently generated a new API key but did not assign all required scopes. - Your account plan was changed and certain scopes were reset. - A team member created the API key without enabling the press-release permission. - You are using an older hardcoded token that no longer has the correct permissions. 🛠️ How to Fix the Scope Error Follow these steps to check and update your API key permissions inside Search Atlas. 1. Log in to your Search Atlas account. 2. Click your Avatar Menu (👤) or account name in the top-right corner of the platform. 3. Navigate to Account Settings and select the API Keys or Integrations section. 4. Locate the API key you are using for Signal Genesys or your External API integration. 5. Click Edit or Manage Permissions on that key. 6. Ensure the press-release scope (also labeled External API in some views) is toggled on. 7. Save your changes. 8. Re-run your token/validate call to confirm the 403 error is resolved. Important: If you do not see an option to enable the press-release scope, your current account plan may not include External API access. Contact our team using the chat widget to verify your plan includes this feature. 🔑 Best Practices for API Key Setup To avoid scope errors in the future, follow these recommendations whenever you create or rotate API keys: - Always review the full list of scopes before saving a new API key. - Enable only the scopes your integration actually needs — but do not accidentally leave required scopes unchecked. - Avoid hardcoding API tokens directly in your application code. Use environment variables or a secrets manager so tokens can be rotated without a code deployment. - After rotating a key, immediately run a validation call (token/validate) to confirm the new key has the correct permissions before pushing to production. - Document which scopes each integration requires so your team can replicate the setup consistently. 📋 Signal Genesys Integration Checklist If you are connecting Signal Genesys to Search Atlas via the External API, confirm all of the following before testing: - Your API key has the press-release scope enabled. - You are using the correct base URL and OAuth client credentials flow (not a legacy hardcoded token). - Environment variables in Signal Genesys are up to date with the current key and endpoint values. - You have tested the token/validate endpoint independently before making other API calls. 💬 Still Seeing the 403 Error? If you have followed all the steps above and the error persists, it is possible that the press-release scope needs to be enabled on your account at the platform level by our team. 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.

🛠️ Fix MCP WebSocket 403 Permission Errors

🔍 What Is This Error? When using the Search Atlas MCP (Model Context Protocol) server with an AI client like Claude to manage or edit your website, you may encounter an HTTP 403 error with a message such as "You do not have permission to perform this action." This error can appear when running playbooks, accessing SEO tools, or executing any MCP-connected operation. This is an authentication and permissions issue — it means the MCP server cannot verify that your session has the correct access rights to carry out the requested action. ⚠️ Common Triggers - Your MCP API credentials are missing, expired, or were not saved correctly. - The MCP connection was set up under a different workspace or user account than the one currently active. - Your Search Atlas session timed out, invalidating the active WebSocket connection. - A recent platform update reset or changed permission scopes for MCP integrations. - The connector was configured but has not completed its authorisation handshake. 🔧 Step-by-Step Troubleshooting 1. Verify you are in the correct workspace. In the left sidebar, click Coworker. At the top of the page, confirm the workspace name shown matches the project you are working on. If not, use the workspace switcher to select the right one. 2. Refresh your setup status. Go to Coworker → Overview tab and click Refresh setup status. Wait for the status indicators to update. A green status on all items confirms your agent connection is healthy. 3. Check your MCP connector. Navigate to Coworker → Connectors tab and click Manage connectors. Locate your MCP connector. If it shows an error state or a warning icon, click into it and re-authenticate by following the on-screen prompts to re-enter your API key or OAuth credentials. 4. Re-enter your Search Atlas API key in your MCP client. Open your MCP client configuration (for example, Claude's settings or your claude_desktop_config.json file). Confirm the API key entered matches the one found in your Search Atlas account. Copy a fresh key from your account settings if needed, paste it into the config, and save. 5. Restart the MCP server connection. After updating credentials, fully quit and relaunch your AI client (e.g., Claude Desktop) so it establishes a fresh WebSocket session with the updated credentials. Stale sessions will continue to produce 403 errors even after a key update. 6. Re-run the failing playbook or tool. Return to your AI client and retry the action that produced the 403 error. If the credentials and connector are correctly configured, the request should now succeed. 💡 Tips to Prevent This Error - Always complete the full connector setup flow in Coworker → Connectors tab before using MCP tools in your AI client. - If you belong to multiple workspaces, double-check the active workspace before running any agent playbook — permissions are workspace-specific. - Rotate API keys carefully: update them in your MCP client configuration immediately after generating a new key in Search Atlas to avoid session mismatches. - Keep your AI client (Claude Desktop or similar) updated to the latest version to ensure WebSocket compatibility with the MCP server. 🚀 Still Seeing the 403 Error? If you have followed all the steps above and the error persists, it is possible that a permission scope for your account or agent has not been correctly provisioned on the backend. This requires a manual review by our team. 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.

📝 Schedule Blog Post Button Disabled in WordPress Synchronize

📝 Overview If you scheduled a blog post for the wrong website inside Content Genius → Content Planner, and when trying to change it the "Schedule Blog Post" button appears disabled (greyed out), this is not a sync error. This happens when required WordPress publishing fields are incomplete. 🧭 Navigation Path Search Atlas → Left Sidebar → Content → Content Planner → open the scheduled post → WordPress Synchronize. 🐾 Step-by-Step Fix 1. Open the scheduled post: go to Content → Content Planner, locate the scheduled post, and open it. 2. Go to WordPress Synchronize: inside the post editor, click WordPress Synchronize. 3. Change Publish Status to Draft: under Publish Status, select Draft. Resetting the status allows the system to reprocess the scheduling configuration. 4. Complete required fields: scroll down and make sure Author, Categories, and Parent (if applicable) are filled in. If any required field is empty, the Schedule button will remain disabled. 5. Click "Schedule Blog Post": once all required fields are filled, the button becomes active. Click it to re-sync and schedule the post correctly. 6. Refresh the page: after scheduling, refresh the page to confirm the updated publishing status reflects correctly in the interface. 🔴 Why This Happens The Schedule button remains disabled when required WordPress fields are empty, or when the publish status wasn't reset before attempting to re-sync. This is expected system behavior and does not indicate a WordPress connection issue. ❓ FAQs - Is this a WordPress sync error? No, it's a required field validation issue. - Do I need support to fix this? No, completing the required fields and refreshing the page resolves the issue. - Will changing to Draft delete the post? No, it simply allows you to reconfigure the publishing settings. 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.

🔧 Fix Pixel Installation on Wix with GTM

Overview If your Search Atlas pixel is not firing correctly on a Wix website, the cause is typically one of three things: a conflict between two installation methods, an incomplete Google Tag Manager (GTM) setup on Wix, or a publishing step that was missed. This article walks you through each scenario so you can identify and fix the issue. Understand Your Two Installation Options Before troubleshooting, confirm which installation method you are using. Running both at the same time will cause duplicate or broken tracking. - Direct header installation: The pixel code is pasted manually into your Wix site's custom code or header section inside the Wix dashboard. - Google Tag Manager installation: A GTM container snippet is placed in the Wix site's header, and the pixel fires as a tag inside GTM — not directly on the page. You must use only one method. If the pixel snippet exists both in your Wix custom code settings and inside a GTM tag, remove one before continuing. Step 1 — Check for a Duplicate Installation Conflict 1. Log in to your Wix account and open your site dashboard. 2. Locate the section in your Wix dashboard where custom code or tracking scripts can be added (the exact menu name may vary by Wix plan — look for a Custom Code or Marketing section). 3. Check whether a Search Atlas pixel snippet is pasted directly in the head section of your site. 4. Open your GTM container and check whether the same pixel is also configured as a tag there. 5. If you find the pixel in both places, remove it from one location. Save your choice before moving to the next step. Step 2 — Verify Your GTM Container Is Correctly Installed on Wix GTM on Wix requires a specific setup. Unlike WordPress, Wix does not support a plugin-based GTM install, so the container snippet must be added through Wix's custom code tools. 1. In your Wix dashboard, locate the area where you can add custom code or scripts to your site's head and body sections (refer to Wix's own documentation for the current navigation path, as menu names change with platform updates). 2. Confirm the GTM head snippet (<script> block) is placed in the head section and set to load on all pages. 3. Confirm the GTM body snippet (<noscript> block) is placed at the start of the body section, also on all pages. 4. Both snippets are required. A GTM installation with only the head snippet is incomplete and may cause tags including your pixel to fail silently. 5. After confirming both snippets are present, save your changes and republish your Wix site. Changes to custom code do not go live until the site is republished. Step 3 — Verify the Pixel Tag Inside GTM 1. Open your GTM container and check whether the Search Atlas pixel tag exists and is configured correctly. 2. Confirm the tag has a trigger set to fire on all pages (or on the appropriate pages you want to track). 3. Use GTM Preview mode to test that the tag fires as expected before publishing. 4. Once confirmed, submit and publish your GTM container so changes go live. 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.

🔌 WordPress OTTO Plugin Setup and Duplicate Script Fix

🧭 Overview When you activate OTTO through the Search Atlas WordPress plugin, OTTO automatically injects its JavaScript onto your site. If you previously added the OTTO pixel script manually — or if you have an older version of the plugin installed — both scripts can run at the same time. This duplicate causes a persistent OTTO JavaScript has been detected warning inside the OTTO SEO dashboard. This article walks you through the correct setup process and shows you how to eliminate the conflict. ⚙️ Step 1: Install or Confirm the Search Atlas WordPress Plugin 1. Log in to your WordPress admin panel. 2. Go to Plugins → Add New → Upload Plugin and upload the Search Atlas plugin .zip file provided by Search Atlas. 3. Click Install Now, then Activate. 4. If the plugin is already installed, go to Plugins → Installed Plugins and confirm it is active and updated to the latest version. 5. Navigate to the plugin settings and connect it to your Search Atlas account using your API key. Your API key is available under your Search Atlas account settings. 🗑️ Step 2: Remove Any Manually Added OTTO Pixel Scripts If you previously connected OTTO by pasting a JavaScript snippet directly into your site, that manual script must be removed. Leaving it in place will cause the duplicate detection warning. Check these common locations for the old script: - Theme header or footer files: In your WordPress admin, go to Appearance → Theme File Editor and open header.php or footer.php. Look for any script tag referencing Search Atlas or OTTO and delete it. - Functions.php: Open functions.php in the Theme File Editor and remove any wp_enqueue_script or inline script block related to OTTO. - Third-party script manager plugins: If you use a plugin such as Insert Headers and Footers, WPCode, or similar, open that plugin and delete any saved OTTO script snippets. - Google Tag Manager: If you deployed the OTTO pixel through GTM, log in to your GTM workspace, find the OTTO tag, and either pause or delete it. After removing every instance of the manual script, save all changes. ✅ Step 3: Verify OTTO Activation in Search Atlas 1. Log in to Search Atlas and go to OTTO SEO using the left sidebar. 2. Select the website you are working on. 3. Confirm that OTTO is activated and that the WordPress plugin is shown as the connected deployment method. 4. If OTTO is not yet activated, click Activate OTTO and follow the on-screen prompts. The plugin will handle script injection automatically once activated. 🧹 Step 4: Purge All Caches Even after removing the old script, cached versions of your pages may still serve the duplicate code. You must clear every cache layer before the warning will disappear. Clear caches in this order: 1. WordPress caching plugin: Go to your caching plugin (e.g., WP Rocket, W3 Total Cache, LiteSpeed Cache, WP Super Cache) and click Clear All Cache or the equivalent option. 2. Cloudflare or CDN cache: If your site runs behind Cloudflare or another CDN, log in and purge the full cache for your domain. 3. Server-level cache: If your host provides a server cache (such as Nginx FastCGI cache or a hosting panel cache), clear it through your hosting control panel. 4. Browser cache: In your browser, open DevTools (F12), go to the Network tab, check Disable cache, and reload your site. Alternatively, do a hard refresh with Ctrl + Shift + R (Windows) or Cmd + Shift + R (Mac). 🔍 Step 5: Confirm the Warning Is Resolved 1. Return to OTTO SEO in Search Atlas. 2. Refresh the page and check whether the OTTO JavaScript has been detected warning is still displayed. 3. If the warning is gone, your setup is complete and OTTO is running correctly through the plugin. 4. If the warning persists, open your browser's DevTools, go to the Sources or Network tab, and search for duplicate OTTO or Search Atlas script references loading on your site. Identify which file or plugin is still serving the old script and repeat Step 2 for that source. ⚠️ Common Mistakes to Avoid - Keeping both connection methods active at the same time. Use either the WordPress plugin or the manual pixel — never both. - Forgetting to clear the CDN cache. A Cloudflare or CDN cache can serve stale pages for hours. Always purge the CDN after making script changes. - Editing theme files without a child theme. Changes to parent theme files are overwritten on theme updates. Use a child theme or a code snippet plugin to ensure your edits persist. - Leaving old GTM tags active. GTM tags are easy to overlook. Double-check your GTM workspace even if you believe you removed the pixel locally. 💬 Need More Help? 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.

🔌 Fix Google Integration Disconnections and OAuth Issues

🔍 Overview Search Atlas integrates with Google Search Console (GSC) and Google Business Profile (GBP) using OAuth — a secure token-based authorization system. When these tokens expire, are revoked, or become invalid, your integrations will disconnect automatically. This article explains the most common causes and the steps you can take to restore a stable connection. ⚠️ Why Integrations Keep Disconnecting There are several reasons your Google integrations may disconnect repeatedly: - Revoked OAuth tokens: If access permissions are revoked in your Google Account settings, Search Atlas loses authorization immediately. This is the most common cause of repeated disconnections. - Expired tokens: Google OAuth tokens have a limited lifespan. If Search Atlas cannot automatically refresh a token (for example, due to a permission change), the connection will drop. - Password or security changes: Changing your Google account password or enabling two-factor authentication can invalidate existing tokens. - Multiple Google accounts: Connecting Search Atlas with more than one Google account, or switching between accounts during setup, can cause token conflicts and unstable connections. - Third-party access revoked at the Google level: Google periodically prompts users to review connected apps. If Search Atlas access was removed during one of these reviews, you will need to reconnect. ✅ How to Check Your Google Account Permissions Before reconnecting inside Search Atlas, verify that access has not been revoked at the Google level: 1. Go to myaccount.google.com and sign in with the Google account linked to Search Atlas. 2. Navigate to Security in the left-hand menu. 3. Under Third-party apps with account access, click Manage third-party access. 4. Look for Search Atlas in the list. If it is missing or shows a revoked status, you will need to re-authorize it when you reconnect. 5. If Search Atlas is listed, remove it and reconnect fresh to clear any corrupted token state. 🔄 How to Reconnect Google Search Console 1. Log in to your Search Atlas account. 2. Navigate to Site Metrics → Site Explorer and click Open Google Search Console to reach the Manage Sites page. 3. Locate the Google Search Console integration and click Disconnect if it shows a connected or error state. 4. Click Connect GSC Account and follow the OAuth prompts. 5. Make sure you select the correct Google account and grant all requested permissions — partial permission grants are a common cause of token issues. 6. Confirm the integration status shows Connected before closing the settings page. 🗂️ How to Reconnect Google Business Profile 1. Log in to your Search Atlas account. 2. Navigate to Settings and select Integrations. 3. Locate the Google Business Profile integration and click Disconnect. 4. Navigate to Local → GBP Projects, click Connect GBP Account, and complete the OAuth authorization flow. 5. Ensure you grant access to all business locations you manage — if a location's access is missing, features like review sync and auto-responder will not function for that location. 6. Verify the integration status shows Connected and check that your locations appear correctly. 💡 Best Practices to Prevent Future Disconnections - Use a dedicated Google account for Search Atlas integrations where possible, rather than a personal account that may be subject to frequent security changes. - Do not revoke third-party access to Search Atlas inside your Google account settings unless you intend to fully disconnect. - Avoid switching Google accounts mid-session when setting up integrations. - Grant all requested permissions during the OAuth flow — skipping optional permissions can cause partial connections that break silently. - Monitor the Integrations page periodically to catch disconnections early before they impact your data or automated features like review auto-responders. 🛠️ What Happens When a Token Is Revoked When Search Atlas detects a revoked or invalid token (invalid_grant error), the integration is automatically flagged as disconnected and you will see a notification prompting you to reconnect. Features that depend on the affected integration — such as GSC keyword data, GBP review sync, and review auto-responses — will pause until the connection is restored. Reconnecting following the steps above will resume these features without data loss for the period the connection was active. 🆘 Still Disconnecting After Reconnecting? If your integrations continue to disconnect after following all the steps above, there may be an account-level permission issue or a conflict that requires investigation. 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.

🛠️ Install Linkgraph When Information Is Missing

🔍 Overview Installing Linkgraph on your website requires a few key pieces of information. If you are missing some of those details, the installation process may stall or produce errors. This article walks you through what information is needed, where to find it, and how to complete the installation successfully. 📋 What You Need Before You Start Before beginning the Linkgraph installation, make sure you have the following ready: - Your website URL — the full domain where Linkgraph will be installed (e.g., https://www.yoursite.com). - Access to your website's backend — either through a CMS (such as WordPress), a hosting control panel, or direct file access via FTP/SFTP. - Your Search Atlas account credentials — you must be logged in to retrieve your unique Linkgraph tracking snippet. - Your Linkgraph tracking snippet — found inside the Search Atlas platform (see steps below). 🗺️ How to Find Your Linkgraph Tracking Snippet If you are unsure where to locate your tracking snippet, follow these steps inside Search Atlas: 1. Log in to your Search Atlas account. 2. In the left sidebar, click Website Studio (URL: /website-studio). 3. Select the website you want to connect, or add a new one by clicking Import Site. 4. Navigate to the Settings or Installation tab for that website. 5. Copy the Linkgraph tracking snippet shown on screen. Keep this code ready for the next steps. ⚙️ How to Install the Linkgraph Snippet on Your Website Once you have your tracking snippet, add it to your website using the method that matches your setup: - WordPress: Go to your WordPress dashboard, navigate to Appearance → Theme Editor, and paste the snippet just before the closing </head> tag in your theme's header.php file. Alternatively, use a plugin such as Insert Headers and Footers to paste the code without editing theme files directly. - Other CMS platforms (Wix, Squarespace, Shopify, etc.): Go to your platform's site settings, find the Custom Code or Header Code section, and paste the snippet there. - Custom or static HTML websites: Open your main HTML file (usually index.html), and paste the snippet just before the closing </head> tag. Upload the updated file to your server. 🚨 Common Reasons Information May Be Missing If you are stuck because key details are unavailable, here are the most common causes and how to resolve them: - No website added in Search Atlas yet: You must first add your website inside Website Studio (What will we get done today?) before a tracking snippet is generated. Click Import Site, enter your domain, and save. - No access to website backend: Contact your web developer or hosting provider to get FTP/SFTP credentials or CMS admin access. Linkgraph cannot be installed without backend access. - Snippet not visible in the platform: Ensure your Search Atlas plan includes Linkgraph. If the installation tab is not visible, your current plan may not support this feature. - Multiple websites and wrong site selected: Double-check that you have selected the correct website inside Website Studio before copying the snippet, as each site has a unique code. ✅ Verifying the Installation After adding the snippet to your website, confirm the installation was successful: 1. Return to Website Studio in Search Atlas. 2. Open the settings for the relevant website. 3. Look for a Connection Status or Verification indicator. A green status or a confirmation message means Linkgraph is installed correctly. 4. If the status still shows as unverified, clear your browser cache, wait a few minutes, and refresh the page. It can take up to 24 hours for verification to complete after a fresh install. 💡 Tips for a Smooth Installation - Always paste the snippet in the <head> section of your site, not the footer, to ensure it loads correctly. - Do not modify the snippet code — copy and paste it exactly as shown in Search Atlas. - If your site uses a tag manager (e.g., Google Tag Manager), you can paste the snippet there as a custom HTML tag firing on all pages. 🙋 Need More Help? If you have followed the steps above and are still unable to complete the Linkgraph installation — for example, if your snippet is not appearing, your website status is not updating, or you are missing account information you cannot locate — our team is ready to assist. 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. Additional Notes Linkgraph is separate from the OTTO SEO tool and its pixel. Also adds guidance for when you lack website backend access: contact your web developer or hosting provider and share the copied script, asking them to paste it inside the tag of every page or site-wide via header injection.

🔌 Fix ChatGPT MCP Tool Discovery

🔍 What this error means If ChatGPT shows “Authentication succeeded, action discovery failed” for https://mcp.searchatlas.com/mcp/, your sign-in was accepted, but ChatGPT could not retrieve the available Search Atlas tools. This usually indicates a connection, session, permission, or temporary service issue rather than an incorrect password. ⚙️ Check your Search Atlas access 1. Sign in to the Search Atlas account you want ChatGPT to use. 2. Confirm that the account can access the Search Atlas areas you need, such as Site Metrics or Local. 3. For Site Metrics, open Left sidebar → Site Metrics and verify that your projects and sites load. 4. For Local, open Left sidebar → Local and verify that your projects load. 5. If you belong to a team, confirm that your role includes access to the required projects and features. 🔄 Reconnect the MCP server 1. In ChatGPT, open the settings or connected apps area where MCP servers are managed. 2. Remove the existing Search Atlas MCP connection, if one is listed. 3. Add the server again using exactly https://mcp.searchatlas.com/mcp/. 4. Complete the Search Atlas sign-in and permission prompts in the same browser session. 5. Retry the connection and wait for ChatGPT to finish discovering the available actions. 🧹 Resolve browser and session issues - Sign out of Search Atlas, then sign in again before reconnecting. - Allow pop-ups, redirects, and cookies for Search Atlas and ChatGPT. - Try a private browser window or another supported browser. - Disable extensions that block scripts, redirects, or third-party authentication. - Ensure the MCP URL has no extra spaces, characters, or trailing path changes. 🧪 Test the connection After reconnecting, ask ChatGPT to list the available Search Atlas MCP tools. If discovery succeeds, ask it to perform a simple read-only request using an accessible site or project. If tools still do not appear, do not repeatedly authorize the same failed connection; continue with the checks below. 📋 Information to provide for investigation If the error continues, record the exact error message, the MCP URL used, the approximate time of the attempt, your Search Atlas workspace, and whether the issue affects all projects or only one. Screenshots of the ChatGPT connection result and any request or correlation ID can also help investigate the authenticated tool-discovery request. Never share your password or private access tokens. 💬 Get help If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.

🔗 Install Linkgraph on Your Website With Missing Information

🧭 Overview Linkgraph is Search Atlas's website tracking and analytics integration — it is separate from the OTTO SEO tool and its pixel. This article specifically covers how to install Linkgraph on your website when you are missing one or more pieces of required information during the setup process. 📋 What You Need Before You Start To complete a full Linkgraph installation, you typically need the following: - Access to your website's code or CMS backend — this is where the Linkgraph script is placed. - Your Search Atlas account credentials — to retrieve your unique Linkgraph installation code. - Your website's domain — to associate the integration with the correct property. - Admin or editor access to your site — required to add or edit scripts and headers. If you are missing any of the above, do not worry. The sections below explain what to do in each scenario. 🔍 How to Find Your Linkgraph Installation Code If you do not have your Linkgraph code, follow these steps to retrieve it from the platform: 1. Log in to your Search Atlas account. 2. In the left sidebar, click Website Studio. You can also navigate directly to /website-builder. 3. Select the website property you want to connect, or add a new one by entering your domain. 4. Locate the Linkgraph Installation section within the property settings. 5. Copy the unique script snippet shown on screen — this is your Linkgraph installation code. Keep this code ready before proceeding to your website's backend. 🌐 Installing Linkgraph When You Lack Website Backend Access If you do not currently have access to your website's code or CMS, here is what you can do: - Contact your web developer or hosting provider and share the copied Linkgraph script with them. Ask them to paste it inside the <head> tag of every page, or site-wide via a header injection setting. - Use a tag manager such as Google Tag Manager if it is already installed on your site. Add the Linkgraph script as a new Custom HTML tag and set it to fire on all pages. - Check your CMS for a script injection field — platforms like WordPress, Wix, Squarespace, and Webflow all have built-in areas where you can paste third-party scripts without touching code directly. 🔑 Installing Linkgraph When You Don't Have Your Domain Information If you are unsure which domain to use or have not yet confirmed your site's URL, follow these steps: 1. Confirm the exact domain your website uses — include or exclude "www" consistently based on how your site is configured. 2. Return to Website Studio in the left sidebar (or go to /website-builder). 3. Add or select the correct domain under your property list before generating the installation code — the code is domain-specific and must match your live site. 4. If your site uses subdomains (for example, blog.yoursite.com), add each subdomain as a separate property if you want Linkgraph tracking on each one. ⚠️ Common Issues and How to Resolve Them - The installation code is not appearing: Make sure you have selected a website property first. The code is only generated after a domain is saved to your account. - Linkgraph is not verifying after installation: Allow up to 24 hours for the platform to detect the script. Confirm the script is placed inside the <head> section and is not blocked by a cookie consent tool or Content Security Policy setting. - You are seeing OTTO pixel instructions instead: OTTO and Linkgraph are two separate products in Search Atlas. If you need Linkgraph installation help, navigate to Website Studio in the left sidebar. OTTO setup is found in a different section of the platform and uses a different script. - You have multiple websites and are unsure which property to use: In Website Studio, each domain is listed as its own property. Match the domain shown in the list to the website you are currently working on. ✅ Verify Your Linkgraph Installation Once you have placed the script on your website, verify it is working correctly: 1. Go to Website Studio in the left sidebar or navigate to /website-builder. 2. Open the property you just set up. 3. Look for a connection status indicator — a green or active status confirms Linkgraph is receiving data from your site. 4. If the status shows as pending or unverified after 24 hours, double-check that the script is present in the <head> of your live site and is not being stripped by your CMS or a caching plugin. 💬 Need More Help? 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.

📤 Find Your OTTO Work Summary in Google Drive

🔍 Overview When you export a work summary from OTTO, Search Atlas sends the file directly to your connected Google Drive account. If the file does not appear, the most common causes are an incomplete Google account connection, insufficient Drive permissions, or the file landing in an unexpected folder. Follow the steps below to locate your export and fix any underlying issues. ✅ Step 1: Confirm Your Google Account Is Connected OTTO requires an authenticated Google account before it can export files to Google Drive. If your account is not linked, the export may appear to succeed inside Search Atlas but the file will never reach Drive. 1. In Search Atlas, navigate to OTTO SEO in the left sidebar, then open SEO Automation (URL: /seo-automation-v3). 2. Click your Avatar in the top-right corner and select Settings. 3. Open the Integrations tab (Settings tabs: Profile, Email Settings, Team Members, Integrations, CMS Connectors, API Keys). 4. Confirm that a Google account is listed and shows a Connected status. 5. If no account is connected, go to Site Metrics → Site Explorer (GSC page) and click Connect GSC Account or Connect GA Account to complete the OAuth sign-in flow. Once connected, re-export your work summary and check Google Drive again. 🔑 Step 2: Check Google Drive Permissions Even when an account is connected, restricted Drive permissions can block file creation. Google may prompt you to grant additional access. 1. Go to myaccount.google.com/permissions and sign in with the account linked to Search Atlas. 2. Find Search Atlas in the list of third-party apps. 3. Confirm that See, edit, create, and delete files in Google Drive is listed as a granted permission. 4. If this permission is missing or restricted, remove Search Atlas from the list and reconnect your Google account inside Search Atlas to trigger a fresh permission request. 📁 Step 3: Search Google Drive for the File Exported summaries may land in a location other than My Drive. Before assuming the export failed, do a targeted search inside Drive. 1. Open Google Drive and click the search bar at the top. 2. Type OTTO or work summary and press Enter. 3. Change the search scope to Everywhere to include shared drives and folders. 4. Check the Shared with me section in the left sidebar — files sent by a connected app sometimes appear here instead of My Drive. 5. Check the Recent view to see the latest files added to your Drive regardless of folder location. 🔄 Step 4: Re-export the Work Summary If you cannot find the file after searching, trigger a fresh export. 1. Navigate to OTTO SEO in the left sidebar, open SEO Automation, and open your OTTO project. 2. Locate the work summary you need and click the Export to Docs button in OTTO SEO → Site Audit → Overview (Website Overview). 3. Wait for the confirmation message that the export completed successfully. 4. Switch to Google Drive immediately and check Recent for the new file. If you receive an error message during export, take note of the exact wording — this will help the support team diagnose the issue faster. ⚠️ Step 5: Resolve Common Error Scenarios - Session expired / re-authentication required: Disconnect your Google account from Search Atlas and reconnect it. Authentication tokens expire and must be refreshed periodically. - Wrong Google account connected: If you have multiple Google accounts, confirm that the account connected in Search Atlas is the same account you are checking in Google Drive. - Storage quota exceeded: Google Drive has a 15 GB free storage limit. If your Drive is full, new files cannot be created. Free up space or upgrade your Google One storage plan, then retry the export. - Organisational Google Workspace restrictions: Some Workspace admins block third-party app access to Drive. Contact your Google Workspace administrator to confirm that Search Atlas is allowed. 💬 Still Can't Find Your Export? If you have worked through every step above and your work summary still does not appear in Google Drive, our team can investigate the export log for your account directly. 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. To speed up the investigation, please have the following ready: the name of the OTTO project, the approximate date and time of the export attempt, and the Google account email address connected to Search Atlas.

🔧 Fix Google Search Console Connection Dropping in Search Atlas

Understanding the Issue Some Search Atlas users notice that their Google Search Console (GSC) account appears connected inside the platform — but after refreshing the page, the connection status reverts to disconnected. In some cases, the GSC connection modal may also remain visible even after a successful connection attempt. This is a known bug related to Google Search Console connection persistence. Our engineering team is aware of this issue. If you are experiencing this behaviour, please reach out to our support team so we can investigate and apply the appropriate fix on our end. What to Have Ready When You Contact Support To help our team resolve this as quickly as possible, please have the following information ready before reaching out: - Your project or site name as it appears in Search Atlas. - The exact behaviour you are seeing — for example, whether the connection drops immediately on refresh, after a period of time, or only in certain parts of the platform. - Any error messages displayed during or after the GSC connection attempt, copied exactly as they appear. - The timestamp of when you first noticed the disconnection (date and approximate time, including your timezone). - The browser and device you are using. Our team will review your account and apply the correct resolution. You do not need to attempt manual reconnection steps while this investigation is ongoing, as doing so without guidance may not resolve the underlying issue. 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.

🛠️ Fix WordPress Content Deployment Sync Failures via AI Agent

🔍 Overview When deploying content to WordPress sites through the Search Atlas AI Agent, you may receive a "deployed" confirmation but find that no new pages or posts appear in your WordPress admin dashboard. This article explains why this happens and walks you through the steps to verify your deployment and get your content live. ⚠️ Why This Happens Several known issues can cause the AI Agent to report a successful deployment when content has not actually been published to WordPress: - The AI Agent may confirm deployment without verifying whether the content is live on your site. - An incorrect or duplicate WordPress connection link may be used, bypassing your existing CMS connector. - WordPress cache is not purged after deployment, making it appear as though no content was published even when it was. - Metadata fields such as category and author may be silently ignored during publishing, causing the post to fail validation or save in an unexpected state. - HTML heading styles may not be applied correctly, which can affect how content is saved or rendered in certain page builders such as Elementor. ✅ Step-by-Step: Verify and Resolve Your Deployment 1. Check your WordPress admin dashboard directly. Log in to each affected WordPress site and navigate to Posts or Pages. Filter by All statuses, including Draft and Pending, to confirm whether the content exists in any state. 2. Check your CMS connector in Search Atlas. Go to your Avatar Menu (👤) → Settings → CMS Connectors and confirm that the correct WordPress site is connected. If a duplicate or incorrect connection exists, remove it and reconnect using the official connector. 3. Purge your WordPress cache manually. If your site uses a caching plugin (such as WP Rocket, W3 Total Cache, or LiteSpeed Cache), navigate to the plugin settings and clear the cache. Then reload your WordPress admin to check for new content. 4. Re-deploy the content through the AI Agent. After confirming your CMS connector is correct and your cache is cleared, return to the AI Agent and redeploy the affected pages or posts. Watch for any error messages during the process. 5. Verify category and author assignment. After deployment, open each newly created post in WordPress and confirm that the correct author and category have been assigned. If these fields are blank, update them manually or adjust your deployment settings before re-publishing. 6. Review heading styles if using Elementor. If your site uses Elementor, open the deployed content in the Elementor editor and check that headings (H1, H2, H3) are rendering correctly. Re-apply heading styles if needed before publishing through Elementor. 🔗 Reconnect Your WordPress CMS Connector If the steps above do not resolve the issue, your WordPress connection may need to be reset entirely. Follow these steps: 1. In Search Atlas, navigate to Settings and open the CMS Connectors section. 2. Locate the affected WordPress site and select Disconnect. 3. Re-add the site using the correct WordPress URL and authentication credentials. 4. Test the connection by deploying a single piece of content before attempting a bulk deployment. 💡 Best Practices to Prevent Future Sync Failures - Always verify content in your WordPress admin after deployment, especially for bulk publish operations. - Limit bulk deployments to small batches (three to five posts at a time) until you have confirmed the connection is stable. - Clear your WordPress cache after every deployment session. - Ensure that category IDs and author IDs exist in WordPress before deploying content that references them. - If you use a page builder such as Elementor, test a single post deployment first to confirm compatibility before publishing at scale. 🆘 Still Seeing the Issue? If you have followed all the steps above and your content still does not appear in WordPress after deployment, our team can investigate your specific connector 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.

🛠️ Troubleshooting Deployed SEO Changes Not Appearing in Shopify

This article explains what the Deployed status means in Search Atlas and why your SEO changes may not yet be visible inside Shopify. 🔍 What "Deployed" Actually Means In Search Atlas, Deployed means the changes have been approved and sent from Search Atlas to Shopify — but it does not automatically guarantee they are visible in your Shopify admin or live storefront. The change must also be accepted and rendered by Shopify, which depends on a successful connection between the two platforms. 🛠️ What to Do If Your Changes Are Not Appearing 1. Verify your Shopify integration is active. Confirm that your Shopify store is connected to Search Atlas. If the integration is disconnected, Search Atlas cannot write changes to Shopify even when the status shows Deployed. 2. Re-authenticate if needed. If the connection appears broken or was set up a long time ago, disconnect and reconnect your Shopify store, then re-deploy the changes. 3. Check the specific resource in Shopify. Log in to your Shopify admin and navigate directly to the page, product, or collection that was changed. Review the SEO fields to see whether the new values are present. 4. Re-deploy if values are still missing. If Shopify still shows the old values, return to Search Atlas, find the affected item, and trigger a new deployment. Monitor the status after saving to confirm it progresses to Deployed again. 5. Wait for propagation if the values are present. If the values are already updated in Shopify but are not yet showing in search results or on the live storefront, allow time for Shopify's theme to re-render and for search engines to re-crawl the page. 📋 When Escalating to Support If the steps above do not resolve the issue, please have the following ready when you contact us: - Your project name in Search Atlas - The specific URL(s) of the affected Shopify pages, products, or collections - The exact status shown in Search Atlas for the affected items (e.g., Deployed, Pending) - Any error messages you have seen, including the exact wording - The date and time when you last deployed the changes 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.

🛠️ Fix WordPress CMS Sync Failures with AIOSEO

🔍 Overview If changes you publish from Search Atlas are not appearing in WordPress, you may be affected by a known bug involving AIOSEO smart tags. This issue is related to the way AIOSEO smart tags interact with the Search Atlas sync process, and it can prevent your SEO changes from being applied correctly to affected pages. This article explains what is known about the issue and what to have ready when contacting our team for assistance. ⚠️ What Causes This Issue The root cause is a known bug involving AIOSEO smart tags and their interaction with WordPress CMS sync in Search Atlas. When this bug is present, SEO changes published through Search Atlas or OTTO SEO may not appear on affected WordPress pages as expected. Because this is an active bug, the specific behavior and scope can vary. Our support team will need to investigate your account and site configuration directly to identify the exact impact and apply the correct fix. 🛠️ What to Do This bug requires investigation and action by the Search Atlas support team. There are no self-serve remediation steps that have been validated for this issue. Attempting to manually modify your AIOSEO or WordPress settings without guidance may not resolve the problem and could cause additional complications. To get this resolved as quickly as possible, please have the following information ready when you contact us: - The name of your WordPress project as it appears in Search Atlas. - The URLs of the affected pages where sync changes are not appearing. - A description of what changes you attempted to publish and through which feature (e.g., OTTO SEO or Content Sync). - The approximate date and time when you first noticed the issue. - Any error messages displayed in Search Atlas or WordPress related to the sync. 🔄 What to Expect Once our team reviews your case, we will investigate the AIOSEO smart tags bug as it applies to your specific configuration and work with you to restore a working sync. Resolution timelines may vary depending on the complexity of the issue. 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.

🛠️ Fix Table Formatting Loss When Publishing Articles

🔍 Overview When you publish an article from Search Atlas to a connected CMS, tables may lose their formatting — borders disappear, columns collapse, or the entire table renders as plain text. This is a known issue that has been resolved through platform updates, but a few steps on your end can ensure tables transfer cleanly across all your CMS connections. ⚙️ Why This Happens Table formatting can break during publishing for a few common reasons: - HTML sanitisation by the CMS: Some CMS platforms strip or rewrite certain HTML tags — including <table>, <thead>, and <td> — when content is received via API, causing borders and structure to disappear. - Block conversion conflicts: When Search Atlas converts your article into CMS-compatible blocks, tables may be flattened into a single content block instead of being preserved as structured elements. - Missing table styles: The CMS theme may not apply default border styles to tables, making them appear invisible even when the HTML is technically correct. ✅ Recommended Fixes 1. Re-publish the article after the platform update. A fix preserving table structure during CMS publishing has been deployed. Open your article in the Content Editor, make no changes, and click Publish again. This forces the updated export logic to run. 2. Check your CMS connection settings. Navigate to your CMS integrations and confirm that the connection is active and using the latest version. Disconnect and reconnect any affected CMS if the issue persists after re-publishing. 3. Verify your CMS theme supports table styles. In WordPress and similar platforms, add the following CSS to your theme's stylesheet or custom CSS panel to restore visible table borders: 1. Test with a single CMS connection first. If you have multiple connections affected, re-publish to one CMS and confirm the table renders correctly before pushing to the remaining five. This helps isolate whether the issue is platform-wide or specific to one integration. 2. Avoid copying table content from external sources. If you paste a table from Google Docs, Microsoft Word, or another tool into the Content Editor, the underlying HTML may carry incompatible styles. Build tables directly inside the Search Atlas editor when possible. 3. Open the left sidebar → Content (Content Genius tab). 4. Locate the article with the formatting issue and click to open it. 5. Scroll through the article to confirm the table appears correctly inside the editor. 6. Click Publish and select your target CMS connection. 7. Once published, visit the live URL or CMS preview to confirm the table borders and columns are intact. 8. Repeat for each additional CMS connection as needed. - Do not manually edit raw HTML in your CMS to re-add table tags — this can be overwritten on the next publish. - Do not delete and recreate CMS connections as a first step; re-publishing is sufficient in most cases. - Do not use the CMS's built-in editor to reformat the table after publishing, as subsequent publishes from Search Atlas may overwrite those changes. - Confirm you are using a supported CMS version. - Check that your CMS API key has write permissions, which are required for full HTML block publishing. - Clear the CMS page cache after publishing, as a cached version may still display the old formatting. table, th, td { border: 1px solid #ccc; border-collapse: collapse; padding: 8px; } This ensures tables display correctly regardless of how your theme handles default styles. 📋 Step-by-Step: Re-Publish an Article 🚫 What to Avoid 💡 Still Seeing the Issue? If tables are still not rendering correctly after re-publishing, try the following quick checks: 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.

🔗 Resolve Recurring Google Disconnections

🔍 Why Google integrations disconnect Recurring Google integration disconnections can occur when the platform deactivates the integration. This is a platform-side issue and does not necessarily indicate a problem with your Google account or permissions. 🛠️ If your integration keeps disconnecting Record the affected project, Google integration type, approximate disconnect times, and any error message shown. Share these details with our team so they can investigate the platform deactivation and determine the appropriate resolution. If the integration continues disconnecting after you attempt to reconnect it, do not repeatedly remove and add the integration. Report the recurring issue with the affected project and integration details so it can be investigated. 💬 Get help from our team 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.

🔑 Fix External API 403 Scope Errors in Search Atlas

🔍 Overview If every External API call — including the token/validate endpoint — returns an HTTP 403 error with the message "Invalid scope provided. Check API Key permissions on your Press Releases account!", your API key is missing the press-release scope required by the Search Atlas External API (used by Signal Genesys). This article explains what causes the error and walks you through the steps to fix it. ⚠️ Understanding the Error The 403 response is a permissions error, not an authentication failure. Your API key is recognized, but it has not been granted the scopes needed to access press release endpoints. Common reasons this happens include: - The API key was created before the press-release scope was added to your plan. - The key was generated with default or limited permissions. - Your account plan does not currently include External API / press-release access. 🛠️ Step-by-Step: Check and Update Your API Key Permissions 1. Log in to your Search Atlas account and navigate to your Account Settings (click your Avatar Menu (👤) in the top-right corner). 2. Go to the API Keys or Integrations section within Account Settings. 3. Locate the API key you are using for your External API or Signal Genesys integration. 4. Click Edit or Manage Permissions on that key. 5. Look for the press-release scope (sometimes listed as External API or Press Releases) and ensure it is enabled. 6. Save your changes. 7. Re-run your API call to confirm the 403 error is resolved. If you do not see a press-release or External API scope option on the key, proceed to the next section. 📋 If the Scope Option Is Not Available The press-release scope may not be visible if it is not included in your current subscription plan. In that case, the scope cannot be enabled from within the API key settings alone — it must be unlocked at the account or plan level first. Here is what to check: - Plan eligibility: Confirm that your Search Atlas plan includes External API and Press Release access. Refer to your plan details in Account Settings under Billing or Subscription. - Regenerate the key: If the plan is correct but the scope is still missing, try deleting the existing API key and generating a new one. Newly created keys inherit the latest permissions tied to your account. - Existing keys: Keys created before a plan upgrade may not automatically receive new scopes. A fresh key should resolve this. 🔗 Reconnecting Signal Genesys After Fixing Permissions Once the correct scopes are in place, update the API key in your Signal Genesys configuration so the integration uses the updated credentials: 1. Copy your updated or newly generated API key from Search Atlas Account Settings. 2. Open your Signal Genesys settings and navigate to the Search Atlas API or External API connection section. 3. Replace the old API key with the new one. 4. Save and test the connection using the token/validate endpoint to confirm a successful 200 OK response. ✅ Verifying the Fix After updating your key and permissions, verify that the integration is working correctly: - The token/validate endpoint should return HTTP 200 instead of 403. - Press release submissions and other External API actions should complete without scope-related errors. - If you still receive a 403 after following all steps, the issue may require a backend scope assignment on your account that cannot be self-served. 💬 Still Seeing the 403 Error? If you have completed all the steps above and the error persists, the press-release scope may need to be manually enabled on your account by our team. 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.

🔧 Fix Slack Integration Errors in Search Atlas

🔍 Overview Some Search Atlas users encounter errors when setting up or using the Slack integration, including a message stating 'Gemini 3.5 Flash is no longer available.' This article explains why these errors occur and how to resolve them quickly. ⚠️ Common Slack Integration Errors The most frequently reported issues with the Slack integration include: - 'Gemini 3.5 Flash is no longer available' — the AI model previously used for this feature has been deprecated and replaced. - Silent failures after approvals — the integration appears to complete setup but does not return a successful result or confirmation. - Channels not appearing — connected Slack channels may not display as expected within the platform. ✅ Step-by-Step Resolution 1. Refresh the integration: In the left sidebar, go to Coworker → Connectors, and locate Slack. Disconnect the existing connection if one is shown. 2. Reconnect your Slack workspace: Click Connect Slack and follow the on-screen authorisation steps. Make sure you are logged into the correct Slack workspace before proceeding. 3. Verify channel access: After reconnecting, confirm that your Search Atlas agent has been added to the relevant Slack channels inside Slack itself. The agent must be a member of a channel to send or receive messages there. 4. Test the integration: Send a test message or trigger an action through the platform to confirm the connection is working. A successful result will be confirmed on screen. 5. Clear your browser cache: If the integration still does not respond as expected, clear your browser cache and cookies, then reload the platform and repeat the steps above. 💡 Why Did the Gemini Error Happen? The 'Gemini 3.5 Flash is no longer available' error appeared because an earlier version of the AI model powering certain Search Atlas features was deprecated. Our engineering team has resolved this by updating the platform to use a supported model version. No action is required on your part to fix the model itself — the update has already been applied. If you still see this error message, it is likely a cached page. Clearing your browser cache and reloading the platform should resolve it. 🏢 Note for GoHighLevel (GHL) Account Users If you are using Search Atlas through a GoHighLevel (GHL) account and cannot see the Slack integration option in your Settings page, this is expected behaviour. The Slack integration is currently not available for GHL-connected accounts. This is a platform-level restriction and is not related to your subscription tier or permissions. 🛠️ Troubleshooting Checklist - Ensure you have admin permissions in your Slack workspace — without these, the authorisation step may fail silently. - Check that your browser is not blocking third-party pop-ups, as the Slack authorisation flow opens in a new window. - If using a company Slack workspace, confirm that your organisation's Slack admin has approved third-party app connections. - Make sure your Search Atlas account has an active plan that includes AI agent and integration features. 💬 Still Need Help? If you have followed the steps above and are still experiencing issues with the Slack integration, our support team is ready to help. 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.

🛠️ Fix WordPress Blog Changes Not Showing

🔍 Why changes may not appear Search Atlas may show a blog update as deployed while the live page still displays an older version. This usually happens because of page caching, a plugin or theme overriding the content, or the live URL differing from the page that was updated. ✅ Check the live page first 1. Open the published blog post URL in a private or incognito browser window. 2. Refresh the page and confirm that you are viewing the correct URL, including the preferred version of the domain. 3. View the page source or use your browser’s inspect tools to confirm whether the updated H1 and image are present in the HTML. If the change appears in the page source but not visually, the theme, CSS, or a page builder may be changing how the content is displayed. 🧹 Clear WordPress and site caches Clear all active cache layers, then test the page again. Check your WordPress caching plugin, hosting cache, CDN, and browser cache. If your site uses a CDN, purge the specific page or cache zone when possible instead of only refreshing your browser. 📝 Troubleshoot an H1 that does not update - Confirm the post has one visible H1 on the published page. - Check whether the theme generates the H1 from the post title instead of the edited content. - Review page-builder templates, custom fields, and theme settings that may replace the standard post heading. - Make sure the update was applied to the published post, not a draft, revision, or staging copy. - Check the live URL again after clearing caches. Some themes display a title outside the main post content. In that case, changing content inside the editor may not change the heading shown by the theme. 🖼️ Fix a duplicated featured image A duplicated image commonly appears when the theme automatically displays the featured image and the same image is also inserted at the top of the post content. - Remove the repeated image from the post body if the theme already displays the featured image. - Check theme or page-builder settings for an automatic featured-image block. - Review image blocks, reusable blocks, and custom fields that may add the same image again. - Clear caches and reload the published URL after saving the change. If the image is duplicated only on the live page, inspect the theme template or page-builder layout rather than adding another content edit. 🚀 Confirm deployment status 1. Open the relevant deployment or fix record in Search Atlas. 2. Confirm that the target WordPress site and exact post URL are correct. 3. Allow the deployment to finish before testing the page. 4. Verify the live page, rather than relying only on a successful deployment message. A successful deployment confirms that Search Atlas sent the change. It does not always mean that every cache, theme template, or WordPress output layer has refreshed. 💬 Get help If the live page still does not match the deployed change after checking the URL, caches, theme, and page builder, capture the page URL and the affected change. 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.

🔍 Fix Lead Capture Widget Invitation-Only Access Issue

🧭 Overview If your lead capture widget shows an Invitation Required page, the available source information does not confirm a specific configuration issue or documented fix. Use the checks below to capture the details needed for troubleshooting. ✅ What to Check 1. Open the widget as a new visitor in a private or incognito browser window. 2. Record the exact page URL and the complete message shown, including whether it says Invitation Required. 3. Note the website where the widget appears and the approximate date and time when the issue occurred. 4. Compare the result in the private window with the result for an account that has access, if available. 5. Provide these details when requesting assistance so the team can investigate the widget access issue. If the issue continues, do not assume that changing the widget or domain settings will resolve it, because no confirmed resolution steps are available in the source information. 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.

⏱️ Fix Timeout Errors and Escalate Support Correctly

⏱️ What Is a Timeout Error? A timeout error occurs when the platform starts a process but does not receive a response within the expected time window. Instead of waiting indefinitely, the system stops the request and shows an error message. These errors are usually intermittent and often resolve on their own — but some cases require action on your part or from our team. 🔍 Common Scenarios Where Timeouts Appear - Page loading or redirect issues: After completing an action such as sign-up or project creation, you may be redirected to a blank page or see a loading error. - AI Agent requests stalling: If you submit a request and the platform does not respond or appears stuck, a background timeout may have interrupted the process. - Batch or long-running tasks: Operations that process large amounts of data may time out under high load. 🛠️ Steps to Resolve a Timeout Error 1. Refresh the page. Many timeout errors are transient. A simple page refresh clears the stalled request and reloads the session. 2. Clear your browser cache. Go to your browser settings, clear cached files and cookies for the Search Atlas domain, then reload the page. 3. Try a different browser or incognito mode. This rules out browser extensions or stored data causing the issue. 4. Wait 60 seconds and retry. If the platform is processing a large task, give it a moment before submitting the request again. 5. Reattempt the original action. If you were interrupted during a workflow, log out and log back in, then retry. Your saved data should remain intact. 6. Check for duplicate submissions. If you clicked a button multiple times before the error appeared, only resubmit once to avoid creating duplicate tasks or projects. 📋 Before You Contact Support — Gather These Details When timeout issues cannot be resolved with the steps above, our support team will need specific information to investigate efficiently. Please have the following ready before starting a chat: - The exact page or feature where the timeout occurred (e.g., project creation, AI Agent, content editor) - The time and date the error happened (include your timezone) - A screenshot or screen recording of the error message if available - The steps you took immediately before the error appeared - Whether the issue is happening consistently or only sometimes - Your browser name and version (e.g., Chrome 124, Safari 17) Providing these details upfront means our team can investigate without back-and-forth delays and resolve your issue faster. 💡 Why Describing the Problem Clearly Matters Timeout errors can stem from many different causes — network conditions, platform load, browser state, or a specific feature behaving unexpectedly. The more precisely you can describe what you were doing and what you saw, the faster our team can identify the root cause and apply the right fix. 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.

🔧 Fix Recurring Google Integration Disconnections

What Is Happening? Some Search Atlas users experience recurring disconnections with Google Search Console (GSC) and Google Business Profile (GBP) integrations. The connection status may flip between Connected and Not Connected repeatedly, even after attempting to reconnect. This is a known issue that may require backend investigation to resolve fully. Common Triggers While our team investigates, the following are known factors that can contribute to repeated disconnections: - OAuth token expiry or revocation: Google periodically invalidates access tokens, especially if your Google account password changed, two-factor authentication was updated, or third-party app access was revoked in your Google Account settings. - Multiple reconnect attempts in one session: Reconnecting more than once without fully completing the auth flow can corrupt stored credentials, causing the status to flip repeatedly. - Browser or cache interference: Cached sessions, browser extensions, or cookie blockers can interrupt the OAuth handshake mid-flow, leaving the connection in a broken state. - Google Account permissions changed: If the Google Account used to connect lost owner or full access rights to the Search Console property or Business Profile, Search Atlas cannot maintain a valid connection. What You Can Try Before escalating to our team, you may attempt the following general steps: 1. Revoke and re-grant access in your Google Account. Go to myaccount.google.com → Security → Third-party apps with account access, find Search Atlas, and remove it. This clears any corrupted tokens on Google's side. 2. Clear your browser cache and cookies, or open an incognito / private window. Disable any ad-blocker or privacy extensions for the duration of reconnection. 3. In Search Atlas, locate your account integrations settings and find the Google Search Console or Google Business Profile connector. 4. Disconnect the integration completely — do not skip this step even if the status already shows as disconnected. A full disconnect ensures stale credentials are cleared. 5. Reconnect once. Complete the full Google OAuth flow and grant all requested permissions. Do not click the button multiple times — wait for the redirect to complete fully before taking any other action. When the Issue Persists — What to Have Ready If disconnections continue after following the steps above, this issue requires backend investigation by our team. To help us resolve it as quickly as possible, please have the following information ready when you reach out: - The email address of the Google Account used for the integration - The name of the GSC property or Business Profile affected - The approximate date and time the disconnection first occurred or recurred - Any error messages displayed during reconnection attempts 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.

🔧 Fix WordPress REST API Blocked by Hosting Firewall

Overview When Content Assistant displays a vault not connected error during content generation or publishing, the most common cause is not a WordPress configuration issue — it is a firewall or Web Application Firewall (WAF) rule set by your hosting provider that blocks requests to the /wp-json/ REST API endpoint before they ever reach WordPress. This article explains why this happens and walks you through general steps to resolve it. Why This Happens Search Atlas Content Assistant communicates with your WordPress site through the WordPress REST API. All requests are sent to a URL that ends in /wp-json/. Many hosting providers run server-level firewalls or WAF rules that inspect incoming traffic and can block these requests automatically — even when your WordPress REST API settings appear correct inside WordPress itself. Common reasons a hosting firewall blocks REST API requests include: - The firewall treats automated API calls as suspicious bot traffic. - A security rule flags requests that do not originate from a browser. - WAF rulesets block access to /wp-json/ as a hardened security measure. - The hosting control panel has a security setting enabled that restricts REST API access. Because the block happens at the server level, disabling or re-enabling the REST API inside WordPress will not fix the problem. How to Confirm This Is the Cause Before changing any settings, confirm that the REST API endpoint is being blocked at the hosting level: 1. Open a new browser tab and go to https://yourdomain.com/wp-json/ (replace with your actual domain). 2. If you see a JSON response listing WordPress routes, the REST API is reachable and the issue is elsewhere. 3. If you see an error response or a generic hosting error page, your hosting provider firewall may be blocking the endpoint. 4. You can also use your browser's developer tools (Network tab) to check the HTTP response code returned for the /wp-json/ URL. General Fix: Whitelist the REST API in Your Hosting Firewall The steps below apply to most hosting providers. Log in to your hosting control panel and look for a section related to Security, Firewall, or WAF. 1. Locate the firewall or WAF settings for your domain. 2. Find any rule that blocks or restricts access to /wp-json/ or REST API requests. 3. Add a whitelist or allow rule for the path /wp-json/* so all REST API sub-routes are permitted. 4. Save your changes and wait a few minutes for the settings to take effect. 5. Return to Content Assistant and attempt to reconnect your vault or retry publishing. If the Issue Persists If you have reviewed your hosting firewall settings and the vault connection error continues, please have your domain name, hosting provider name, and any error messages ready when you reach out. 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.

⚡ Cloudflare DNS Proxying and Domain Verification

Overview When you connect a custom domain to Search Atlas, our platform performs a DNS verification check to confirm you own the domain. If your domain is managed through Cloudflare, its proxy setting (the orange cloud icon) can interfere with this process — causing verification to fail or your site to become unreachable inside the platform. This article explains how Cloudflare proxying affects domain verification and what information to have ready so our team can help you resolve it quickly. How Cloudflare Proxying Affects Verification Cloudflare offers two DNS modes for each record: - Proxied (orange cloud): Traffic is routed through Cloudflare's network. The real IP address of your server is hidden from external lookups. - DNS Only (grey cloud): DNS resolves directly to your server's IP. No Cloudflare proxy is applied. Search Atlas needs to resolve your domain to our servers to verify ownership and route traffic correctly. When Cloudflare's proxy is active, it returns Cloudflare's own IP addresses instead — so our verification check can fail even if your DNS record appears to be configured correctly. What You Can Check on Your End Before contacting support, review the following in your Cloudflare DNS settings: - Confirm whether the record pointing to Search Atlas is set to Proxied (orange cloud) or DNS Only (grey cloud). - Note the record type currently in use (CNAME or A record) and the value it is pointing to. - Check whether there are multiple conflicting records (for example, both a CNAME and an A record) for the same hostname. Because the correct DNS configuration depends on details specific to your Search Atlas account and project setup, our support team will need to confirm the exact record type and target value for your domain before you make any changes. Making changes without confirmed instructions from our team may cause additional downtime. What to Have Ready When You Contact Us To help our team resolve this as quickly as possible, please have the following information ready: - The domain or subdomain you are trying to connect to Search Atlas - The current DNS record type (CNAME or A record) and the value it points to, as shown in your Cloudflare dashboard - Whether Cloudflare proxying is currently set to orange cloud (Proxied) or grey cloud (DNS Only) - Any error message shown in Search Atlas when verification fails - The approximate time you first noticed the issue 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.

🔧 Fix WordPress CMS Sync Still Failing

What Is Happening Your WordPress CMS sync may stop working again even after a previous support ticket was marked as solved. This is a known recurring issue where the sync appears resolved but continues to fail silently. Because the root cause requires investigation on the backend, this is not something that can be fully resolved through self-serve steps alone. What to Expect Our team will need to look into your specific account and WordPress connection to identify why the sync is failing again. The issue may be related to authentication, a connector state, or a backend configuration — but confirming the exact cause requires access to your account data. How to Escalate Effectively To help our team resolve this as quickly as possible, please have the following ready when you reach out: - The name of the WordPress site or project affected by the sync failure. - Any error message you are seeing, copied exactly as it appears. - The date and approximate time when the sync stopped working again. - Confirmation of whether the issue started immediately after the previous ticket was closed or after some time had passed. - Your Search Atlas account login details. 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.

🛠️ Fix Wix Integration Metadata and Content Defects

🔍 Overview of Known Wix Integration Defects Search Atlas integrates with Wix to help you publish and manage on-page SEO content directly from the platform. However, a small number of users have reported recurring defects when using this integration. This article explains the four known issue categories, what causes them, and the steps you should take to document and escalate them effectively. The four defect categories currently under investigation are: - Metadata not saving correctly — Meta descriptions or titles written in Search Atlas do not persist on the live Wix page after publication. - Title mutations — Page titles are altered unexpectedly during or after a publish action, resulting in unintended wording or formatting changes. - Alt text rewrites — Image alt text is overwritten with incorrect values, or reverts to a previous state after publishing. - Cold-load discrepancies — Changes appear saved inside the platform but do not reflect on a fresh browser load of the published Wix page. ⚠️ Why These Issues Happen Wix uses a proprietary API layer that controls how external tools write and read page content. Conflicts can occur when: - Wix's internal editor cache does not sync immediately with changes pushed via the API. - Wix applies its own formatting rules that override externally set title or alt text values. - A publish action triggers a Wix-side re-render that resets certain metadata fields to their previous state. These are integration-level defects that require engineering investigation on both the Search Atlas and Wix API sides. They cannot be resolved by changing settings within your account. 📋 How to Document Your Issue Before Escalating Strong documentation speeds up engineering investigations significantly. Before contacting support, please gather the following: 1. Affected page URLs — List every Wix page URL where the defect has occurred. 2. Screenshots or screen recordings — Capture the value as set inside Search Atlas, then the value shown on a fresh (incognito) browser load of the live page. 3. Timestamps — Note the exact date and time you published the change. 4. Steps to reproduce — Write out exactly what you did: which field you edited, what value you entered, and what you expected versus what appeared. 5. Previous ticket or case references — If you have earlier ticket numbers (for example, from a previous support conversation), include these so our team can retrieve prior evidence and link everything to a single active case. 🚀 How to Escalate to Engineering Once you have your documentation ready, use the following process to get your case escalated with a tracked reference: 1. 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. 2. Tell the teammate you are reporting a Wix integration defect and provide your documentation. 3. Ask the teammate to create or reopen an escalation ticket and confirm the active reference number with you in chat. 4. Request that the ticket be linked to any prior case references you have on file so evidence is consolidated. 5. Ask for a named owner and current status to be assigned to your case so you have a clear point of contact. Our support team will log the defect with engineering and set up the required cold-load and controlled publication tests to confirm whether the fix is working before the case is closed. ✅ What Happens After Escalation Once your case is active with engineering, the following process applies: - Engineering will review all linked evidence from previous and current tickets. - A cold-load test will be performed — this means loading the affected page on a fresh browser session with no cached data to verify whether published changes are visible. - A controlled publication test will be run — this involves making a defined change, publishing it, and independently verifying the result on the live Wix page. - The case will remain open until both tests confirm resolution. It will not be closed based solely on an internal fix being deployed. - You will receive a status update via the platform chat each time there is a meaningful change to your case. 🛡️ Temporary Workarounds While Awaiting a Fix These steps will not permanently resolve the defects, but they may reduce the impact while engineering works on a fix: - Verify changes immediately after publishing — Open the page in a private or incognito browser window right after publishing to check whether the correct values appear. - Re-publish if a revert is detected — If metadata or alt text has reverted, make the change again inside Search Atlas and publish a second time. Some users find the second publish attempt sticks. - Avoid bulk publishing — Publishing one page at a time appears to reduce the frequency of title mutations compared to publishing multiple pages simultaneously. - Keep a local record of intended values — Maintain a simple document with your intended titles, meta descriptions, and alt text so you can quickly re-enter them if a revert occurs. 💬 Need Help With Your Case? 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.

🔧 Fix Shopify Connector Disconnected After Token

🔍 Overview After adding a Shopify token in Search Atlas, you may notice the connector still shows a Disconnected status. In most cases, this is caused by stale browser cache or cookies interfering with the authentication handshake — not a problem with the token itself. Following the steps below resolves the issue for the majority of users without requiring support. ⚠️ Before You Begin Confirm the following before troubleshooting the browser: - Your Shopify token was generated with the correct permissions required for the integration. - The token was copied and pasted in full with no extra spaces. - You saved the connector settings after entering the token. If all three are confirmed and the connector still shows disconnected, proceed with the steps below. 🧹 Step 1: Clear Your Browser Cache and Cookies Cached authentication data can prevent Search Atlas from recognising a newly added token. Clearing your cache and cookies forces the browser to load a fresh session. 1. Open your browser settings and navigate to the option for clearing browsing data. 2. Set the time range to All time. 3. Check both Cached images and files and Cookies and other site data. 4. Clear the data and wait for the process to finish. 5. Close all browser tabs and reopen your browser completely. 🔄 Step 2: Reconnect the Shopify Connector After clearing the cache, log back in to Search Atlas and navigate to Avatar → Settings → CMS Connectors to access your Shopify connector settings. If the connector still shows Disconnected, try re-entering your Shopify token and saving again. Allow a moment for the status to update before refreshing the page. 🕵️ Step 3: Try a Different Browser or Incognito Window If the connector still shows disconnected after clearing cache, test in a private or incognito window, or switch to a different browser entirely. This rules out browser extensions, conflicting cookies, or persistent cache issues. Repeat Step 2 inside the new window. If the connection succeeds here, a browser extension in your main browser is likely the cause. Try disabling extensions one by one to identify the conflict. 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.

🛠️ Fix OTTO Pixel Detection and Google Analytics Issues

🔍 Overview Two of the most common setup issues in Search Atlas involve the OTTO Pixel not being detected on your site and Google Analytics properties failing to appear or connect. This article walks you through the most likely causes and how to fix them. ⚙️ Why the OTTO Pixel May Not Be Detected The OTTO Pixel can fire correctly and even appear in your page source without being successfully detected by Search Atlas. This is usually caused by one of the following reasons: - Pixel placed inside an iFrame or shadow DOM: Search Atlas scans the top-level document. If your pixel is injected inside an iFrame or a shadow DOM component, the detection crawler cannot read it. - Pixel loading after a JavaScript delay: If the pixel fires only after a user interaction or a delayed script execution, the detection tool may scan the page before the pixel renders. - Cookie consent blocking the pixel: A cookie consent or consent management platform (CMP) may be preventing the pixel from loading for users who have not accepted tracking, including automated crawlers. - Caching layer serving a stale page: Your CDN or server cache may be serving an older version of the page that does not yet include the pixel code. - Incorrect placement in the HTML: The pixel must be placed inside the <head> tag of every page you want tracked, not in the footer or conditionally loaded only on certain pages. ✅ How to Fix OTTO Pixel Detection 1. Open your site's source code and confirm the pixel snippet is placed inside the <head> tag, directly in the HTML and not inside a script loader or tag manager container that delays execution. 2. If you are using a tag manager such as Google Tag Manager, make sure the trigger is set to All Pages and the firing priority is high enough to load before other scripts. 3. Check your cookie consent platform settings. Add the OTTO Pixel to the necessary or always active category so it loads without requiring user consent. 4. Purge your CDN and server cache after making any changes, then wait a few minutes before triggering a new detection scan. 5. In Search Atlas, go to Left sidebar → OTTO SEO → All Sites (SEO Automation) and locate your site. Click Re-detect Pixel to run a fresh scan after you have made the corrections above. 📊 Why Google Analytics Properties Are Not Showing Up If your Google Analytics properties are missing from the Search Atlas connection screen or fail to load after authorisation, consider these common causes: - Wrong Google account connected: The Google account you authorised may not be the one that has access to the relevant GA4 or Universal Analytics property. - Insufficient permissions on the GA property: Your Google account needs at least Viewer level access to a property for it to appear in Search Atlas. Editor or Administrator access is required to write data. - GA4 property not yet published: A newly created GA4 property can take up to 24–48 hours to become visible through the Google API. Wait and try reconnecting later. - Token expired or revoked: If you recently changed your Google account password or revoked third-party app access, the existing token will be invalid and must be re-authorised. - Multiple Google accounts causing a conflict: Browser sessions with multiple Google accounts logged in simultaneously can cause the wrong account to be used during OAuth authorisation. ✅ How to Fix Google Analytics Connection Issues 1. Sign out of all Google accounts in your browser, then sign back in using only the account that owns or has access to the GA property you want to connect. 2. In Search Atlas, go to Left sidebar → OTTO SEO → All Sites (SEO Automation), open your site settings, and disconnect the existing Google Analytics integration. 3. Navigate to Site Metrics → Site Explorer (GSC Accounts page) and click Connect GA Account to complete the OAuth flow again, making sure you select the correct Google account and grant all requested permissions. 4. Once reconnected, confirm that the correct GA4 property appears in the dropdown. If it does not, verify that your Google account has at least Viewer access to that property inside Google Analytics under Admin → Property Access Management. 5. If the property was created recently, wait 24–48 hours and attempt the reconnection again. 💡 Quick Checklist Before Contacting Support - OTTO Pixel is in the <head> tag on all target pages - No cookie consent or CMP is blocking the pixel from loading - CDN and server cache have been cleared after pixel changes - Re-detect Pixel scan has been run from Left sidebar → OTTO SEO → All Sites (SEO Automation) - Only one Google account is active in the browser during OAuth - The connected Google account has sufficient permissions on the GA property - Newly created GA4 properties have been given 24–48 hours to propagate 🆘 Still Need Help? If you have followed all of the steps above and are still experiencing issues, we are here to help. 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.

🔌 Fix OTTO Pixel WordPress Sync Issues

🔍 Overview The OTTO Pixel WordPress plugin links your website to Search Atlas so OTTO SEO can read your site data and apply optimizations. When the plugin shows Synced inside WordPress but Search Atlas still cannot detect it, a configuration or connectivity issue is preventing the two systems from communicating. This guide walks you through every fix, step by step. ✅ Before You Begin Confirm the following before diving into deeper troubleshooting: - You are logged in to Search Atlas and viewing the correct project/domain. - The OTTO Pixel plugin is active (not just installed) in your WordPress dashboard under Plugins → Installed Plugins. - You installed the plugin using the unique pixel key generated inside Search Atlas — not a generic copy. 🛠️ Step 1 — Verify Your Pixel Key Each domain in Search Atlas has its own unique pixel key. Using the wrong key is the most common cause of sync failures. 1. In Search Atlas, go to OTTO SEO → SEO Automation (left sidebar, URL: /seo-automation-v3). 2. Select your website and open the OTTO SEO panel. 3. Locate your Pixel Key and copy it exactly — including any hyphens or uppercase letters. 4. In WordPress, go to Search Atlas (WP menu) → Settings and paste the key into the OTTO Pixel UUID field. 5. Click Save Changes, then return to Search Atlas and wait up to 60 seconds for detection. 🔄 Step 2 — Deactivate, Reinstall, and Reactivate A corrupted plugin installation can cause silent sync failures even when WordPress reports the plugin as active. 1. In WordPress, go to Plugins → Installed Plugins. 2. Click Deactivate next to OTTO Pixel, then click Delete. 3. Return to Search Atlas and copy your pixel key again (see Step 1). 4. Reinstall the OTTO Pixel plugin by uploading the latest .zip version provided in Search Atlas via Plugins → Add New → Upload Plugin. 5. Enter your pixel key, save, and activate the plugin. 6. Check Search Atlas for detection — allow up to 2 minutes. 🌐 Step 3 — Check for Firewall or Security Plugin Conflicts Security plugins and server-level firewalls sometimes block the outbound requests the OTTO Pixel plugin needs to reach Search Atlas servers. - Wordfence, Sucuri, iThemes Security: Temporarily disable the firewall rules or whitelist Search Atlas domains (searchatlas.com and its subdomains). - Cloudflare: Set your domain's security level to Essentially Off temporarily and retest. If detection succeeds, add a firewall rule to allow traffic to/from Search Atlas. - Hosting-level firewalls (e.g., SiteGround, WP Engine): Contact your host or check your control panel to whitelist outbound requests to Search Atlas. After whitelisting, reactivate your security settings and recheck Search Atlas for detection. ⚙️ Step 4 — Confirm PHP and WordPress Requirements The OTTO Pixel plugin requires a minimum environment to run correctly. - PHP version: 7.4 or higher (PHP 8.x recommended). - WordPress version: 5.8 or higher. - HTTPS: Your site must be served over HTTPS. An SSL certificate must be active and valid. You can check your PHP version at WordPress Dashboard → Tools → Site Health → Info → Server. If your environment is below these minimums, contact your hosting provider to upgrade. 🧹 Step 5 — Clear All Caches Cached responses can prevent the plugin's verification handshake from completing. 1. Clear your WordPress caching plugin cache (e.g., WP Rocket, W3 Total Cache, LiteSpeed Cache) — look for a Clear Cache or Flush Cache button in the plugin settings or admin toolbar. 2. Clear your Cloudflare or CDN cache if applicable. 3. Clear your browser cache and try reloading Search Atlas in a private/incognito window. 4. Return to Search Atlas and check for detection once more. 📋 Step 6 — Test in a Staging or Default Theme Environment Theme functions or other plugins occasionally interfere with pixel output. To isolate the issue: - Temporarily switch to a default WordPress theme (e.g., Twenty Twenty-Four) and recheck detection in Search Atlas. - Disable all plugins except OTTO Pixel, then recheck. Re-enable plugins one at a time to identify any conflict. If detection succeeds after switching themes or disabling plugins, you have identified the conflicting item. Reach out via chat (see below) and share the conflicting plugin or theme name so our team can advise further. 💡 Still Not Working? If you have completed all steps above and Search Atlas still does not detect the OTTO Pixel, there may be a server-level or account-level issue that requires manual investigation. 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. When you open the chat, please share: your domain URL, a screenshot of your OTTO Pixel plugin settings page in WordPress, and the name of any security plugins or CDN services active on your site. This helps our team resolve your issue as quickly as possible.

🔌 Fix OTTO Pixel Plugin Timeout and Throttling Errors

🧭 Overview When authenticating the OTTO pixel WordPress plugin, you may encounter two related issues: the authentication pop-up completes successfully but the connection times out before finishing, or repeated attempts trigger a Request Throttled error. These are distinct problems — this article explains what each error means and what to expect. ⚠️ Understanding the Two Errors Before troubleshooting, it helps to know what each error means: - Connection timeout during authentication: The plugin authenticated your credentials in the pop-up but the handshake between your WordPress site and Search Atlas did not complete in time. - Request Throttled error: After several failed or repeated authentication attempts in a short period, Search Atlas temporarily limits further requests from your site. This is not a permanent block. ⏳ Step 1 — Stop Retrying and Wait If you are currently seeing a Request Throttled error, stop attempting to reconnect immediately. Additional attempts may worsen the situation. 1. Close the OTTO pixel authentication pop-up in your WordPress dashboard. 2. Wait before attempting to reconnect. Because the exact duration and conditions depend on your account and situation, our support team can advise on next steps for your specific case. 3. Do not reload the authentication pop-up or navigate to the OTTO pixel settings while waiting. Once you have waited, you can attempt authentication again. If the issue persists, contact our support team for guidance tailored to your account. 🔧 Step 2 — Contact Support if the Issue Continues If you continue to see a connection timeout or a Request Throttled error after waiting, our team will need to investigate the specific conditions affecting your site and account. To help us assist you as quickly as possible, please have the following ready: - Your WordPress site URL - The exact error message you are seeing (a screenshot is helpful) - The approximate date and time the error first appeared - A note of how many authentication attempts you have made 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.

🛠️ Fix WordPress Pixel and Title Tag Deployment Issues

🔍 Overview Two of the most common WordPress-related issues in Search Atlas are: (1) a 'failed to fetch' error when installing the OTTO SEO pixel, and (2) deployed title tag changes that do not appear on your live site. Both problems usually share the same root cause — a conflict caused by having more than one active deployment method running at the same time. ⚠️ Why These Issues Happen Search Atlas can deploy changes to your WordPress site in two ways: - WordPress Plugin — the OTTO SEO plugin installed directly in your WordPress admin. - Cloudflare Worker — a script that intercepts and modifies pages at the network level. When both methods are active on the same project at the same time, they conflict with each other. This duplicate install state causes pixel fetch failures, prevents title tags from updating, and can even produce duplicate meta title tags on your homepage. You must use one method only. 🛠️ Step 1 — Check for a Duplicate Install 1. Log in to Search Atlas and open your project. 2. Navigate to Left sidebar → OTTO SEO → Installation Guide to view the Pixel Installation settings. 3. Check whether both the WordPress Plugin and a Cloudflare Worker are shown as active. 4. If both are enabled, this is the cause of your issues. Continue to Step 2. 🔧 Step 2 — Remove the Duplicate Deployment Method Decide which installation method you want to keep, then disable the other one completely. If you want to keep the WordPress Plugin: 1. Log in to your Cloudflare dashboard. 2. Go to Workers & Pages and locate the OTTO SEO worker assigned to your domain. 3. Disable or delete the worker. 4. Return to Search Atlas and confirm the pixel status shows only the plugin as active. If you want to keep the Cloudflare Worker: 1. Log in to your WordPress admin panel. 2. Go to Plugins and deactivate and delete the OTTO SEO plugin. 3. Return to Search Atlas and confirm the pixel status shows only the Cloudflare Worker as active. ✅ Step 3 — Reinstall the Pixel (If Needed) If you removed the plugin and are starting fresh with it, follow these steps to reinstall cleanly: 1. In Search Atlas, go to Left sidebar → OTTO SEO → Installation Guide and select WordPress Plugin. 2. Download the latest plugin file or copy your unique pixel snippet. 3. In your WordPress admin, go to Plugins > Add New > Upload Plugin and install the file. 4. Activate the plugin and return to Search Atlas to verify the pixel shows a connected status. Note: If you see a 'failed to fetch' error during installation, it almost always means an old Cloudflare Worker is still active. Confirm the worker has been fully removed before retrying. 📝 Step 4 — Fix Title Tags Not Updating Once only one deployment method is active and the pixel is confirmed connected, title tag changes should deploy correctly. If a previously deployed title tag is still not appearing live, follow these steps: 1. In Search Atlas, go to the page where the title tag change was deployed. 2. Check the deployment status — if it shows an error, redeploy the change. 3. Clear any caching on your WordPress site. Go to your caching plugin (such as WP Rocket, W3 Total Cache, or LiteSpeed Cache) and purge all caches. 4. If you use Cloudflare, log in to your Cloudflare dashboard and go to Caching > Configuration > Purge Everything. 5. Visit your live page and perform a hard refresh (Ctrl + Shift + R on Windows or Cmd + Shift + R on Mac) to bypass your browser cache. If the title tag is still showing the old value after completing these steps, check whether a theme or SEO plugin (such as Yoast SEO or Rank Math) is overriding the title tag. These plugins can conflict with Search Atlas deployments. 🔌 Resolving CSS or Plugin Conflicts In some cases, the OTTO SEO plugin may conflict with your WordPress theme or another active plugin, preventing changes from rendering correctly. To isolate the issue: - Temporarily switch to a default WordPress theme (such as Twenty Twenty-Four) and test whether the title tag appears correctly. - Deactivate other SEO plugins one at a time and check after each deactivation. - Re-enable plugins one by one to identify which one causes the conflict, then reach out for support. 💡 Quick Reference — Common Causes and Fixes - 'Failed to fetch' on pixel install — Remove the duplicate deployment method (plugin or Cloudflare Worker), then reinstall. - Title tag not updating — Confirm pixel is connected, redeploy the change, and purge all caches. - Duplicate meta title on homepage — A sign of a duplicate install state; remove one deployment method. - Changes deploy in Search Atlas but not visible on site — Check for caching layers and conflicting SEO plugins. 💬 Still Need Help? 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.

🛠️ Fix WordPress Pixel and Deployment Issues

🔍 Overview Two common issues affect WordPress sites connected to OTTO SEO: deployed changes (such as title tags) not appearing live on your site, and a "failed to fetch" error when attempting to install a pixel through the chatbot. This article explains why these happen and walks you through the steps to resolve them. ⚙️ Why Your Deployed Changes May Not Appear Live After deploying a change in OTTO SEO — for example, a page title or OG title update — you may notice the change still does not appear on your live WordPress site. This is usually caused by one of the following: - Caching: Your WordPress site, hosting provider, or a CDN (such as Cloudflare) is serving a cached version of the page that does not yet reflect the update. - Duplicate or conflicting plugin installs: If the OTTO SEO plugin and a Cloudflare Worker are both active on the same project, they can conflict and prevent changes from deploying correctly. - Plugin not fully synced: The OTTO SEO plugin on your WordPress site may not have received or applied the latest instructions from OTTO. ✅ Steps to Fix Deployed Changes Not Going Live 1. Clear all caches. Clear the cache in WordPress (using your caching plugin, such as WP Rocket, W3 Total Cache, or LiteSpeed Cache), your hosting provider's cache, and any CDN cache (including Cloudflare). Then revisit the page in an incognito or private browser window. 2. Check for duplicate installations. Go to your WordPress dashboard and confirm that you only have one active method deploying OTTO SEO changes — either the OTTO SEO WordPress plugin or a Cloudflare Worker, not both. Having both active simultaneously causes a conflict that blocks deployments. Deactivate or remove the method you are not primarily using. 3. Verify the plugin is active and up to date. In your WordPress dashboard, navigate to Plugins and confirm the OTTO SEO plugin is installed, activated, and running the latest available version. Update it if a newer version is available. 4. Re-deploy the change in OTTO SEO. Return to the OTTO SEO platform, locate the change you deployed, and deploy it again. After deploying, wait two to three minutes, clear caches once more, and check your live site. 5. Check the deployment status in OTTO. OTTO verifies deployments by scanning your live page. If the status shows not live, this confirms the change has not yet been detected on the page. Follow the steps above and re-check after clearing caches. 📡 Why You Get a "Failed to Fetch" Error During Pixel Installation When using the OTTO chatbot to install a pixel on your WordPress site, a "failed to fetch" error typically means OTTO could not communicate with your WordPress site to complete the installation. Common causes include: - The OTTO SEO plugin is not installed or activated on your WordPress site. The pixel installation requires the plugin to be present and active so OTTO can interact with the necessary endpoints. - REST API access is blocked. Some security plugins, firewall rules, or hosting configurations block access to the WordPress REST API, which OTTO uses to install the pixel. - Incorrect site URL or connection settings in the OTTO SEO platform. ✅ Steps to Fix the "Failed to Fetch" Pixel Error 1. Install and activate the OTTO SEO plugin. In your WordPress dashboard, go to Plugins → Add New → Upload Plugin, upload the plugin .zip provided by Search Atlas, and install and activate it. If it is already installed, deactivate it and reactivate it to reset the connection. 2. Check that your REST API is accessible. Visit yoursite.com/wp-json/ in your browser. If you see a JSON response, the REST API is working. If you see an error or a blocked page, contact your hosting provider or check your security plugin settings to allow REST API access. 3. Confirm your site URL in OTTO. In the OTTO SEO platform, verify that the site URL connected to your project exactly matches your live WordPress site URL (including whether it uses www or not, and https). 4. Retry the pixel installation. Once the plugin is active and the REST API is accessible, return to the OTTO chatbot and attempt the pixel installation again. 🚀 Quick Checklist - OTTO SEO plugin installed, activated, and up to date - No duplicate install method active (plugin AND Cloudflare Worker simultaneously) - All caches cleared (WordPress, hosting, CDN) - WordPress REST API accessible (not blocked by security plugin or firewall) - Site URL in OTTO matches your live WordPress URL exactly - Re-deployed changes after clearing caches 💬 Still Need Help? If you have followed all the steps above and the issue persists, our team is here to help. 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.

🔧 Fix Sitemap and Google PPC Data Sync Issues

Why Sitemap Data May Not Appear in Search Atlas Even when your sitemaps show a Success status in Google Search Console (GSC) and have been submitted for weeks, that data may not immediately appear in the sitemap section of Search Atlas. This is a known sync behaviour and does not mean your sitemaps are broken. Here is what causes the delay and what you can do about it: Understanding the Sync Delay Search Atlas pulls sitemap data from GSC via the API on a scheduled basis. This means: - Data displayed in Search Atlas reflects a snapshot from a previous sync cycle, not real-time GSC data. - Dates shown may appear stale because sitemap data is not refreshed in real time. - A sitemap showing Success in GSC does not guarantee that the indexing data has been processed and delivered to Search Atlas yet. This is expected behaviour during the current product cycle. Why Google PPC Data May Be Missing or Outdated If you notice that Google Ads data is not appearing in Search Atlas or seems out of date, the most common causes are: - Stale account sync: The platform may be displaying data from a previous sync without clearly indicating that a newer sync failed or is pending. - Manual changes not reflecting: Updates made directly in Google Ads (outside of Search Atlas) may take time to appear after a sync cycle completes. What to Do If Data Is Missing 1. Confirm that your Google Search Console connection is active and that your sitemap status shows Success in GSC. 2. Check whether updates made directly in Google Ads are reflected — if not, the sync cycle may still be in progress. 3. Note the specific ads, campaigns, or sitemaps affected and the approximate time the issue started. 4. Because there is no confirmed self-serve refresh option for sync issues of this type, escalate to the support team with the following information ready: your project or domain name, the affected ads or sitemap URLs, and the approximate time you first noticed the missing data. 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.

🔑 Fix Signal Genesys API Key Validation Errors

🔍 What Is This Error? When publishing a press release through Signal Genesys, you may encounter a 401 'API Token is invalid' error. This means the API key connected to your Signal Genesys account could not be authenticated. The press release will not publish until this is resolved. This error is generally caused by an issue with the API key configured for your Signal Genesys integration — for example, the key may have been entered incorrectly, regenerated in Signal Genesys without being updated in Search Atlas, or it may lack the necessary permissions. ⚙️ What to Check - Verify the API key in Signal Genesys: Log in to your Signal Genesys account and locate your API key in your account settings. If you are unsure where to find it, consult Signal Genesys's own documentation or support. - Update the key in Search Atlas: Once you have a valid API key from Signal Genesys, navigate to the Signal Genesys integration area within Search Atlas and replace the existing key with the new one. Save your changes. - Retry publishing: After updating the key, attempt to publish your press release again to confirm the error is resolved. - Check for typos or extra spaces: Always copy and paste your API key directly — never type it manually. Even a single extra space will cause a validation failure. - Confirm API permissions: Ensure the key you are using has the permissions required to publish press releases. If you are unsure, check your Signal Genesys account plan or contact Signal Genesys support to verify the key's scope. 🛠️ If the Error Persists If you have updated your API key and the 401 error continues, please reach out to our support team. To help us investigate quickly, have the following ready: - Your Search Atlas project name or workspace URL - The exact error message you are seeing (a screenshot is helpful) - The timestamp of the failed publish attempt - Confirmation of whether the API key was recently regenerated or changed in Signal Genesys 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.

🔧 Fix WordPress Reconnection Failures and Understand Credits

Overview Two common questions arise together: your WordPress site shows as disconnected in Search Atlas despite the plugin being active, and you want to understand how credits work across your account. This article explains what to expect and what information to have ready so our team can resolve both issues for you as quickly as possible. Why Your WordPress Site May Show as Disconnected A known issue can cause the Search Atlas dashboard to display an incorrect or outdated connection status for your WordPress site. The connector may show a disconnected state even after you have attempted to reconnect the plugin, or the status may not update as expected. Because this issue involves backend work, it typically requires a member of our team to investigate and correct the connection. Common symptoms include: - Your WordPress site appears disconnected in the dashboard even though the plugin is active. - Reconnection attempts do not resolve the displayed status. What to Have Ready When You Escalate Because resolving a WordPress reconnection failure requires a backend action by our team, please have the following information ready before reaching out: - Your site URL — the exact WordPress site address shown in your Search Atlas account. - Your Search Atlas account username or login. - A description of what you have already tried — for example, whether you have deactivated and reactivated the plugin in your WordPress admin panel. - Any error messages displayed — copy the exact wording of any error codes or status messages you see on screen. - Timestamps — when the disconnection was first noticed and when any reconnection attempts were made. How Credits Work in Search Atlas If you have questions about how your credits are managed within your account, our support team can review your specific account details and provide a clear breakdown. Please have your account login ready to share with our team when you reach out. 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.

🛠️ Fix Website Studio ws_bulk_send_message HTTP 403 Error

🔍 Overview If your ws_bulk_send_message MCP call is consistently returning an HTTP 403 error inside Website Studio — even when all other MCP calls are working correctly — you are likely experiencing a JWT authentication issue that affects how the bulk message tool connects to your project. This article explains what causes the error, how to identify it, and the steps to resolve it. ⚠️ What Triggers This Error The HTTP 403 error on ws_bulk_send_message is typically caused by one or more of the following: - Expired or invalid JWT token: The authentication token used by the MCP layer has expired or was not correctly passed to the bulk send endpoint. - Project-level permission mismatch: The MCP session credentials are not aligned with the specific Website Studio project you are targeting. - False failure reporting: In some cases, the message delivery may have actually succeeded, but the tool incorrectly reports a 403 failure due to a response-handling bug that has since been resolved. - Broken MCP tool initialisation: If create_project encountered an error earlier in your session, subsequent tools — including ws_bulk_send_message — can inherit a broken authentication state. ✅ How to Resolve the 403 Error 1. Refresh your MCP session. Log out of the Search Atlas platform completely, then log back in. This forces a new JWT token to be issued and clears any stale authentication state tied to your current session. 2. Re-open your Website Studio project. Navigate back to your project from the Website Studio dashboard rather than resuming from a cached or bookmarked URL. This ensures the MCP tools reinitialise with the correct project context and fresh credentials. 3. Retry the ws_bulk_send_message call. After re-entering the project, trigger the bulk send action again. In many cases, the 403 resolves immediately after the session is refreshed. 4. Verify the message was not already delivered. Due to the false-failure reporting bug (now resolved), your messages may have been sent successfully despite the 403 error appearing. Before re-sending, check your project's message history or the destination records to avoid duplicate updates. 5. Check for create_project errors earlier in your session. If you attempted to create a new project before the 403 appeared and received an error, start a new session entirely. A failed create_project call can corrupt the authentication context for all MCP tools that follow in the same session. 🔄 What Was Fixed on Our End Our engineering team has shipped several fixes related to this issue: - The JWT authentication flow for ws_bulk_send_message and other Website Studio MCP tools has been corrected to prevent token mismatch errors. - The create_project MCP tool, which was broken and contributing to downstream 403 failures, has been repaired. - False failure reporting on successful ws_bulk_send_message deliveries has been resolved — the tool now accurately reflects whether a message was sent. If you encountered this error before these fixes were deployed, refreshing your session as described above should be sufficient to restore full functionality. 🩺 Special Note for Healthcare and Data-Sensitive Projects If you are using Website Studio to manage critical records — such as physician profiles, patient-facing directories, or clinical data — we recommend confirming delivery success in your project's data view before re-triggering a bulk send. This prevents duplicate entries and ensures data integrity, particularly in cases where the 403 error was a false negative and the update had already been applied. 🚫 Common Mistakes to Avoid - Do not retry ws_bulk_send_message repeatedly in the same broken session. Multiple retries without refreshing the session will not resolve the 403 and may create duplicate processing attempts. - Do not assume data was not updated. As noted above, the error may have been cosmetic. Always check your records first. - Do not use a bookmarked deep link to re-enter a project after a session error. Always navigate from the main dashboard to ensure a clean initialisation. 💬 Still Seeing the Error? If you have followed all the steps above and the ws_bulk_send_message MCP call is still returning HTTP 403, our team can investigate your specific project and session 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.

🛠️ Fix Critical WordPress Plugin Issues Fast

🔍 Why Details Matter When Reporting Plugin Issues When a WordPress plugin stops working correctly, the speed of resolution depends almost entirely on the information you provide upfront. Vague reports such as "the plugin is broken" make it difficult for our team to diagnose the problem, which leads to longer back-and-forth exchanges and slower fixes. This article walks you through exactly what to capture and how to report it effectively. ⚠️ Common Signs of a Critical Plugin Issue Before reaching out, confirm you are experiencing one or more of the following: - The Search Atlas WordPress plugin fails to install, activate, or update - Data is not syncing between your WordPress site and the Search Atlas platform - The plugin causes a white screen, fatal error, or site crash after activation - Settings saved in the plugin are not being retained - The plugin dashboard is blank, missing data, or displays an error message - Conflict with another plugin or theme causes unexpected behavior 📋 Information to Gather Before Reporting Collecting the right details before you contact support dramatically reduces resolution time. Please have the following ready: 1. WordPress version: Found in your WordPress admin under Dashboard → Updates. 2. Search Atlas plugin version: Found under Plugins → Installed Plugins. Note the version number listed beneath the plugin name. 3. PHP version: Found under Tools → Site Health → Info → Server. 4. Exact error message: Copy the full text of any error or warning displayed on screen. Do not paraphrase — the exact wording matters. 5. Steps to reproduce: Write down the precise sequence of actions that trigger the issue (e.g., "I clicked Save Settings, then navigated to the Keyword Tracker tab, and the page went blank"). 6. When it started: Note the date and time the issue first appeared, and whether anything changed around that time (update, new plugin, hosting change). 7. Screenshots or screen recordings: Visual evidence helps our team see exactly what you are seeing. 8. Active plugins list: Go to Plugins → Installed Plugins and note which plugins are active. This helps identify conflicts. 9. Hosting environment: The name of your hosting provider (e.g., WP Engine, SiteGround, Cloudways). 🧪 Quick Troubleshooting Steps to Try First Before escalating, try these steps — they resolve the majority of plugin issues: 1. Deactivate and reactivate the plugin: Go to Plugins → Installed Plugins, deactivate Search Atlas, then reactivate it. 2. Update the plugin: Check for and install any available updates. 3. Clear your cache: Clear both your WordPress site cache and your browser cache, then reload the page. 4. Switch to a default theme: Temporarily switch to a default WordPress theme (e.g., Twenty Twenty-Four) to rule out a theme conflict. 5. Disable other plugins temporarily: Deactivate all plugins except Search Atlas to check for a plugin conflict. Reactivate them one by one to identify the culprit. 6. Check Site Health: Go to Tools → Site Health and review any critical issues flagged by WordPress. 🚀 How to Escalate Effectively If the steps above do not resolve the issue, escalate immediately — but come prepared. When you open a support conversation, include everything from the checklist in the section above. The more specific you are, the faster our team can act. A report that says "After updating to plugin version 3.2.1 on WordPress 6.5, clicking the Sync button on the Content Planner page returns a 500 Internal Server Error. This started on June 10 and my host is WP Engine." will be prioritised and resolved far more quickly than a general report of something being broken. ⏱️ Understanding Escalation Timeouts Our support team follows up on open issues within a set window. If a conversation is escalated as critical but no specific details are provided, the ticket may time out while our team waits for the information needed to investigate. To prevent this: - Respond promptly to any follow-up questions from our team - Include all required details in your very first message - Mark your issue as critical only when it is causing site downtime or complete loss of plugin functionality If your ticket has timed out and your issue is still unresolved, please reopen a conversation and include the full details outlined above. 💬 Contact Support 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.

🛠️ MetaSync/OTTO Plugin CPU Exhaustion Incident Guide

🔍 Overview In some cases, the Search Atlas MetaSync/OTTO WordPress plugin has been identified as the source of abnormal server load — causing CPU exhaustion and, in some cases, the website going offline. This article explains what to do if you experience this issue and how to escalate it to our team. ⚠️ What Causes This Issue The MetaSync/OTTO WordPress plugin can, under certain conditions, generate abnormal server load that exhausts a server's CPU allocation. Hosting providers such as SiteGround may detect this and disable the plugin automatically to protect your server. Our engineering team is aware of this class of issue and investigates each report. 🚨 If Your Site Was Taken Offline If your hosting provider has flagged the MetaSync/OTTO plugin as the cause of CPU exhaustion or has disabled it to protect your server, follow these steps: 1. Do not re-enable the plugin until you have confirmed with our support team that it is safe to do so on your account. 2. Note any reference numbers provided by your hosting provider (incident IDs, case numbers, or support tickets). You will need these when contacting us. 3. Check your plugin version in your WordPress dashboard and have that version number ready to share with our support team. 4. Contact Search Atlas support via the chat widget (see below) so our team can investigate your specific case and confirm when it is safe to re-enable the plugin. 📋 What to Have Ready When You Escalate To help our team resolve your case as quickly as possible, please have the following information ready: - Your Search Atlas project name or workspace URL - The domain of the affected WordPress site - Your current MetaSync/OTTO plugin version number - Any incident IDs, case numbers, or error messages provided by your hosting provider - The approximate date and time the issue began 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.

🔌 Fix WordPress Plugin Disconnection and Deployment Sync Failures

🔍 Overview If your Search Atlas WordPress plugin icon is showing red, or your OTTO SEO deployments are not saving or persisting to your WordPress site, this guide walks you through the most common causes and how to fix them quickly. ⚠️ Why Is the WordPress Plugin Showing Red? A red plugin status means Search Atlas has lost its authenticated connection to your WordPress site. This is usually caused by one of the following: - A WordPress core, plugin, or theme update that reset REST API permissions - A security plugin (such as Wordfence or iThemes Security) blocking the Search Atlas REST API route - A hosting-level firewall or CDN rule interfering with authentication requests - An expired or revoked application password on the WordPress side - A caching layer serving stale authentication responses 🛠️ How to Reconnect the WordPress Plugin 1. Log in to your Search Atlas account and navigate to Settings > Integrations > WordPress. 2. Locate the disconnected site. You will see a red indicator next to the connector. 3. Click Reconnect and follow the on-screen authentication prompts. 4. When redirected to your WordPress admin, confirm that the Search Atlas application password is active under Users > Your Profile > Application Passwords. If you see an old or duplicate entry, revoke it and allow Search Atlas to generate a new one. 5. Return to Search Atlas and verify the connector status has changed to green (connected). 6. If the status still shows red after reconnecting, clear any full-page or object caches on your WordPress site (via your caching plugin or hosting control panel) and attempt reconnection again. Tip: If you use a security plugin, temporarily disable it during reconnection and then add the Search Atlas REST API route (/wp-json/search-atlas/) to the allowlist before re-enabling it. 💾 Why Won't My Deployment Save or Persist? Even after a successful reconnection, some customers find that OTTO SEO deployments — such as Knowledge Based Trust and Factual Enhancement optimisations — appear to save in the platform but do not persist on the live WordPress site. This is a sync issue between Search Atlas and your CMS. Common reasons this happens include: - The WordPress connector was reconnected but the CMS sync was not re-enabled for the project - A REST API route error prevented the deployment payload from being written to WordPress - A caching or CDN layer returned a cached version of the page, making it appear the changes were not applied - The WordPress user account linked to the connector has insufficient permissions (must be Administrator role) ✅ How to Fix Deployment Sync Failures 1. Confirm your WordPress connector is showing green in Settings > Integrations > WordPress. If it is not, complete the reconnection steps above first. 2. In Search Atlas, open your OTTO SEO project and navigate to the deployment in question (e.g., Knowledge Based Trust and Factual Enhancement Issues). 3. Check that CMS Sync is toggled on for the project. If this setting was off, enable it and re-deploy. 4. Click Deploy again. Wait at least 60 seconds before checking your live site, as sync operations can take a short time to propagate. 5. Purge all caches on your WordPress site — including page cache, object cache, and any CDN cache — then reload the page to confirm the changes are live. 6. Verify the WordPress account used in the connector has Administrator privileges. Go to WordPress Admin > Users and confirm the role assigned to the connected account. 7. If you still see a wp_client_error in the platform after following these steps, check your hosting provider's error logs for blocked REST API requests and whitelist the Search Atlas IP range if required. 🚫 Common Mistakes to Avoid - Do not revoke the Search Atlas application password manually unless you intend to fully reconnect — doing so will immediately break the sync. - Do not assume a green connector status means sync is active. Always verify the CMS Sync toggle is enabled at the project level. - Do not check for deployed changes before clearing your cache — cached pages will always show the old content. 💬 Still Need Help? If you have followed all of the steps above and the plugin is still disconnected or deployments are still not persisting, 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.

🛠️ Wix Integration: Image Metadata, Titles & Alt-Text Defects

🔍 Overview of the Issue A confirmed defect affects Search Atlas customers who publish content directly to Wix sites via the platform integration. The three specific symptoms are: - Image metadata loss: Image file names, captions, or embedded metadata are stripped or reset during publication. - Title mutation: Page or post titles are altered from the intended value after being pushed to Wix. - Alt-text rewrite: Custom alt-text applied inside Search Atlas is overwritten or removed when content lands in Wix. These issues have been confirmed through internal reproduction testing and are being actively tracked by our engineering team. 📋 What Has Been Done So Far This defect has been escalated internally and is being investigated at the engineering level. Here is the current status: - The issue has been reproduced internally using controlled publication tests that mirror real customer publishing conditions. - Engineering has access to the evidence gathered from escalated customer conversations, including affected site configurations and publishing sequences. - A cold-load test (simulating a fresh Wix page load post-publish) and a controlled publication test are being used as the benchmark for confirming a fix. - The case will not be closed until both independent cold-load and controlled publication tests confirm full resolution. ⚠️ What This Means for Your Workflow Until a fix is confirmed and released, we recommend the following workarounds to protect your content quality when publishing to Wix: 1. Do not rely on Search Atlas to push final alt-text to Wix. After publishing, log in to your Wix editor and manually verify and re-enter alt-text for all images. 2. Copy your intended page title before publishing. After the post goes live on Wix, confirm the title matches your original and correct it manually if needed. 3. Check image metadata in Wix directly. Navigate to each published image in your Wix Media Manager and confirm that file names and any required metadata fields are intact. 4. Keep a local record of your intended titles, alt-text, and image metadata before each publishing session so you have a reference if corrections are needed. 🚀 How to Request an Active Ticket Reference or Case Status If you were previously involved in an escalation related to this defect, or if you need a current engineering ticket reference and case owner status, our support team can retrieve this for you in real time. To request this information: 1. Open the Search Atlas platform and locate the chat widget in the bottom-right corner. 2. Type human teammate to be connected with a member of our support team. 3. Share your site URL and a brief description of the symptom you experienced (title mutation, alt-text rewrite, or image metadata loss). 4. Request the active ticket reference number and the current engineering case owner and status. Our team will confirm whether your previous case is linked to the tracked defect and provide you with the latest status update. 📊 How We Will Communicate a Fix When engineering confirms that the fix has passed both the cold-load test and the controlled publication test, we will: - Update this article with a confirmed resolution date and any steps you may need to take on your end. - Proactively notify customers who were part of escalated conversations related to this defect. You do not need to reopen a ticket or submit a new report if you have already been involved in an escalation — your case remains open and linked to the active engineering investigation. 💡 Tips While You Wait for the Fix - Use the Onpage Audit tool (Left sidebar → Content → Onpage Audit) to audit your published pages and catch any metadata or title discrepancies after each Wix publication. - If you are generating content before publishing, use Content Genius (Left sidebar → Content → Content Genius) and save a copy of all title and alt-text fields locally before pushing to Wix. - Avoid bulk-publishing to Wix until the fix is confirmed, as the defect has a higher chance of appearing when multiple pages are pushed in a single session. 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.

🛠️ Fix Search Atlas Script Conflicts With Prerender via GTM

🔍 Understanding the Conflict When you install the Search Atlas tracking script through Google Tag Manager (GTM) on a site that uses a prerender service (such as Prerender.io or a similar solution), the script can interfere with how the prerender service processes and caches pages. This typically results in two symptoms: - The Search Atlas plugin fails to verify the script installation. - The site behaves unexpectedly or breaks for certain users or bots. This happens because prerender services intercept requests from crawlers and serve a pre-rendered static version of the page. If GTM fires the Search Atlas script during this render cycle, it can disrupt the prerender output or cause the verification check to receive an incomplete page response. ⚙️ How Prerender Services Work With GTM Prerender services detect bot or crawler user agents and serve them a cached, JavaScript-free HTML snapshot of the page instead of the live version. GTM and any tags it loads — including the Search Atlas script — are typically JavaScript-based. This means: - The Search Atlas script may not execute at all in the prerendered snapshot. - The verification check, which looks for the script on the live page, may query a cached snapshot that does not include the script. - GTM itself may be stripped or blocked during the prerender process, preventing the tag from firing. ✅ Recommended Fix: Exclude the Search Atlas Script From Prerender Caching The most reliable solution is to ensure your prerender service does not interfere with the page when the Search Atlas verification check runs, and to configure GTM so the script loads correctly for real users. Follow these steps: 1. Add the Search Atlas script directly to the page source (recommended). Instead of loading the script through GTM, paste it directly into the <head> section of your site's HTML template. This ensures it is always present in the page source, regardless of how the prerender service handles JavaScript. 2. Whitelist the script in your prerender configuration. If you must keep the script in GTM, log in to your prerender service dashboard and add a rule to exclude or pass through requests that include the Search Atlas verification user agent or the specific URL used for verification checks. Refer to your prerender provider's documentation for exact steps. 3. Configure GTM to fire on all environments. Check your GTM container's trigger settings to confirm the Search Atlas tag is not restricted to specific environments or conditions that would prevent it from firing during a verification request. 4. Re-run the plugin verification in Search Atlas. Once the script is in place and the prerender conflict is resolved, return to your Search Atlas workspace and trigger the verification check again to confirm the installation is recognised. 🧪 Testing Your Setup Before re-running the official verification, test the fix manually to save time: - Open your browser's developer tools, go to the Network tab, and reload the page. Search for the Search Atlas script to confirm it loads in the page source. - Use a tool such as Google's Rich Results Test or a user-agent switcher to simulate a crawler request to your page. Check whether the script appears in the rendered output. - Clear your prerender cache after making changes so the service regenerates snapshots with the updated page source. 💡 Additional Tips - If your prerender service uses a cache TTL (time to live), wait for the cache to expire or manually purge it before re-testing. - Some prerender services allow you to block specific JavaScript files from executing during render. Make sure the Search Atlas script domain is not on that blocklist. - If you manage multiple client sites with this setup, apply the direct-to-source installation method as your default to avoid this conflict across all properties. 💬 Still Need Help? If you have followed the steps above and the plugin still fails to verify, or if your site continues to break after making these changes, our technical team can investigate your specific configuration. 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.

🔌 Fixing ChatGPT MCP Action Discovery Failure

You connect Search Atlas to ChatGPT using MCP, sign in successfully, and then see Authentication succeeded, action discovery failed. No tools appear. This article explains what the message means and how to fix it. 🔍 What This Error Means The message has two parts. Authentication succeeded means your Search Atlas login and permission approval worked. Action discovery failed means ChatGPT signed in but could not load the list of available tools (actions) from the MCP server. Your account is usually fine. The problem is typically in how the connector is set up, or in the session ChatGPT saved while connecting. ⚡ About the Lite Endpoint Search Atlas offers a Lite MCP endpoint. It is meant for clients that work better with a smaller, simpler set of tools. If ChatGPT struggles to load a large tool list, the Lite endpoint can be a good option. - The Lite endpoint has its own address. It is not interchangeable with the standard endpoint. - Sign-in can work against either address, so a wrong or mismatched address may only show up at the discovery step. - Always copy the address from your Search Atlas MCP settings instead of typing it from memory. 🧭 Common Causes - The server address was copied with a typo, a missing part, or a trailing space. - An older connector attempt left behind a saved session that no longer matches. - The permission screen was closed early, or not every requested permission was approved. - You signed in to a different Search Atlas account than the one you meant to use. - A pop-up blocker, browser extension, or privacy setting interrupted the sign-in handoff. - Your ChatGPT plan or workspace does not currently allow custom connectors, or the required developer option is turned off. - The tool list did not load in time, and a retry is needed. 🛠️ Step-by-Step Fix 1. Check the address. Open your Search Atlas MCP settings and copy the Lite endpoint address again. Paste it into the connector without extra spaces or characters. 2. Delete the failed connector. In ChatGPT, open your connector settings and remove the connection that shows the error. Do not just retry on top of it. 3. Confirm your Search Atlas login. Open Search Atlas in the same browser and check that you are signed in to the correct account and workspace. 4. Prepare your browser. Allow pop-ups for ChatGPT, or use a private window with extensions turned off. 5. Create the connector again. Add a new connector with the Lite endpoint address and choose OAuth when asked for the authentication method. 6. Approve everything. On the permission screen, review and approve the requested access, then wait until you are returned to ChatGPT. 7. Refresh the tools. If the connector shows no tools, use the refresh option in the connector settings and wait a few seconds. 8. Start a new chat. Enable the connector for that chat and ask ChatGPT to list the Search Atlas tools it can use. ✅ How to Confirm It Worked - The connector shows a list of tools instead of an error. - ChatGPT can name some Search Atlas actions when you ask what it can do. - A simple request, such as asking for information about one of your projects, returns a result. 💡 Tips to Avoid the Error - Use one connector per endpoint. Do not reuse a connector created for the standard endpoint when you want the Lite one. - If you change accounts or workspaces in Search Atlas, remove and recreate the connector. - Do not close the permission window until you are redirected back. - If the tools fail to load once, delete and recreate the connector instead of retrying several times. 📝 What to Share If the Problem Continues If the steps above did not help, gather these details so our team can resolve it faster: - A screenshot of the error message in ChatGPT. - The endpoint address you used (the address only, never passwords or tokens). - Your ChatGPT plan type and whether you use a personal or team workspace. - The approximate time of your last attempt and your browser name. - The steps you already tried from this article. 💬 Need More Help? If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.

🔧 Fix Signal Genesys External API 403 Scope Errors

Overview If every request you send to the Signal Genesys External API returns an HTTP 403 – Invalid scope provided error, your API token may be missing one or more required permission scopes. This article explains what causes the error and what to have ready when contacting our team to resolve it. What Causes the 403 'Invalid Scope' Error? A 403 scope error means your bearer token was authenticated successfully, but it does not have permission to perform the action you requested. Common reasons include: - The token was generated without the necessary permission scopes for the External API feature you are trying to use. - Your token was created with a limited scope configuration that excludes certain External API features. - Your plan tier may not include External API access, so the platform blocks those scopes entirely. - The token has expired or been rotated and the updated token was not saved in your integration. What to Do Because resolving a 403 scope error on the Signal Genesys External API requires backend verification of your token permissions and plan entitlements, our support team will need to investigate on your behalf. To help us resolve this as quickly as possible, please have the following ready before reaching out: - Your Search Atlas account email address - The exact 403 error message you are receiving - The specific API endpoint or action you are attempting to call - The date and time (with timezone) when the error first occurred - Your current plan or subscription tier, if known Do not share your full bearer token when contacting support — our team can look up your token configuration securely on the backend. 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.

🔌 Fix OTTO Pixel Not Detected on Dealer.com Sites

🧭 Overview If your OTTO Pixel shows a Not Installed status on a site hosted on the Dealer.com CMS, this is a known integration issue. Unlike most platforms, Dealer.com sites can cause the OTTO Pixel to silently disconnect after initial setup — even when the pixel code appears to be present on the site. Clearing cache or verifying the installation method will not resolve this issue. The only confirmed fix is to delete the existing pixel and reinstall it from scratch using the steps below. ⚠️ Why This Happens Dealer.com's CMS manages third-party scripts in a way that can break the connection between Search Atlas and an installed OTTO Pixel over time. When this disconnection occurs, Search Atlas can no longer verify the pixel's presence — even if the script tag is still visible in the site's source code. This causes the pixel status to display as Not Installed inside the platform. This behaviour is specific to Dealer.com-hosted sites and is not caused by browser caching, bot-blocking settings, or incorrect installation methods. ✅ How to Fix It — Delete and Reinstall the Pixel 1. In the left sidebar, click OTTO SEO → All Sites (SEO Automation) (URL: /seo-automation-v3) to open your OTTO dashboard. 2. Locate the affected site — in this example, www.polestarfortlauderdale.com — and open its OTTO settings. 3. Find the existing OTTO Pixel entry for this site and delete it. Do not attempt to re-save or update the existing pixel — it must be fully removed. 4. Once deleted, generate a new OTTO Pixel for the same site from within the OTTO SEO section. 5. Copy the new pixel script provided by Search Atlas. 6. Log in to your Dealer.com account and navigate to the section where third-party scripts or tracking codes are managed (typically under Site Settings or Integrations). 7. Remove any previously installed OTTO Pixel script from Dealer.com. 8. Paste the new pixel script into Dealer.com and save your changes. 9. Return to Search Atlas and allow time for the pixel status to update to Installed. Automatic checks run every 15 minutes for projects under 2 hours old, hourly from 2–24 hours, every 6 hours from 1–7 days, and stop after 7 days. 🔍 How to Confirm the Fix Worked - After the next automatic check, return to OTTO SEO → All Sites (SEO Automation) in the left sidebar and check the pixel status for your site. - The status should now display as Installed. - If you want to verify the pixel is firing independently, use a browser extension such as Google Tag Assistant or inspect the page source to confirm the new script is present. 🚫 What Not to Try on Dealer.com Sites The following steps are standard pixel troubleshooting actions that will not resolve this specific Dealer.com disconnection issue: - Clearing browser or server-side cache - Switching between manual and tag-manager installation methods - Checking or adjusting bot-access or crawler settings - Re-saving the existing pixel without deleting it first If you apply any of the above steps without completing the full delete-and-reinstall process, the pixel will continue to show as Not Installed. 📋 Quick Reference — Dealer.com Pixel Fix - Affected platform: Dealer.com CMS - Symptom: OTTO Pixel status shows Not Installed despite pixel code being present - Root cause: Dealer.com script handling causes pixel disconnection after installation - Resolution: Delete existing pixel in Search Atlas, generate a new one, reinstall in Dealer.com - Time to verify: Depends on project age — every 15 minutes (under 2 hours old), hourly (2–24 hours), every 6 hours (1–7 days), no automatic checks after 7 days 💬 Still Need Help? If you have completed the delete-and-reinstall process and the pixel still shows as Not Installed after the expected check interval for your project's age, or if you need guidance navigating Dealer.com's script management interface, 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.

🔄 Fix WordPress CMS Sync Toggle Errors

🔍 Overview When connecting your WordPress site to Search Atlas via the CMS sync toggle, you may encounter a stuck loading circle, a "No WP website found" error, or a generic sync failure. This article walks you through the most common causes and how to resolve them step by step. ⚙️ Prerequisites Before You Begin The CMS sync feature only works with WordPress sites that have the official Search Atlas WordPress plugin installed and activated. Before troubleshooting, confirm the following: - The Search Atlas WordPress plugin is installed and active on your WordPress site. - The domain you are trying to sync exactly matches the domain registered in your Search Atlas project (including or excluding www). - Your WordPress site is publicly reachable and not in maintenance mode, staging lockdown, or behind a firewall that blocks external API requests. 🛠️ Step 1 — Verify the Plugin Is Installed Correctly 1. Log in to your WordPress admin dashboard. 2. Go to Plugins → Installed Plugins. 3. Confirm the Search Atlas plugin is listed and its status shows Active. 4. If the plugin is deactivated, click Activate and wait 30 seconds before retrying the sync in Search Atlas. 5. If the plugin is not installed, download it from your Search Atlas account, upload it via Plugins → Add New → Upload Plugin, and activate it. 🔗 Step 2 — Check Your Project Domain Matches 1. In Search Atlas, navigate to your project settings and note the exact domain listed (e.g., hoardrescue.com vs. www.hoardrescue.com). 2. Compare this to the domain shown in your WordPress admin under Settings → General → Site Address (URL). 3. If there is a mismatch, update the domain in your Search Atlas project to match WordPress exactly, or adjust the WordPress site URL accordingly. 😴 Step 3 — Reactivate a Sleeping Project If your Search Atlas project has been inactive for an extended period, it may have been put to sleep automatically. A sleeping project cannot complete a CMS sync and will return a generic error or leave the toggle stuck on loading. 1. Open Search Atlas and go to the Home page via the left sidebar. 2. Locate your project and click Refresh data to wake it. 3. Wait up to two minutes for the project to fully reload. 4. Return to the CMS sync toggle and try again. 🔄 Step 4 — Retry the CMS Sync Toggle 1. Navigate to your project in Search Atlas. 2. Locate the Sync to CMS toggle. 3. If the toggle is stuck on a loading circle, refresh the entire page using your browser (do not just click the toggle again). 4. After the page reloads, click the toggle once and wait up to 60 seconds for the connection to establish. 5. A successful sync will turn the toggle green and display a confirmation message. 🚫 Common Error Messages and What They Mean - "No WP website found" — Search Atlas cannot detect the plugin on your domain. Re-check that the plugin is active and the domain matches exactly. - Generic sync error / no message shown — This is often caused by a sleeping project or a temporary server timeout. Follow Step 3 to wake your project, then retry. - Toggle spins indefinitely — A page refresh usually resolves this. If it persists after refreshing and retrying, the issue may require investigation by our team. ✅ Quick Checklist - Search Atlas plugin installed and active in WordPress - Domain in Search Atlas project exactly matches WordPress site URL - WordPress site is publicly accessible (not in maintenance or staging mode) - Project is not sleeping — refresh data if unsure - Page was refreshed before retrying the toggle 💬 Still Having Trouble? If you have completed all the steps above and the sync toggle is still failing or stuck, our team can investigate your specific domain and project configuration. 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.

⚠️ Fixing Anthropic 503 Provider Access Error

🔍 What This Error Means When you see API Error: 503 [provider_access_absent], it means Search Atlas's AI gateway was temporarily unable to route your request to Anthropic's servers. The error message may say "retrying will not help" or suggest you need to request access — in most cases, neither is true. This is almost always a short-lived routing issue between Search Atlas and Anthropic's infrastructure, not a problem with your account or subscription. 🛠️ Why This Error Occurs - Temporary capacity constraints: Anthropic's infrastructure occasionally limits availability during high-demand periods, which can cause the gateway to report a failed connection. - Model-level restrictions: A specific AI model may be temporarily unavailable while others remain fully accessible. The error message can make this look like a broader access problem — but it usually is not. - Gateway routing delay: Search Atlas's AI gateway may briefly lose its path to Anthropic's API pool before recovering automatically within seconds or minutes. ✅ How to Fix It — Step by Step 1. Wait 1–2 minutes, then retry. The majority of these errors resolve on their own. Refresh the page and try your action again before doing anything else. 2. Switch your AI model to Atlas Fusion. If the error appears again, change the model to atlas-fusion using the model selector before generating content. Atlas Fusion uses a separate provider pool and is unaffected by Anthropic-specific outages — it is the fastest way to keep working without interruption. 3. Try a different content action. In Content Genius (left sidebar → Content → Content Genius), you can switch modes. For example, try Write it yourself or Rework existing article if the error appeared during a different generation flow. 4. Check Anthropic's status page. If you suspect a wider outage, visit status.claude.com to see if Anthropic is reporting any active incidents that may be affecting availability. 📋 A Note on the Error Message Wording The phrasing in this error — "retrying will not help" and "ask an operator for Anthropic access" — can be alarming, but it is often misleading. This wording was intended for a very specific edge case (a permanently blocked API key), but it can surface during temporary routing failures that have nothing to do with your account's access level. You do not need to request new permissions or contact Anthropic. If switching to atlas-fusion resolves the issue, your account is fully functional and the problem was on the provider side. 🔄 Running Bulk Content Jobs? If this error appears during a Write with AI in Bulk session, pause the batch immediately rather than retrying rapidly. Wait 60–120 seconds to allow the gateway to re-establish its connection, then resume. Rapid successive retries during an outage window can queue up failed requests and slow recovery. 💡 Best Practices to Minimise Disruptions - Keep atlas-fusion available as a backup model when working on time-sensitive content or large bulk runs. - Wait at least 60 seconds between retry attempts — this gives the AI gateway time to recover its routing path. - If the same error recurs across multiple sessions on the same day, note the time and model you were using before contacting support — this helps our team investigate faster. 🆘 Still Seeing the Error? If the error persists after switching to atlas-fusion and waiting a few minutes, our team can look into the specific instance ID shown in your error message. 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.

🔧 Fix Shopify CMS Connector Authentication Errors

Overview The Shopify CMS Connector in Search Atlas can experience authentication failures when connecting Shopify for use with Content Genius. These failures are typically related to OAuth or Client Credentials authentication methods. Common Authentication Errors When connecting Shopify to Search Atlas, authentication may fail due to issues with either the OAuth flow or the Client Credentials (legacy token) method. These are backend-side connection issues that require investigation by our engineering team. What to Expect If your Shopify CMS Connector is failing to authenticate, the issue is likely occurring on the backend during the connection handshake between Search Atlas and Shopify. This is not something that can typically be resolved through the UI alone, and may require our team to review logs and connection state. Information to Have Ready When Escalating To help our team diagnose and resolve the issue quickly, please have the following details available: - Your Search Atlas project name - Your Shopify store URL (e.g., your-store-name.myshopify.com) - The exact error message you see when the authentication fails - The authentication method you are attempting to use (OAuth or Client Credentials) - The approximate timestamp of when the error occurred Next Steps Once you have the above information ready, escalate to our team so we can investigate the backend connection and resolve the authentication failure. 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.

🔑 Fix Service Account Provisioning for Instant Indexing

🧭 Overview Instant Indexing in Search Atlas uses a dedicated Google service account to submit URLs directly to Google's Indexing API. Before any URLs can be submitted, that service account must be granted Owner-level access inside Google Search Console (GSC). Until ownership is confirmed, the Has Access flag in your Search Atlas dashboard remains False and no indexing requests will process. Two common approaches fail to satisfy this requirement: the OTTO auto-provisioning flow and the WordPress plugin method. Both are blocked because Google does not allow service account email addresses to claim GSC ownership through automated requests alone. Ownership must be explicitly delegated by a verified human owner inside GSC. The only supported path is the provisioning flow built into the Search Atlas dashboard, paired with a manual ownership grant in GSC. ⚠️ Why Auto-Provisioning and the WP Plugin Fail Understanding why these approaches are rejected saves time before you begin the correct process. - OTTO auto-provisioning: OTTO generates a service account and attempts to register it automatically. Google's Indexing API requires the service account to hold Owner permission in GSC — a level that Google restricts to manual grants by an existing verified owner. Automated registration requests are rejected at Google's end, so ownership is never confirmed regardless of how many times the flow runs. - WordPress plugin approach: The WP plugin authenticates at the site level but cannot elevate a service account to Owner in GSC. Plugin-level credentials carry Full User permission at best, which is insufficient for the Indexing API. Google silently ignores indexing submissions from accounts below Owner level. - Google Cloud Console only: Creating or downloading a service account key directly from Google Cloud Console without linking it through the Search Atlas dashboard means the platform never registers the account. The Has Access flag is set by Search Atlas after verifying the ownership grant, so bypassing the dashboard leaves it permanently False. ✅ What the Has Access Flag Actually Means The Has Access flag is a status indicator inside the Search Atlas dashboard. It reflects whether the service account attached to your property has been verified as an Owner in GSC and is ready to submit indexing requests. - False: The service account exists but Google has not confirmed Owner-level permission. No URLs will be submitted. - True: Search Atlas has verified that the service account holds Owner permission in GSC. Instant Indexing submissions are active. The flag flips to True only after you complete both steps: provisioning the service account through the Search Atlas dashboard and manually granting that service account Owner-level permission inside GSC as a verified human owner. 🛠️ How to Correctly Set Up Instant Indexing 1. Navigate to Authority → Indexer (URL Indexer) in your Search Atlas dashboard and use the built-in provisioning flow to generate your dedicated service account. 2. Copy the service account email address provided by the dashboard. 3. Log in to Google Search Console with an account that already holds Owner verification for your property. 4. Go to Settings > Users and permissions and add the copied service account email as an Owner. 5. Return to your Search Atlas dashboard. Once Google confirms the ownership grant, the Has Access flag will update to True and Instant Indexing submissions will become active. 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.

🛠️ Fix Shopify CMS Connector OAuth 400 Errors

🔍 Overview Some customers have encountered a 400 Bad Request error when connecting their Shopify store to Search Atlas via the CMS Connector. This error typically appears during the OAuth or Client Credentials authentication step and can prevent Autopilot and Content Genius auto-publishing from functioning. This article explains what to have ready when escalating this issue to our support team so it can be resolved as quickly as possible. ⚠️ Why This Error Happens A 400 error during Shopify CMS Connector authentication indicates a failure in the token exchange or credential validation process between Search Atlas and Shopify's API. This type of issue requires investigation by our backend team, as the root cause can vary depending on your specific store and integration configuration. 🔧 What to Have Ready When Escalating Because resolving this error requires action on our backend, please have the following information ready before contacting support so our team can investigate and fix the issue promptly: - Your Search Atlas project name or workspace URL - The exact error message you are seeing (e.g. the full 400 error text or any additional error code displayed) - The timestamp of when the error first occurred or most recently occurred - Whether you are using OAuth or Client Credentials as your authentication method - Any recent changes to your Shopify store or app settings that preceded the error 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.

🏛️ Fix Brand Vault Setup Stuck on Refresh

🔍 What This Article Covers Some customers find that Brand Vault stays on a "Setting up" or "Refreshing" status long after the process should have finished. In some cases, the suggested fix task list references the wrong website entirely. This article explains why this happens and the steps to resolve it. ⚠️ Why This Happens Brand Vault setup can appear stuck for a few common reasons: - A previous crawl attempt failed silently in the background, and the system is still holding onto that failed state. - The refresh process took longer than expected — in some cases it can take up to 45 minutes to complete or time out. - A failed refresh caused page and word counts to drop to zero without displaying a clear error message. - The setup was linked to a different domain, so suggested fixes appear to belong to the wrong website. 🛠️ Step-by-Step Fixes 1. Wait and confirm the timeout window. Brand Vault refresh can take up to 45 minutes. If setup started recently, allow the full window before taking further action. A failure is typically declared after this period. 2. Manually trigger a refresh. Navigate to Left sidebar → Coworker → Overview and click Refresh setup status. This forces the platform to check the current state and may resolve a stuck display. 3. Check you are on the correct workspace and domain. If the suggested task list references the wrong website, you may be viewing a different workspace. Use Switch workspace from the Coworker Overview page to confirm you are in the right one, then refresh again. 4. Re-initiate Brand Vault setup. If the status remains stuck after refreshing: - Go to Left sidebar → Coworker → Overview. - Look for an option to recreate or restart the Brand Vault. - Confirm the correct domain is selected before saving. A previous failed crawl can be reused by the system — selecting the correct domain explicitly prevents this. 5. Clear your browser cache and reload. Sometimes the stuck state is a display issue only. Clear your cache, close the tab, and reopen the platform before checking the Brand Vault status again. 6. Verify page and word counts. After setup completes, confirm that page and word counts in Brand Vault are populated with real numbers. A count of zero after a refresh indicates the crawl did not complete successfully and setup should be re-initiated. ✅ How to Confirm Brand Vault Is Working Brand Vault setup is fully complete when: - The status no longer shows "Setting up" or "Refreshing". - Page and word counts display real, non-zero values. - The Ask-your-Vault feature is accessible and responding correctly. - Suggested fixes and task lists reference your correct website and domain. 💡 Tips to Prevent This Issue - Always double-check the domain selected when first creating your Brand Vault — using the wrong domain is the most common cause of mismatched task lists. - Avoid triggering multiple refresh attempts in quick succession. Allow each refresh the full 45-minute window before retrying. - If you manage multiple client sites, use Switch workspace to confirm you are in the correct workspace before reviewing Brand Vault data. 🙋 Still Need Help? If you have followed all the steps above and Brand Vault is still stuck or showing incorrect information, our team can investigate the crawl status on your account directly. 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.

🛠️ Fix API 404 Errors Fetching Published Content

🔍 Overview If you are calling the Search Atlas API to retrieve published content and receiving a 404 error, you are not alone. This error can appear even when your published articles are clearly visible inside the Search Atlas platform. This article explains what to have ready when escalating this issue to our support team. ⚙️ What This Error Means A 404 response when retrieving published content via the Search Atlas API indicates that the server could not locate the requested resource at the time of the call. Because the root cause requires investigation on the backend, our support team will need to look into your specific account and request details to identify what went wrong. 🚀 What to Do This issue requires backend investigation by our support team. To help us resolve it as quickly as possible, please have the following information ready before reaching out: - The exact API endpoint URL you are calling, copied directly from your integration or logs. - The full error response you are receiving, including any response body or headers. - The name of the workspace or project where the published content is located. - The timestamp of when the 404 error occurred (date and time, including timezone). - Confirmation of the content status — whether the affected content is confirmed as fully published inside the platform at the time of the error. 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.

🛠️ Troubleshoot OTTO WordPress Connections

🔍 Check the connection status Start in OTTO SEO from the left sidebar, then open Installation Guide. Confirm that the WordPress site is connected to the correct Search Atlas project and that OTTO shows an active installation. If you manage several sites, open each affected project separately. A connection can succeed on one site while another has different WordPress permissions, plugins, caching, or configuration. ⚙️ Verify the WordPress setup 1. Confirm that the WordPress site is live and accessible without a maintenance or password-protection page. 2. Log in with an account that has administrator permissions. 3. Confirm the OTTO plugin is installed and activated on the intended WordPress site. 4. Make sure the site URL in WordPress matches the site added to Search Atlas, including HTTPS and the correct domain version. 5. Temporarily disable security, firewall, or maintenance settings that may block plugin requests, then test the connection again. 🔑 Refresh authentication If the connection remains unresolved, return to OTTO SEO → Installation Guide and restart the connection process. Use the current installation details generated for that project rather than reusing an older API key or setup link. Do not connect the same WordPress installation to a different project unless that is intentional. An old connection, API key, or project identifier can cause OTTO to appear installed while data is linked to another project. 🔄 Resolve syncing and caching issues - Clear WordPress, hosting, CDN, and browser caches. - Check whether a security plugin or hosting firewall is blocking REST API requests or outgoing connections. - Confirm that WordPress can communicate with external services and that the server is not blocking plugin requests. - Update WordPress and the OTTO plugin when updates are available. - After making changes, wait a few minutes and refresh the Installation Guide before testing again. 🧩 Check project and site matching When OTTO reports an unexpected installation state, verify that the WordPress site is connected to the intended Search Atlas project. This is especially important when projects were duplicated, renamed, migrated, or connected more than once. Review the affected project in Site Metrics from the left sidebar and confirm that the domain and project details match the WordPress site. Avoid repeatedly reinstalling OTTO until the project match is confirmed. 🚫 If the connection still fails 1. Disconnect or deactivate the existing OTTO installation only if the Installation Guide provides that option. 2. Remove obsolete OTTO plugin connections from the affected WordPress site. 3. Clear caches and reconnect using the Installation Guide for the correct project. 4. Test the site in an incognito browser window and confirm the OTTO status again. If several sites work but one or two do not, compare the affected sites with a working site. Focus on differences in WordPress administrator access, domain format, security plugins, hosting, caching, and project assignment. 💬 Get help from our team Before contacting support, note the affected project, WordPress site URL, connection status, recent changes, and any error message. Screenshots can also help identify the issue quickly. 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.

🔌 Shopify Pixel Disconnection After Version Updates

🔍 What Is This Issue? If your Shopify store's pixel connection has dropped in Search Atlas, a Shopify pixel version update is the most common cause. When Shopify releases a new pixel version, the previously installed tracking script can become invalid, breaking the connection between your store and Search Atlas. This affects all stores using the integration, including scenarios where multiple domains disconnect at the same time. This article walks you through why it happens and how to fix it by replacing the outdated script with the current version. ⚠️ Common Symptoms - One or more Shopify stores show a Disconnected status in Search Atlas. - Tracking data stops updating or shows a gap starting from a recent date. - Multiple stores owned by the same account disconnect simultaneously. - The connection was working correctly before a recent Shopify platform update. 🧠 Why This Happens Shopify periodically updates its Customer Pixel framework. When a new pixel version is released, scripts built on the previous version are no longer recognised as valid by Shopify's tracking infrastructure. The connection is not lost due to anything you changed — it is a platform-side version change that requires you to replace the installed script with an updated one generated from Search Atlas. 🔧 How to Fix It Follow these steps for each affected Shopify store. 1. Log in to Search Atlas and navigate to the Integrations section from the top-right avatar → Settings → Integrations. 2. Locate the disconnected Shopify store and click Reconnect or Manage Integration. 3. Search Atlas will generate a new pixel script based on the latest Shopify pixel version. Copy this script to your clipboard. 4. Open your Shopify Admin for the affected store. 5. Go to Settings → Customer Events. 6. Find the existing Search Atlas pixel script. Click on it to open the editor. 7. Delete the entire contents of the existing script field. 8. Paste the new script you copied from Search Atlas into the field. 9. Click Save. 10. Return to Search Atlas and verify the store status has changed to Connected. This may take up to five minutes to confirm. Repeat steps 4–10 for every disconnected Shopify store. ✅ How to Confirm the Fix Worked - The store displays a Connected status in the Search Atlas Integrations panel. - Tracking events begin appearing in your reports within 24 hours. - No error banners are shown against the store in the dashboard. 🛡️ How to Prevent Future Disconnections - Check the Search Atlas status banner when you notice a drop in tracking data — platform-wide pixel version changes will often be flagged there first. - After any Shopify platform announcement about Customer Pixel updates, proactively refresh your script using the steps above before a disconnection occurs. - If you manage multiple Shopify stores in Search Atlas, check all of them when one disconnects, as version updates affect all stores at the same time. 💬 Need More Help? If you have completed the steps above and your store still shows as disconnected, or if you are unsure which script version to use, 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.

🔄 Fix CMS Syncing for GHL

🔗 What CMS syncing does CMS syncing connects Search Atlas with your website’s content management system so approved articles can be published directly to your site. GoHighLevel (GHL) connections may require an active authorization, the correct site or sub-account, and valid publishing permissions. 📝 Check your publishing setup 1. Open Content → Content Genius from the left sidebar. 2. Open the article you want to publish or create one using Generate, Write it yourself, Write with AI in Bulk, or Write an article. 3. Open the article’s publishing or CMS connection settings. 4. Confirm that GHL is selected and that the connected site, location, or sub-account is correct. 5. Review the available publishing instructions and required fields before sending the article to your CMS. 🔄 Refresh the GHL connection 1. Open the CMS connection settings for the article or project. 2. Select the option to refresh, reconnect, or authorize the GHL connection. 3. Complete the GHL authorization using an account with access to the correct sub-account and publishing permissions. 4. Return to Search Atlas and wait for the connection status to update. 5. Retry the sync or publishing action. Refreshing the sync alone may not resolve an expired authorization or an incorrect GHL location. Reauthorizing the connection is usually required in those cases. 🛠️ Resolve common sync errors - Connection expired: Reconnect GHL and approve all requested permissions. - Wrong site or location: Confirm that the selected GHL sub-account matches the website where the article should be published. - Missing permissions: Ask a GHL administrator to grant access to the website, blog, and publishing features. - Required fields missing: Add the article title, content, URL path, author, category, or other fields requested by the CMS. - Duplicate or existing article: Check whether the same URL or article already exists in GHL before retrying. - Temporary sync failure: Save the article, wait briefly, then retry once. Avoid repeated submissions that could create duplicate posts. 📚 When connection instructions are unavailable If the original CMS instructions are no longer visible after connecting GHL, open the connection or publishing settings again from the article. The instructions may only appear before authorization or while the connection setup panel is open. If available, disconnect and reconnect the CMS to restart the setup flow, then select the correct GHL location before publishing. ✅ Confirm a successful publish 1. Check that the sync status changes to successful or published. 2. Open the article URL from your website and confirm the title, content, images, and formatting. 3. In GHL, confirm that the article appears in the expected blog or website area. 4. If the article is not visible, check whether it was saved as a draft and publish it in GHL if needed. 💬 Get help with an unresolved error Before contacting support, record the exact error message, affected article, selected GHL location, and whether reconnecting changed the result. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.

🔐 Fix Signal Genesys API Scope Errors

🔎 What the 403 error means A 403 Invalid scope provided response means the access token does not include the scope required by the endpoint. The request may be correctly formatted, but the token was issued without the permission the API checks. This is different from an expired or invalid token. Repeating the request with the same token will continue to return 403 until the token is issued with the correct scope. ⚙️ How Signal Genesys authentication works Each Signal Genesys endpoint defines one or more required scopes. Your authentication setup must request those scopes, and the Signal Genesys authorization service must approve them for the client or application. Scopes are controlled by Signal Genesys and the client configuration used for your integration. Search Atlas cannot add, approve, or enable a Signal Genesys scope from the Search Atlas interface. ✅ Verify your configuration 1. Confirm that you are using the current Signal Genesys API base URL and endpoint documentation. 2. Check the endpoint’s required scope and copy it exactly, including capitalization, punctuation, and separators. 3. Review the token response and confirm that the returned scope value contains the required permission. 4. Request a new token after changing scopes. Existing tokens do not gain newly approved permissions. 5. Send the token as an authorization header using the format Authorization: Bearer YOUR_ACCESS_TOKEN. 6. Make sure the token was issued for the same environment, client, and API host as the request. 🚫 Common causes of invalid scopes - The scope was omitted from the token request. - The scope name was typed incorrectly or uses an unsupported alias. - The client is not approved for that scope. - A token from another environment or application is being reused. - The integration is using an authentication flow that does not support the required scope. - The API documentation and deployed endpoint require different scope names. 👤 Is a Search Atlas account required? A Search Atlas account is required when you use a Search Atlas feature or workflow that connects to Signal Genesys. However, having a Search Atlas account does not automatically grant Signal Genesys API access or the scopes required by external endpoints. For a direct Signal Genesys API integration, access depends on Signal Genesys client registration, authorization, and scope approval. Confirm the required account and client setup with the Signal Genesys API owner or administrator. 🛠️ When to request configuration help If every endpoint returns the same invalid-scope response, provide your integration owner with the endpoint, HTTP method, requested scope, token response scope, client environment, and request timestamp. Do not share client secrets or full access tokens. Ask the API owner to confirm that the client is approved for the exact scope and that the selected authentication flow can issue it. Search Atlas support can help review how the Search Atlas workflow is configured, but cannot grant Signal Genesys permissions. 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.

🔧 Fix WordPress Plugin Authentication Credentials Error

Overview The 'authentication credentials not provided' error appears when the Search Atlas WordPress plugin cannot verify your account credentials during a diagnostic run. This usually means the connection between your WordPress site and Search Atlas has broken or was never fully established. Because the source of this error can vary by site configuration, the steps below cover the most common areas to check. Work through them in order before escalating. Step 1: Verify Your API Key Before changing any plugin settings, confirm that the API key linked to your site is still valid. 1. Log in to your Search Atlas dashboard. 2. Navigate to your account or integration settings and check whether an API key exists and is active. 3. If the key appears inactive, expired, or missing, generate a new one from within the dashboard. 4. Copy the key carefully — do not rely on a previously copied value. An invalid or expired key is a common cause of authentication failures that persist even after reconnection attempts. Step 2: Reconnect the Plugin If your key is active but the error continues, try fully disconnecting and reconnecting the plugin. 1. In your WordPress admin panel, open the Search Atlas plugin settings. 2. Remove or clear the currently stored API key. 3. Paste the fresh key you copied from the dashboard into the appropriate field and save. 4. Wait a minute, then run diagnostics again to see whether the error clears. Step 3: Check for Security Plugin or Server-Level Conflicts Security plugins and server-level firewalls can block the requests the Search Atlas plugin sends during authentication. - Temporarily deactivate any security or firewall plugins and run diagnostics again to see if the error disappears. - If diagnostics pass with those plugins off, re-enable them one at a time to identify the conflict, then adjust that plugin's settings to allow Search Atlas traffic. - Contact your hosting provider to confirm that outbound requests to Search Atlas servers are not being blocked at the server or firewall level. - Check whether your site's REST API is accessible — if it is disabled or restricted, the plugin will not be able to authenticate. Step 4: Clear Cached Credentials Stale cached data can cause the plugin to send outdated credentials. Clear your WordPress site's cache (including any object cache or page cache) and your browser cache, then attempt to reconnect the plugin and run diagnostics again. Step 5: Escalate if the Error Persists If you have worked through all of the steps above and the 'authentication credentials not provided' error still appears, the issue likely requires investigation by our support team. To help us resolve it as quickly as possible, please have the following ready when you reach out: - Your WordPress site URL - The exact error message displayed during diagnostics - A list of any active security or firewall plugins - Details of any recent changes to your site or hosting environment 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.

🔑 Troubleshoot Customer API Key 401 Errors

🔍 What a 401 error means A 401 Unauthorized response with "Bad API key" means Search Atlas could not authenticate the credential sent with the request. This usually results from an incorrect key, an unsupported header format, a hidden character, or using a key from the wrong environment. ✅ Check the API key and request format 1. Locate your API key in your Search Atlas account settings. 2. Confirm you copied the complete production key. Do not include quotation marks, spaces, line breaks, or other surrounding characters. 3. Review the endpoint documentation and use the required authentication header exactly as shown. Do not substitute a JWT, session token, or an older authentication format. 4. Confirm the request is sent over HTTPS and that your HTTP client is not removing or rewriting the authentication header. 5. Test with a simple request from a tool such as cURL or Postman before testing through your application. 🧪 Test with a clean request Create a new request using one documented endpoint and the current production base URL. Add only the required headers, including the API key header specified in the documentation. Avoid copying headers from a browser session, cached environment variables, or another integration. If the request works in cURL or Postman but fails in your application, compare the final outgoing request. Check for an empty environment variable, truncated value, extra whitespace, incorrect capitalization, or middleware that replaces the API key. 🔄 Rotate the key safely If the key still returns 401, generate a new API key from your Search Atlas account settings and update the integration. Store it securely as a secret, then retry the request. Do not publish API keys in source code, browser-side scripts, screenshots, logs, or support messages. After confirming the new key works, remove or revoke the old key if it is no longer needed. When rotating keys in production, update all services that use the credential before disabling the previous key. ⚠️ Check endpoint and account access API key authentication is supported on customer-facing endpoints documented for API-key access. Some specialized actions or connectors may require a different authentication method or may not support API keys. Verify that the endpoint, HTTP method, account, and production environment match the documentation. 🛠️ When to contact Search Atlas If newly generated production keys continue to return 401 on documented endpoints after completing these checks, have the following ready when you reach out: the endpoint path, HTTP method, response status, response message, and a redacted request example showing only the header names (never the key values). This information allows the team to investigate your account's API access quickly. 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.

🔧 Fix Outreach Inbox Unread Count No Messages

Overview If your Outreach inbox displays an unread message count but shows no content when you open it, or if your emails are taking longer than expected to sync, this article explains the most common causes and the steps you can take to resolve them. This issue affects the Inbox section inside the Digital PR and Outreach tools. Common Causes of the Unread Count Display Bug Seeing an unread badge without any visible messages is usually caused by one of the following: - Email sync still in progress: Messages have been detected by the system but have not yet fully loaded into the inbox view. - Incomplete email account connection: The connected email account lost its authentication or was disconnected mid-sync, leaving ghost counts behind. - Browser cache conflict: Outdated cached data in your browser can cause the inbox UI to display stale or mismatched information. - Filter or folder mismatch: Active inbox filters may be hiding messages that the unread counter is still tracking. Common Causes of Email Sync Delays Email syncing in the Digital PR and Outreach modules depends on a live connection between Search Atlas and your linked email provider. Delays can occur when: - Your email provider is experiencing service issues or rate limiting. - The OAuth token for your connected account has expired and needs to be re-authenticated. - A large volume of emails is being synced for the first time after a new account connection. - Your inbox has a high number of messages or threads, which increases initial sync time. - Network interruptions occurred during an active sync cycle. Initial syncs for newly connected accounts may take some time depending on mailbox size. Subsequent syncs are typically faster. Step-by-Step Troubleshooting Follow these steps in order to diagnose and resolve the issue. 1. Wait and refresh: If you recently connected your email account or sent a campaign, wait a few minutes and then hard-refresh the page using your browser's refresh shortcut. 2. Clear your browser cache: Go to your browser settings, clear cached images and files, then reload the platform. 3. Check your inbox filters: Navigate to your Outreach or Digital PR inbox and confirm that no active filters are narrowing the view. Reset any applied filters to show all messages. 4. Reconnect your email account: If messages are still missing, disconnect your email account from the platform's email connection settings and reconnect it. This forces a fresh authentication and a new sync cycle. 5. Try a different browser or incognito mode: If the issue persists after clearing cache, open the platform in a private/incognito window or a different browser to rule out a local browser conflict. 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.

🔧 Fix a Broken WordPress Contact Form

🧭 Overview If your WordPress contact form suddenly stopped working — especially after a site change, plugin update, or on a specific date — this guide walks you through the most common causes and fixes. If you have already tried troubleshooting before or reported this issue previously without resolution, skip to the Escalate to Our Team section at the bottom. Persistent or account-specific issues require hands-on investigation that goes beyond standard self-service steps. ⚠️ Before You Begin Keep these points in mind before attempting any fixes: - If you have already reported this issue to support and it remains unresolved, do not repeat the same troubleshooting steps. Escalate directly using the instructions at the end of this article. - Note the exact date the form stopped working. A specific break date (such as March 31) often points to a plugin update, hosting change, or server-side configuration change that occurred on or around that day. - Back up your site before making any changes. 🔍 Common Causes of a Broken Contact Form WordPress contact forms most often break due to one of the following reasons: - A plugin conflict — a recently updated or newly installed plugin is interfering with your form plugin. - A caching issue — cached pages are serving outdated form markup or blocking nonce validation, which is a WordPress security token required for form submissions. - A hosting or server change — PHP version updates, mail server configuration changes, or firewall rules can silently break form submissions. - An SSL or HTTPS mismatch — forms submitting over HTTP on an HTTPS site will fail. - Email delivery failure — the form itself may be working, but submission confirmation emails are being blocked or filtered as spam. 🛠️ Troubleshooting Steps Work through these steps in order. After each step, test your form by submitting a test entry. 1. Check for recent plugin or theme updates. Go to your WordPress dashboard and review your update history. If a plugin was updated around the date the form broke, try deactivating it temporarily to see if the form recovers. 2. Clear all caches. Clear your WordPress caching plugin cache, your browser cache, and if your site uses a CDN (such as Cloudflare or BunnyCDN), purge the CDN cache as well. Stale cache is one of the most common causes of form nonce errors. 3. Test with all plugins deactivated. Deactivate every plugin except your form plugin and retest. If the form works, reactivate plugins one at a time to identify the conflict. 4. Switch to a default WordPress theme temporarily. Theme code can interfere with form scripts. Switch to Twenty Twenty-Four or another default theme and test the form again. 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.

⚡ Fix Contentful Sync Errors Blocking Article Publishing

Overview When publishing an article from Search Atlas to Contentful fails with a sync error, one known cause is a Content Type validation restriction inside Contentful itself. This article explains what that means and how to diagnose and resolve it. What Is a Content Type Validation Error? A Content Type validation error occurs when Search Atlas successfully connects to Contentful, but Contentful rejects the content because the entry does not meet the field-level rules defined in your Contentful Content Type configuration. This is a Contentful-side restriction, not a broken connection between the two platforms. Common signs that you may be experiencing this issue include: - Reconnecting your Contentful integration or refreshing your API credentials does not resolve the error. - The sync error appears only for certain articles, not all publishes. - Publishing succeeds from Contentful directly but fails when triggered from Search Atlas. What to Do If You Encounter This Error Start by checking your Contentful Content Type configuration to identify the validation rules that may be blocking your publish: 1. Log in to your Contentful workspace. 2. Navigate to the Content Model tab. 3. Select the Content Type you are trying to publish to from Search Atlas. 4. Review each field and note which ones are marked as required, which have character limits, or which restrict the type of content allowed (for example, rich text fields that only accept plain text). 5. Compare the fields in your Search Atlas article with the validation rules in Contentful. Common mismatches include: missing required fields, field values exceeding character limits, or attempting to publish rich text or HTML to a field configured to accept plain text only. 6. If you find a mismatch, you can either adjust your article in Search Atlas to match the Contentful field rules, or contact your Contentful administrator to modify the Content Type validation rules. Because the specific Content Type configuration and validation rules vary by Contentful account, if you are unable to resolve the issue after reviewing your Content Type settings, our support team can help investigate further. When reaching out, please have the following information ready to speed up the investigation: - The exact error message or sync error text you see in Search Atlas. - The name of the Contentful Space and Content Type you are publishing to. - The name of the article or entry that failed to publish. - The approximate date and time the error occurred. - A screenshot or list of the validation rules you found in your Content Type configuration. 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.

🛠️ Fix WordPress MetaSync Detection

🔍 Understand the connection status The WordPress MetaSync plugin may not be detected. When it is not detected, the OTTO script is an alternative installation method. 🔁 Check the WordPress plugin 1. Sign in to WordPress and open the MetaSync plugin settings. 2. Check whether the MetaSync plugin is detected in Search Atlas. 🚀 Install the OTTO script instead 1. If the MetaSync plugin is not detected, use the OTTO script installation method. 2. Copy the OTTO script provided for your site and add it to the required location on your WordPress site. 3. Save or publish the change so the script is active on the live site. ✅ Verify the installation - Return to Search Atlas and check whether the site is detected. - If it is still not detected, confirm that the OTTO script was saved and published on the live site. 💬 Get help with unresolved issues If the issue remains unresolved, confirm that the MetaSync plugin is not detected and that the OTTO script has been added and published. 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.

🔧 How to Fix a Fatal WordPress Plugin Conflict

This article helps you address a fatal error or broken page layout that appears on your WordPress blog after publishing a post. This type of issue is commonly caused by a plugin conflict. Because the exact cause can vary depending on your specific plugins and theme, the steps below provide a general approach to identifying and resolving the conflict. 🔍 Common Causes - Plugin conflict: Two or more active plugins may be attempting to control the same functionality, causing errors on the front end. - Recently activated or updated plugin: A plugin change made just before publishing may have introduced a compatibility issue. - Theme conflict: Some themes are not compatible with all plugins, which can cause layout breaks or fatal errors. 🛠️ General Troubleshooting Steps 1. Access your WordPress admin dashboard by navigating to yourdomain.com/wp-admin and logging in with your credentials. 2. Identify recently changed plugins. In your plugins list, look for any plugin that was installed, activated, or updated just before the error appeared. 3. Deactivate the suspect plugin from the plugins list, then reload your blog page to see if the error clears. If it does, that plugin is the likely cause of the conflict. 4. If the source is unclear, deactivate all non-essential plugins one at a time and reload your blog page after each deactivation to isolate which plugin is responsible. 5. Once the conflicting plugin is identified, you can choose to leave it deactivated, look for an alternative plugin, or contact the plugin's support team for a compatibility fix. 6. Clear your website cache using your caching plugin or hosting panel after making any changes, so the updated version of the page is served to visitors. ℹ️ What to Have Ready When Contacting Support - The name and version of the plugin you believe is causing the conflict. - The exact fatal error message displayed on your blog (copy the full text if possible). - A list of all active plugins on your site. - The timestamp of when the error first appeared and what change was made immediately before it. ✅ How to Confirm It Worked - Open your blog post URL in a private/incognito browser window — this ensures you are not seeing a cached version. - The page should display your post content normally, with no white screen, fatal error message, or broken layout. - Scroll through the full post to confirm images, formatting, and any embedded content render correctly. 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.

🛠️ Fix Search Atlas Plugin Performance Slowdown

🔍 Overview Some users notice a drop in website performance after installing the Search Atlas WordPress plugin. This is a known issue our engineering team investigates on a case-by-case basis. This article explains what may be happening and how to escalate so our team can identify and resolve the root cause for your specific setup. ⚙️ What May Be Causing the Slowdown The Search Atlas plugin communicates with the Search Atlas platform to sync content, metadata, and SEO signals. Under certain configurations, this communication can introduce latency. Potential contributing factors include: - Conflict with other active plugins — some plugins may interfere with plugin scripts, causing repeated uncached requests. - Hosting environment limitations — shared hosting with limited server resources or slow external request handling can amplify any added load. - Outdated plugin version — older versions may include less efficient data-handling routines. - Excessive post volume — sites with a very large number of posts may experience heavier sync operations. 🚀 What to Try Before Escalating 1. Update the plugin to the latest version. In your WordPress dashboard, go to Plugins → Installed Plugins, find Search Atlas, and click Update if an update is available. 2. Check your PHP memory limit. Review your hosting account's server settings or contact your hosting provider to confirm your current PHP memory limit and request an increase if needed. 3. Check for plugin conflicts. Temporarily deactivate other active plugins and retest your site speed to determine whether a conflict is contributing to the slowdown. 4. Run a speed test before and after each change. Use a site speed testing tool to measure the impact of each adjustment individually so you can isolate the cause. 📋 How to Escalate This Issue Because this is a bug-category issue, our support team will need to investigate your specific environment. To help us resolve this as quickly as possible, please have the following ready when you contact us: - Your WordPress site URL - The exact version of the Search Atlas plugin you are running - The names and versions of any other active plugins, particularly caching or performance plugins - Your PHP memory limit and hosting provider name - A speed test report showing the slowdown - The approximate date and time when you first noticed the performance drop 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.

🛠️ Atlas Brain Niche Field Not Saving via API

🔍 Overview Some users have reported that after updating the niche field inside default_ai_settings through the API, the new value does not persist. Instead, the field returns null when queried. This is a known platform bug that has been identified, escalated, and resolved by the Search Atlas engineering team. ⚙️ What Causes This Issue This problem was caused by a bug in Atlas Brain that prevented the niche field from being written and retained correctly when updated via the API. The field would appear to accept the new value, but it would not save, and subsequent reads would return null. This affected Brand Vault niche field updates made through the API integration. ✅ Current Status The engineering team has confirmed that this bug has been fully resolved. The fix was prioritized, developed, reviewed, and released. If you experienced this issue before the fix was deployed, your niche field may still show null and will need to be set again. 🚀 Steps to Resolve 1. Retry your API update. Now that the underlying bug is fixed, attempt to update the niche field via the API again using the same request you used previously. 2. Verify the value persisted. After submitting the update, retrieve the record via a follow-up API read request to confirm the niche field now returns your intended value rather than null. 3. Re-enter the value manually if needed. If the field still shows null after retrying the API update, try setting the niche field directly within the platform as a temporary measure while you confirm the API call is formatted correctly. 4. Check your API request format. Ensure the niche value is being passed correctly within the default_ai_settings object in your request payload. A malformed or missing field key can cause the value to be silently dropped. 💡 Tips to Prevent This Going Forward - After any API update to settings fields, always perform a follow-up read request to confirm the value was saved as expected. - If a field returns null unexpectedly after an update, treat this as a signal to retry the request or contact support — it may indicate a transient issue rather than an error in your code. - Keep your API integration up to date, as platform fixes may occasionally require that previously failed operations be retried. 📞 Still Seeing the Issue? If the niche field continues to return null after following the steps above, this may indicate a different underlying problem specific to your account or project. If you need further assistance, reach out to our support team and a member of our team will be happy to help.

🛠️ BrandVault WordPress Sync Shows Numeric Categories

🔍 What Is Happening When you bulk select articles in BrandVault and sync them to WordPress, the published posts may display a raw numeric value — such as 16 — in the category field instead of the category name you selected during the sync. This occurs even when the sync popup appears to confirm the correct category was chosen. This is a confirmed platform bug. Our engineering team has identified the root cause and a fix has been developed, reviewed, and is awaiting release to production. ⚠️ Is This Affecting You Right Now You are affected by this issue if you notice any of the following after syncing BrandVault articles to WordPress: - WordPress posts show a number (for example, 16) in the category field instead of a category name. - The category appeared correct inside the BrandVault sync popup but was wrong after publishing. - The issue happens consistently when syncing multiple articles in bulk. 📋 What You Should Do Now Because the fix is currently awaiting deployment to production, the recommended steps are: 1. Do not re-sync repeatedly in an attempt to correct the category — this will not resolve the issue and may create duplicate posts. 2. Manually update the category on any already-published WordPress posts that are showing a numeric value. Log in to your WordPress admin, open each affected post, and reassign the correct category directly in WordPress. 3. Hold off on new bulk category syncs for content where the correct category assignment is critical, until the platform fix has been deployed. 4. Check back soon — once the fix is live in production, category names will sync correctly from BrandVault to WordPress without any manual workaround needed. ✅ What Our Engineering Team Has Done This issue was escalated internally and logged as a confirmed bug: BrandVault → WordPress Content Sync: published posts show numeric category value instead of selected category name. The ticket progressed through full investigation, development, code review, and quality assurance. It is currently at the Awaiting Release stage, meaning the fix is complete and scheduled for deployment to production. No action is required on your end to receive the fix — it will apply automatically once released. 💬 Need Help With Affected Posts If you have a large number of posts impacted and need guidance on the fastest way to correct them, or if you want a status update on when the release is expected, our team is ready to help. If you need further assistance, please reach out to our support team directly and we will be happy to assist you.

🔗 Reconnect Search Atlas After Anthropic Cloud Migration

🧭 Overview If you recently switched or migrated your Anthropic Cloud account, your existing Search Atlas connection will be lost because the Model Context Protocol (MCP) configuration is tied to your account credentials. To restore the integration, you need to re-add the Search Atlas MCP URL inside your Anthropic Cloud account settings. 🔑 What Is the Search Atlas MCP URL? Search Atlas connects to Anthropic Cloud via a Model Context Protocol (MCP) endpoint. This URL tells Anthropic Cloud where to find and communicate with the Search Atlas toolset. When you change your Anthropic account, this connector is not carried over automatically — you must add it again manually. The Search Atlas MCP URL is: https://mcp.searchatlas.com/mcp/ ⚙️ How to Restore the Connection To restore your Search Atlas connection after an Anthropic Cloud account migration, you will need to re-add the Search Atlas MCP URL to your new Anthropic Cloud account. The exact navigation steps may vary depending on your Anthropic Cloud interface, so follow the MCP connector setup flow within your account settings and enter the MCP URL above when prompted for a server or integration endpoint. If you are unsure where to locate the MCP connector setup in your Anthropic Cloud account, please reach out to our support team (see below) and have the following ready: - Your Search Atlas project or workspace name - Confirmation of which Anthropic Cloud account (email address) you migrated to - Any error message you see when attempting to connect ✅ Verifying the Integration Is Working After adding the MCP URL in your new Anthropic Cloud account, confirm the connection is working by testing an AI-powered feature in Search Atlas. If responses populate correctly, the integration has been restored. If the connection still fails, double-check that the MCP URL was entered exactly as shown above with no trailing spaces or extra characters. ⚠️ Common Issues After Account Migration - Multiple Anthropic accounts: Make sure you are logged into the correct new account when adding the MCP URL. Connectors added to the wrong account will not link to your Search Atlas workspace. - MCP URL added but still not connecting: Try removing the entry and re-adding it. Occasionally a partial save during initial setup can cause the connection to fail silently. 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.

🔌 Fix OTTO GHL Subaccount Connection Issues

🔍 Overview Search Atlas can publish content (for example Content Genius articles) directly to your GoHighLevel (GHL) subaccount via a CMS connector — but the connection must be configured correctly before articles can go live. To connect, go to the top-right Avatar Menu (👤) → Settings → CMS Connectors → Add Connector → GoHighLevel. Note: this CMS connector does not install OTTO — OTTO on a GoHighLevel site still uses the OTTO pixel. If the integration is not connecting as expected, this guide explains what to check and what information to have ready when contacting our support team. ✅ Before You Begin Confirm the following before troubleshooting the connection: - You are using a GHL subaccount API token. Search Atlas requires a subaccount-specific token to publish content. - Your GHL subaccount has website/blog functionality enabled. If blogs are not active on the subaccount, publishing will fail even with a valid token. - You have at least one blog set up inside the GHL subaccount. OTTO needs an existing blog destination to publish to. - Your GHL account is on a plan that supports API access. Check your GHL subscription if you are unsure. ⚠️ Common Things to Check When the Connection Fails - Confirm your API token is from the correct subaccount level: Make sure the token was generated from inside the specific GHL subaccount you want to connect, not from the agency dashboard. - Check whether the blog feature is active on the subaccount: In GHL, blog publishing may need to be enabled at the subaccount level. Confirm the blog section is visible and accessible inside the subaccount. - Confirm at least one blog exists in the subaccount: OTTO requires an existing blog destination. If no blog has been created yet, set one up in GHL before attempting to connect. 📋 What to Have Ready When Escalating If the connection still does not work after checking the above, our support team will need the following details to investigate: - Your Search Atlas project name and the GHL subaccount you are trying to connect - A description of exactly what happens when you attempt to connect (e.g., any error message shown, word for word) - The timestamp of when the issue occurred - Confirmation of whether your GHL plan includes API access 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.

🔧 Fix WordPress Plugin One-Click Authentication Failures

Overview If you have already installed the Search Atlas JavaScript code on your WordPress site but the one-click authentication button still fails, you are not alone. This is a known issue related to WordPress plugin authentication and OTTO integration. This article explains what to prepare and how to get it resolved quickly. Why Does This Happen? One-click authentication failures after JavaScript installation are typically related to how the Search Atlas WordPress plugin connects with OTTO. Installing the JavaScript snippet and authenticating the plugin are two separate steps, and completing one does not automatically complete the other. Common situations where authentication fails: - The one-click button does not complete the connection even though the JavaScript snippet is already on the site. - The plugin was installed or updated but the OTTO integration was not fully configured afterward. - A caching layer or server configuration is interfering with the authentication request. What to Try First Because the specific steps to resolve this issue depend on your account configuration and OTTO setup, the most reliable path is to work directly with the Search Atlas support team. Before reaching out, gather the following so your request can be handled as quickly as possible: - The domain of the WordPress site where the plugin is installed. - A description of exactly what happens when you click the one-click authentication button (e.g., error message, spinner that never completes, page reload with no change). - Whether you have already attempted any manual authentication steps in the plugin settings. - Any recent changes to your site, such as caching plugin updates, server migrations, or JavaScript snippet modifications. What to Expect Once a support agent reviews your account, they will be able to identify whether the issue is related to your OTTO configuration, plugin settings, or another factor, and will walk you through the exact steps needed for your setup. Manual authentication using your API key is a fully supported alternative path if the one-click button cannot be made to work. 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.

🔧 Fix Slack Coworker Bot Connection Issues

🔍 Overview After reinstalling or reconnecting the Slack integration, some users find that the Coworker bot stops responding in channels and DMs, the dashboard still shows Slack as Not Connected, and the bot cannot read thread history — even when Slack reports the required scopes are granted. This is a backend gateway mapping issue that requires our team to resolve on your account. ⚠️ Why This Happens When the Slack app is reinstalled, Slack issues a new OAuth token and workspace ID. If the platform's internal gateway mapping is not updated to point to this new token, the connection appears broken from the Search Atlas side even though Slack itself shows the app as installed. A stale mapping also blocks thread history access because the bot cannot authenticate its read requests correctly. Resolving this mapping requires a backend correction by our support team. 🛠️ What to Do Because this issue involves a backend gateway mapping that cannot be corrected from the user interface, please escalate to our support team. To help us resolve your issue as quickly as possible, have the following information ready before reaching out: - Your Search Atlas workspace or project name - The exact error message you see, if any (for example, the 'Not Connected' status message or any error shown during the OAuth flow) - The timestamp of when the issue started or when you last attempted to reconnect Slack - Whether you have already attempted to remove and reinstall the Slack app, and if so, approximately when - Your Slack workspace name so our team can locate the relevant gateway mapping on the backend 💡 What to Expect Once our team receives the above details, we will correct the gateway mapping on the backend so that the new OAuth token and workspace ID are properly registered. After the fix is applied, the Coworker bot should resume responding in channels and DMs, and thread history access will be restored. You do not need to take any additional action in Slack or Search Atlas unless our team instructs you to. 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.

🔧 Fix WordPress Plugin Disconnect and OTTO Deployment Failures

Overview If your OTTO SEO dashboard is showing a red connection status, or deployed fixes are not rendering on your live site, your WordPress plugin may have lost its connection to Search Atlas. This guide explains what may be happening and what to have ready when you contact our support team so we can resolve the issue as quickly as possible. Common Symptoms - Red indicator next to your WordPress site in OTTO SEO - Fixes marked as deployed but not visible on your live site - Deployment failures that revert to an undeployed state - Error messages related to API key issues - Unable to deploy specific fix types What May Be Causing This WordPress plugin disconnects and OTTO deployment failures can occur for several reasons, including an outdated plugin version, an expired or incorrectly entered API key, or a configuration issue between your WordPress installation and Search Atlas. Because the specific cause varies by account and site setup, our support team will need to investigate your connection directly. How to Escalate This Issue Since this is a bug-category issue that requires backend investigation, please do not attempt to delete and reinstall the plugin without guidance, as this may cause additional data loss. Instead, contact our support team and have the following information ready: - Your site URL — the exact domain connected to OTTO SEO - Your Search Atlas account email - A description of what you see — for example, the exact error message, the color of the status indicator, and which fix types are failing - When the issue started — approximate date and time, and whether anything changed around that time (e.g., a plugin update, WordPress update, or password change) - Your current plugin version — visible in your WordPress admin under Plugins Our team will review your connection status, verify your API key configuration, and push any necessary backend fixes to restore your deployment pipeline. 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.

🛠️ Wix Integration Known Issues and Workarounds

🔍 Overview If your Wix site is connected to Search Atlas and you are experiencing issues with stale images, delayed metadata updates, or an H1 element causing unexpected page behavior, you are not alone. These are known integration defects that affect a subset of Wix-connected sites. This article explains each issue, its current status, and what to have ready when escalating to our team. ⚠️ Known Wix Integration Defects The following defects have been identified and are under active investigation by our engineering team. - Stale images: Images on Wix sites may not refresh after being updated through Search Atlas. The old image may continue to appear even after a successful save. - Delayed mutations: Changes pushed from Search Atlas — such as metadata updates — may take longer than expected to reflect on the live Wix site. - H1 containment: On certain Wix page templates, modifications to the H1 element through Search Atlas may produce unexpected page behavior related to how Wix renders that element. 📊 Current Status All defects listed above have been escalated to our engineering team for investigation. Our team is actively working to resolve each issue and will communicate updates as they become available. If you have an open support conversation related to these issues, our team will update your ticket directly as progress is made. You do not need to reopen or re-submit a request for these known defects. 🛠️ What to Have Ready When Escalating Because these are backend integration defects, our engineering team will need specific details to investigate your case. Please have the following information ready before contacting support: - Your Wix site URL - The specific defect you are experiencing (stale images, delayed mutations, or H1 containment) - The exact page or pages affected - A description of what you changed in Search Atlas and when - Any screenshots or screen recordings showing the issue 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.

🔧 Fix OTTO WordPress Plugin Sync Issues

Overview When OTTO SEO deploys fixes — such as schema markup, heading tag updates, or site audit recommendations — those changes are sometimes marked as Deployed inside Search Atlas but do not appear on your live WordPress site. This article explains the most common causes and what to do next. How OTTO Deploys Changes to WordPress OTTO SEO communicates with your WordPress site through the Search Atlas WordPress plugin. When you apply a fix inside OTTO, the platform sends the change to your site via this plugin. If the connection between OTTO and your WordPress installation is broken or misconfigured, changes will be recorded as deployed in Search Atlas but will never reach your live site. Step 1 — Verify the WordPress Plugin Is Installed and Active 1. Log in to your WordPress admin dashboard. 2. Go to Plugins → Installed Plugins. 3. Confirm that the Search Atlas plugin is listed and its status shows Active. 4. If the plugin is missing, download the plugin .zip from your Search Atlas account and install it in WordPress → Plugins → Add New → Upload Plugin. 5. If the plugin is inactive, click Activate. Step 2 — Check for Caching Conflicts Even when changes are successfully deployed, caching layers can prevent them from appearing on the live site. Try clearing your caches, including any WordPress caching plugin, your hosting-level cache, any CDN cache, and your browser cache. After clearing caches, revisit the affected pages on your live site and check whether the changes are now visible. Step 3 — Escalate to Our Support Team Because deployment sync issues between OTTO and your live WordPress site may require backend investigation, please reach out to our team with the following details ready: - Your WordPress site URL - The specific OTTO fixes that are showing as deployed in Search Atlas but are not appearing on the live site - Any error messages you have observed 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.

🔧 Fix MCP Endpoint Connectivity and Initialization Failures

Overview The Search Atlas MCP (Model Context Protocol) endpoint allows external AI agents and tools to connect with your Search Atlas account. If you are seeing timeout errors, DNS resolution failures, or MCP initialization issues, this article explains what to have ready when escalating to our support team so we can investigate and resolve the issue on the backend as quickly as possible. Common Symptoms - DNS resolution failure: Your client cannot resolve the MCP endpoint domain - Connection timeout: The MCP endpoint does not respond within the expected window - Initialization error: The MCP handshake starts but fails before tools are loaded - API or server errors: Requests via MCP return error responses - Tool list empty or missing: Connected successfully but no tools appear What to Have Ready When You Contact Support MCP endpoint connectivity and initialization failures are typically caused by backend configuration issues that require investigation by our team. To help us resolve your case efficiently, please gather the following before reaching out via the chat widget: - Your Search Atlas account email or username - The exact error message you are seeing — copy it in full, including any error codes - The timestamp of when the failure first occurred or was most recently observed (include your timezone) - A description of your MCP client setup — for example, which AI agent or tool you are using to connect - Steps you have already tried — such as re-entering your API key, restarting your client, or checking your network connection - Whether the issue is consistent or intermittent — and if intermittent, how often it occurs Having this information ready will allow our team to investigate your specific account and endpoint configuration on the backend without unnecessary back-and-forth. 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.

🔧 Fix WordPress Elementor Content Sync Issues

Overview When syncing content from Search Atlas to a WordPress site that uses Elementor, you may notice formatting inconsistencies, broken images, or content that does not appear as expected. This guide explains why these issues occur and what to do about them. Why Sync Issues Happen with Elementor Elementor is a page builder that stores content in its own custom data structure rather than in WordPress's standard post editor (the Block Editor or Classic Editor). When Search Atlas syncs content, it writes to the standard WordPress content field. If your page was built or last saved in Elementor, the two content sources can conflict, causing: - Formatted text appearing as plain or stripped-down content - Images missing or displaying broken links - Headings, bullet points, or spacing not rendering correctly - Content appearing in the wrong section of the page What to Do When You Experience These Issues Because the source topic for this article reflects a known compatibility issue between Search Atlas content sync and Elementor-managed pages, the specific resolution steps may vary depending on your WordPress setup, Elementor version, and how your pages are structured. If you are experiencing formatting or image problems after syncing, please reach out to our support team so we can review your specific configuration and guide you through the correct steps. When contacting support, it helps to have the following ready: - The name or URL of the WordPress page where the sync issue occurred - A description of what the content looks like after syncing (e.g., broken images, missing formatting, plain text) - Whether the page was built or last edited using Elementor or the standard WordPress Block Editor - Any error messages displayed during or after the sync attempt - The approximate date and time the sync was performed 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.

🔧 Fix WordPress CMS Sync Errors After Reinstall

🔍 Overview Some customers find that the CMS sync for their domain continues to show an error even after uninstalling, reinstalling, and activating the latest version of the Search Atlas WordPress plugin. This article explains why that can happen and what to do next. ⚠️ Why This Happens A standard plugin reinstall does not always clear the underlying connection state on the platform side. The sync error may persist due to a stale or broken connection tied to your domain that requires a backend reset — something that cannot be resolved through the WordPress dashboard alone. 🛠️ What You Can Try First 1. Fully delete the plugin — do not just deactivate it. In your WordPress dashboard go to Plugins, deactivate the Search Atlas plugin, then click Delete to remove it completely. 2. Reinstall the plugin. Go to Plugins → Add New → Upload Plugin, upload the Search Atlas plugin .zip provided by Search Atlas, install the latest version, and activate it. 3. Attempt to reconnect your domain. Follow the standard reconnection flow in Search Atlas for your WordPress site and check whether the sync error clears. 📋 When to Escalate If the sync error persists after the steps above, the issue is likely a stale connection state on the backend that requires action from our engineering team. This is not something you can resolve from your WordPress dashboard or your Search Atlas account settings. When you contact support, please have the following ready: - Your domain name (the exact URL showing the sync error) - The exact error message displayed (a screenshot is helpful) - Confirmation that you have already deleted and reinstalled the plugin - Any timestamp of when the error first appeared or when you last attempted a reconnect 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.

Fix Cloudflare Blocking Search Atlas Content Pushes

Overview When your website uses Cloudflare and its Web Application Firewall (WAF) is active, it may block automated content pushes from Search Atlas tools such as OTTO SEO. This happens because Cloudflare does not recognise Search Atlas servers by default and may treat the requests as potential threats. This article explains how to whitelist Search Atlas IP addresses inside your Cloudflare account so content automation works without interruption. Step 1 — Access Your Cloudflare Security Settings Log in to your Cloudflare account at cloudflare.com and select the domain that is blocking your content pushes. From your domain's dashboard, navigate to the security or firewall section where IP-based rules can be managed. If you access Cloudflare through a hosting control panel (such as cPanel), look for a Cloudflare or security option within that panel and open the firewall or IP rules area from there. Step 2 — Add an IP Allowlist Rule for Search Atlas Once you are in the firewall or IP rules area of your Cloudflare settings, create an allow rule for the following Search Atlas IP addresses: - 52.41.36.82 - 52.43.154.161 - 54.69.73.23 For each IP address, set the action to Allow and apply it to your domain. Save your changes once all addresses have been added. Step 3 — Retry Your Content Push After saving the allowlist rules, return to Search Atlas and retry the content push that was previously blocked. In most cases this resolves the firewall block immediately. If the content push still fails after adding all IP addresses, check that the rules have been saved correctly and that no other firewall or security layer (such as a separate hosting-level firewall) is also active on your domain. 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.

🛠️ Fix a Disconnected Shopify Connector in Search Atlas

🔍 Overview After adding or updating a Shopify API token, your connector may still show a Disconnected status in Search Atlas. This is almost always caused by cached authentication data that prevents the platform from recognising your new token. Following the steps below will clear that cache and restore the connection. 🚀 Step-by-Step: Clear Cache and Reconnect 1. Locate your Shopify connector. In Search Atlas, find your existing Shopify connector. Even if the status shows Disconnected, do not add a duplicate connector — work with the existing one. 2. Remove the existing connector. Disconnect or remove the existing Shopify connector. This clears the cached authentication session tied to the old token. 3. Hard-refresh your browser. Press Ctrl + Shift + R (Windows/Linux) or Cmd + Shift + R (Mac) to clear any locally cached page data. 4. Re-add the Shopify connector. Add the Shopify connector again from scratch. 5. Enter your token. Paste your Shopify API token into the connector setup. 6. Save and verify. Save the new connector and wait for the status to update to Connected. 💡 Why This Happens When a Shopify API token is replaced or expires, cached authentication data can conflict with the new credentials, causing the connector to appear disconnected even though the token itself is valid. Removing the connector and re-adding it clears this cached data so a fresh authentication handshake can occur. ✅ Confirming the Connection is Working Once the status shows Connected, verify the integration is fully functional by checking that any reports or features relying on Shopify data are loading correctly without errors. 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.

🛠️ Escalating Wix Integration Defects to Engineering

🔍 Overview If your Wix-connected site is experiencing persistent issues — such as SEO changes not publishing correctly — this article explains how to escalate your case to our engineering team and what to have ready when you do. ⚠️ Common Wix Integration Defects Some Wix-integrated sites may experience publishing issues where SEO changes applied within Search Atlas do not appear correctly on the live site. If you are seeing unexpected behavior with your Wix integration, our engineering team can investigate further. 📋 What to Have Ready When You Escalate To help our support team escalate your case to engineering as efficiently as possible, please have the following information available: - Your connected domain (e.g., yoursite.com) - A description of the specific publishing issue you are experiencing - The type of content affected (e.g., images, page titles, meta descriptions, alt text) - Whether the issue occurs consistently or intermittently - Approximate timestamps of when changes were applied and when the problem was noticed - Any screenshots or other evidence you are able to provide 🚀 How to Escalate Your Defect Case To open an engineering escalation for a Wix integration publishing defect, contact our support team directly. When you reach a teammate, clearly describe the publishing issue and provide your affected domain. Ask to have your case escalated to engineering and request confirmation of the following in writing: - Your active support ticket number or reference - Current status of the investigation - Expected next steps or resolution timeline Ask the teammate to keep your case open until the issue has been confirmed resolved on your site. 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.

🔌 Fix Intermittent Google Ads and Integration Drops

Overview If your Google Ads data appears and disappears, or your Google My Business and Search Console integrations show as connected one day and disconnected the next, you are not alone. Intermittent data visibility issues with Google integrations are a known topic our support team handles. Because the exact steps to resolve this depend on your account configuration, the best path forward is to contact our team directly so we can investigate your specific connection. What to Have Ready When You Reach Out To help our team resolve your issue as quickly as possible, please have the following information ready: - Your project or workspace name in Search Atlas where the integration issue is occurring. - Which integration is affected — Google Ads, Google My Business, or Search Console (or multiple). - A description of the pattern — for example, whether data disappears entirely, shows gaps on specific dates, or the integration flips between connected and disconnected states. - Approximate timestamps of when you first noticed the issue and any recurring times it seems to happen. - Any error messages displayed on screen — please copy the exact wording or take a screenshot. - The Google account email used to connect the integration (so our team can check the connection on the backend). What May Be Causing This Intermittent integration visibility issues can stem from several backend factors, including OAuth token state, permission changes on the connected Google account, API quota windows, or sync timing. Our support team can review your account's integration logs and connection status to identify the actual cause and apply the correct fix. 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.

🔌 Reconnect Your Yesly Integration

Overview If your Yesly integration has become disconnected — whether during an active support session or after a session was closed — our team can help you get it reconnected. Because the reconnection process for Yesly integrations is handled with agent assistance, this article explains what to expect and how to get help quickly. What to Know Reconnecting a Yesly integration is something our support team can assist you with directly. If your integration is showing as disconnected or stopped syncing, no data is lost — the connection simply needs to be restored. This can happen mid-session or at any point after a support interaction has ended. In either case, you do not need to start a new process from scratch; the team can pick up where things left off. What to Have Ready When You Contact Support To help our team reconnect your Yesly integration as quickly as possible, please have the following information ready: - Your Search Atlas account email address - The name of the workspace or project where the Yesly integration should be active - A brief description of when the disconnection occurred (e.g., during a support session, after a password change, or at an unknown time) - Any error messages you may have seen, including the exact wording if possible Next Steps Once you reach out, a member of our team will verify your integration details and restore the connection on your behalf. You will be notified once the integration is active again and syncing normally. 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.

Fix the Shopify "404 Token Exchange" Error When Connecting Your Store

If you try to connect your Shopify store to Search Atlas and see an error such as "token exchange failed" or "404 store unavailable", the cause is almost always in the Shopify app setup, not in Search Atlas. This article shows what to check. What does a 404 token exchange error mean? When you connect Shopify with a client ID and client secret, Search Atlas asks Shopify for an access token for your store. Shopify answers with a 404 when it cannot find the app on that store, or when the client ID does not match the app. This is not a routing problem on the Search Atlas side. How do I fix a 404 token exchange error? 1. In your Shopify admin, open the custom app you created and confirm it is installed on the exact store you are connecting. Installing the app is a manual step in Shopify, and an app that exists but is not installed on that store will fail. 2. Check the shop domain you entered in Search Atlas. It must be the store where the app is installed. 3. Compare the Client ID in Search Atlas with the Client ID shown in your Shopify app. Re-enter it if there is any difference. 4. Save the connector again in Search Atlas under Settings, in the CMS Connectors tab. What access permissions does the Shopify app need? If you connect with an Admin API access token instead of client credentials, the token must come from an app with the read_content and write_content access scopes. What if the error continues? Reach our team through live chat. Please send a screenshot of the error, a screenshot of your Shopify app's API access scopes, and the shop domain you are connecting. This lets the team check the connection quickly.

🔧 Troubleshooting Data Aggregator Submission Issues

This article covers data aggregator submission issues in Search Atlas. Data aggregators distribute your business information (name, address, phone number, and other key details) to directories and listing sites across the web. When a submission fails or stalls, your local presence can be affected. What Is a Data Aggregator Submission Issue? A data aggregator submission technical issue occurs when your business information fails to be distributed or processed correctly through the aggregator network. This can result in listings not appearing, outdated information persisting, or submissions remaining in an unresolved state. What to Have Ready When Contacting Support Because data aggregator submission problems are technical in nature and require backend investigation, our team will need to look into your specific account and submission records. To help us resolve your issue as quickly as possible, please have the following information ready before reaching out: - Your project or business name as it appears in Search Atlas - The specific aggregator(s) affected, if known - The exact error message or status displayed for the submission - The date and time when you first noticed the issue - Any recent changes made to your business profile or listing details prior to the issue occurring Having this information ready will allow our team to investigate your submission records and take the appropriate backend action to resolve the issue. 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.

⚡ Search Atlas WordPress Plugin Impersonation Message Explained

Overview When configuring the Search Atlas WordPress plugin, you may see a message related to impersonation. This article explains what that message means and what steps to take next. What Does This Message Mean? An impersonation message in the Search Atlas WordPress plugin indicates that the session currently connected to your plugin may be associated with an account other than your own. This can happen during or after a support or onboarding interaction where account access was involved. If you are seeing this message, it is important to pause any configuration work until the situation is clarified, to ensure that any changes you make are applied to the correct account. What You Should Do Because the exact cause of the impersonation message can vary depending on your account setup and recent activity, the best course of action is to contact the Search Atlas support team directly. A support agent will be able to review your account, explain why the message is appearing, and guide you through the correct next steps for your specific situation. When you reach out, please have the following information ready: - Your Search Atlas account email address - The name of the WordPress site where you are seeing the message - A description of what you were doing in the plugin when the message appeared - Any screenshot of the message if possible 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.

🔧 Fix WordPress Plugin Dashboard and Google Instant Indexation Issues

Overview Two common issues reported with the Search Atlas WordPress plugin are unresponsive dashboard buttons and Google Instant Indexation failing to connect or configure. If you are experiencing either of these problems, our support team will need to investigate your specific setup to identify and resolve the root cause. Unresponsive Dashboard Buttons If buttons inside the Search Atlas plugin dashboard are not responding or appear frozen, this is a known issue that may affect certain WordPress environments. Because the cause can vary between setups, our team will need to review your case directly. When reaching out, please have the following ready: - Your WordPress site URL - The exact button or area of the dashboard that is unresponsive - Any error messages visible on the page - A description of when the issue first appeared and any recent changes made to your site Google Instant Indexation Connection Failures If Google Instant Indexation is not connecting or the configuration is not completing, this is also a known issue that requires investigation by our support team. Please have the following ready when you contact us: - Your WordPress site URL - The exact step at which the connection or configuration fails - Any error messages displayed during the process - A description of the steps you have already attempted 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.

🛠️ Fix WordPress Connector Gateway Routing Errors

🔍 What Is This Error? If your WordPress connection shows a status of Active but test operations such as wordpress-get-current-user fail with a message indicating the operation is not available for WordPress, you are experiencing a gateway routing error. The connector may appear authenticated correctly, yet the test operation cannot be completed. This is a platform-level issue and cannot be resolved through user-side steps alone. ⚙️ Why Does This Happen? This error occurs at the gateway routing level within the WordPress connector. Even when the connection status shows Active, specific test operations can fail due to a routing problem that is not visible from the connector settings screen. Because the root cause is at the platform level, it requires investigation and action by the Search Atlas team. 📋 What to Have Ready When You Escalate To help our team resolve this as quickly as possible, please gather the following before reaching out: - The exact error message you are seeing (e.g. the full text stating the operation is not available) - The name of the failing operation (e.g. wordpress-get-current-user) - Your WordPress site URL associated with the connector - The date and approximate time when the error first appeared - Any screenshots of the error message or connector status screen 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.

🛠️ Loveable CMS Integration and Refunds

🔍 Why Loveable is unavailable Loveable is not currently listed as a supported CMS integration in Search Atlas. This means you cannot connect Loveable directly for publishing through the CMS options. 💡 Available workarounds You may be able to continue using your project by exporting it from Loveable and uploading the resulting ZIP or HTML files, where supported by your Search Atlas workflow. You can also connect a supported CMS if your website is available on another platform. Before choosing a workaround, confirm that your export includes the pages and assets you need. Export-based workflows may require additional setup and may not provide the same publishing experience as a direct CMS connection. 🚫 Cancel your subscription If Loveable support is essential to your workflow, you can request cancellation. Include the account details associated with your Search Atlas subscription and explain that the unavailable Loveable integration is the reason for your request. 💳 Request a refund Refund eligibility depends on your subscription and account circumstances. A refund is not automatic when an integration is unavailable, so request a review when you ask to cancel. The team can confirm the applicable options and any next steps. 💬 Contact the team 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.

🛠️ Fix WordPress Plugin Duplicates and Deployment Status

Overview Two of the most common WordPress plugin issues Search Atlas customers encounter are duplicate information appearing in the plugin and deployment statuses showing items as undeployed when they have already been deployed. What to Have Ready Before Escalating Because the specific causes and confirmed resolution steps for these issues need to be verified by our support team, please gather the following information before reaching out: - Your project name in Search Atlas where the issue is occurring. - A description of the duplicate data you are seeing — for example, which items are duplicated and where they appear in the plugin. - The exact deployment status shown for the affected items (e.g., the label or status text displayed on screen). - Any error messages displayed in the plugin or on your WordPress dashboard — copy the exact text. - The timestamp or date when you first noticed the issue. - Your WordPress site URL and the version of the Search Atlas plugin you have installed. A support team member will be able to review your account, confirm the root cause, and walk you through the correct resolution steps for your specific situation. 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.

🔌 Fix GA4 Connection Missing Data Stream

🔍 What Is This Issue? When you connect Google Analytics 4 (GA4) to Search Atlas, we need to read data from a data stream on your GA4 property. A data stream is the source that collects visitor data from your website. If your GA4 property has no data stream, the connection cannot finish. The property may be missing from the list, or the connection may fail. This can also affect how Search Atlas displays data from Google Search Console (GSC) and Google Analytics together. Some customers see this as a country or location setting that looks incomplete. ⚠️ Common Signs - Your GA4 property does not appear, or you cannot select it, when connecting Google Analytics. - The Google Analytics connection starts but never completes. - Your GSC settings in Search Atlas are set to a country such as the UK, but the dropdown in the reports only shows Worldwide and USA. - Analytics reports show no data, or a message that setup is incomplete. 🧠 Why Does This Happen? - No data stream exists. The GA4 property was created, but no web data stream was added to it. - The wrong property was chosen. You may have several GA4 properties, and the one you selected is empty or belongs to another site. - Limited permissions. The Google account you connected may not have enough access to the property. - The connection is only partly finished. If GA and GSC are not both fully connected, location options may fall back to the defaults (Worldwide and USA) until data syncs. - No data yet. A brand-new data stream needs time to collect visits before it can report them. 🛠️ Step 1: Check Your GA4 Property for a Data Stream 1. Sign in to Google Analytics with the Google account you use for Search Atlas. 2. Click Admin (the gear icon in the bottom-left corner). 3. Select the correct Account and Property for your website. 4. Under the property, open Data collection and modification, then click Data streams. 5. Check whether a web stream for your website is listed. If you see a stream with your website address, go to Step 3. If the list is empty, continue to Step 2. ➕ Step 2: Create a Web Data Stream 1. On the Data streams page, click Add stream, then choose Web. 2. Enter your website address (for example, yourwebsite.com). 3. Enter a clear stream name, such as your site name. 4. Click Create stream. Your stream is now created. For GA4 to report real visitor data, the tracking tag must also be installed on your website. Google shows you the setup instructions on the stream details page. If your site already uses Google Analytics through a website builder or plugin, you can often paste the new Measurement ID into its settings. 🔗 Step 3: Reconnect Google Analytics in Search Atlas 1. Log in to Search Atlas and open the integrations or connections area for your project. 2. If Google Analytics shows as connected but incomplete, disconnect it first. 3. Click Connect for Google Analytics. 4. Sign in with the same Google account that has access to your GA4 property. 5. Approve all the permissions requested. If a permission box is left unchecked, the connection may not finish. 6. Select your GA4 property and the data stream for your website. 7. Save your changes. 🌍 Step 4: Fix Missing Country Options (UK, for Example) If your GSC setting is set to the UK but the report dropdown only shows Worldwide and USA, work through these checks: - Finish the GA4 connection first. Complete Steps 1 to 3 above, then refresh Search Atlas. - Reconnect GSC with the same Google account. Use the account that owns both your GSC property and your GA4 property, so the two sources match. - Confirm the right GSC property. Choose the property that matches your live site address, including the correct version (domain, or with or without www). - Allow time for data to sync. After reconnecting, new data can take up to 24 to 48 hours to appear. - Check that your site has traffic from that country. Google only reports locations where your site has received impressions or visits. Your saved GSC country setting does not change the options in the report dropdown. After the connection is complete and data has synced, check the dropdown again. ✅ Step 5: Confirm Everything Is Working - Your GA4 property shows as Connected in Search Atlas. - The data stream listed matches your website. - GSC and GA both use the same Google account and website. - Reports begin to show data after the sync period. 💡 Tips to Avoid This Issue - Create your data stream in GA4 before connecting Google Analytics to Search Atlas. - Use one Google account for GA4, GSC, and Search Atlas whenever possible. - Make sure that account has Editor or Administrator access to the GA4 property. - Name your properties and streams clearly if you manage several websites. - Always accept every permission box during the Google sign-in step. 💬 Still Need Help? If you have followed these steps and the property still will not connect, or the country option is still missing after 48 hours, we are happy to help. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team. To help us resolve it faster, tell us your website address, the Google account email you connected, and what you see in the Data streams page in GA4.

📰 Fixing Inactive or Unapproved Publication Media Sites

📌 Overview If the Publication Media sites in your Search Atlas account suddenly show as Inactive or Not Approved, you are not alone. This is a common question, and in most cases the cause can be found with a few quick checks. This article explains what these statuses mean, why they appear, and what you can do about them. 🔎 What These Statuses Mean - Inactive: The site is currently not available for use. You cannot publish to it or select it for new content until it is active again. - Not Approved: The site has not passed review yet, or it was reviewed and needs changes before it can go live. These two statuses can look similar, but they usually have different causes, so it helps to know which one you are seeing. ❓ Common Reasons Sites Become Inactive When many or all of your sites become inactive at the same time, the cause is usually something that affects the whole account rather than each site individually. Common examples include: - Plan or billing changes: A plan change, a lapsed payment, or an expired subscription can pause features tied to your account, including connected sites. - Plan limits: Your current plan may allow a limited number of active sites. If you exceed that limit, extra sites may be deactivated. - Broken connection: If the link between your website and the platform was interrupted, the site can show as inactive. This can happen after a hosting change, a security plugin update, or changed login credentials. - Domain or hosting changes: Moving to a new domain, changing DNS settings, or switching hosts can disconnect a site. - Temporary system updates: Occasionally, a platform update can change site statuses until the next sync completes. 🚫 Common Reasons Sites Are Not Approved - Review still in progress: New sites often need to be reviewed before they can be used. This can take some time. - Incomplete site details: Missing or incorrect information, such as the site URL or required profile details, can delay approval. - Site not reachable: If the site is offline, password-protected, or blocking access, the review cannot be completed. - Quality or content guidelines: Sites that do not meet publishing standards may not be approved until the issues are addressed. 🛠️ Step-by-Step: What to Check First 1. Log in to your Search Atlas account and open the Publication Media section. 2. Look at the status shown next to each site. Note whether it says Inactive, Not Approved, or something else. 3. Open your account or billing settings and confirm that your subscription is active and that your plan includes the number of sites you are using. 4. Visit each affected site in your browser. Make sure it loads normally and is not offline, under maintenance, or password-protected. 5. Confirm the site URL and details saved in the platform are correct and match your current domain. 6. If you recently changed hosting, plugins, security settings, or login credentials, review those changes and reconnect the site if the platform prompts you to. 7. Refresh the page or log out and back in to make sure you are seeing the latest status. ⏱️ How Long Does Approval Take? Approval times can vary depending on the number of sites in the queue and whether any information is missing. If a site has been waiting for longer than expected and all of its details are complete, contact our team so they can look into it. ✅ Tips to Keep Your Sites Active - Keep your subscription and payment details up to date. - Stay within the site limits of your current plan. - Do not change your domain, hosting, or access settings without checking that the connection still works afterward. - Keep your site publicly accessible so it can be reviewed and verified. - Make sure site details in your account always match your live website. - Check your site statuses regularly so you can catch issues early. 💬 When to Contact Our Team Reach out if any of the following apply: - All of your sites became inactive at the same time and your subscription looks active. - You completed the checks above and the status has not changed. - A site has stayed in Not Approved status for a long time without any update. - You need help reactivating several sites at once. To help us resolve the issue faster, please include the following details in your chat: - The names or URLs of the affected sites - The status each site is showing - When you first noticed the change - Any recent changes to your plan, billing, domain, or hosting If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team. 📚 Quick Summary - Inactive usually points to an account, plan, or connection issue. - Not Approved usually means a review is pending or something needs to be fixed. - Check your subscription, plan limits, site accessibility, and site details first. - If the problem continues, contact our team through the live chat widget with the details above.

🖼️ Fix Logo Corruption After Search Atlas Pixel Install

About This Issue Some users have reported logo corruption or unexpected visual changes on their Shopify store after installing the Search Atlas tracking pixel. Our team is aware of this reported issue and is investigating the root cause. Because the exact cause can vary depending on your theme, pixel placement, and site configuration, our support team will need to review your specific setup directly in order to identify what is happening and guide you to the right fix. What to Have Ready Before Contacting Support To help our team investigate as quickly as possible, please gather the following before reaching out: - The name of your Shopify theme (e.g., Dawn, Debut, a custom theme) - The URL of the page where the logo corruption is visible - A screenshot or screen recording showing the visual issue - The date and time you first noticed the problem - Confirmation of where the pixel snippet is currently placed in your theme code (e.g., theme.liquid, a specific section file) - Any recent changes made to your theme around the time the issue started 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.

🛠️ Fix OTTO Changes Not Showing on GoHighLevel

🔍 What This Issue Looks Like You deploy a change in OTTO and the platform shows it as Deployed. But when you open your GoHighLevel website, or inspect the page, the change is not there. This is usually a setup, publishing, or caching issue, not a failed deployment. The steps below walk you through the most common causes. 💡 Why This Happens OTTO applies changes to your site through its installed script. A deployed status means OTTO has the change ready on the Search Atlas side. The change only appears on your site if the page loads the OTTO script and the page is not serving an old, saved copy. On GoHighLevel, the most common reasons are: - The OTTO script is missing from the page. GoHighLevel sites, funnels, and individual pages can each have their own tracking code settings. - The GoHighLevel page was not re-published after the script was added. - Caching. Your browser, GoHighLevel, or a CDN may be showing an older version of the page. - Domain mismatch. The domain connected in OTTO may differ from the live domain, for example www vs non-www, or a GoHighLevel preview URL vs the custom domain. - You are checking the wrong view. Some changes are applied after the page loads, so they may not appear in View Page Source. - The URL is not covered. The change may be deployed to a different page than the one you are checking. ✅ Step 1: Confirm the Deployment in OTTO 1. Open your project in OTTO. 2. Find the change you deployed and confirm its status is Deployed. 3. Check the exact page URL the change applies to. 4. Make sure the URL matches the live page you are testing, including https, www, and any trailing slash. 🧩 Step 2: Check That the OTTO Script Is Installed 1. Open the live page in your browser. 2. Right-click and choose View Page Source. 3. Search for the OTTO script from your project's installation instructions. 4. If you cannot find it, the script is not loading on that page. If the script is missing, add it again in GoHighLevel using the tracking code or header code area for the correct level. This might be site-wide settings, funnel settings, or the individual page settings. Add the same script exactly as shown in your OTTO installation instructions, and do not edit it. 🚀 Step 3: Re-Publish the GoHighLevel Page GoHighLevel often needs a fresh publish before code changes go live. 1. Save the settings where you added the script. 2. Open the page in the GoHighLevel builder. 3. Click Save, then Publish. 4. Wait a few minutes and reload the live page. If you manage several pages or funnels, check that each one has the script and has been re-published. 🧹 Step 4: Clear Caches and Re-Test 1. Open the page in a private or incognito window. 2. If the change is still missing, do a hard refresh. Use Ctrl + Shift + R on Windows or Cmd + Shift + R on Mac. 3. If you use a CDN or caching service in front of GoHighLevel, clear its cache for the affected page. 4. Test on a different device or network to rule out local caching. 🔎 Step 5: Inspect the Page the Right Way Some OTTO changes, such as titles, meta descriptions, headings, or schema, may be applied after the page loads. This means they can look different depending on how you check. - View Page Source shows the original code the server sends. It may not show changes applied afterward. - Inspect (Developer Tools, Elements tab) shows the page as the browser finally displays it. Use this view to check for OTTO changes. To check, right-click the page, choose Inspect, and search the Elements tab for the text or tag you changed. Then compare it with the change shown in OTTO. 🌐 Step 6: Verify the Domain and URL - Make sure the domain in your OTTO project is the same one visitors use to view the site. - Test the custom domain, not a GoHighLevel preview or staging link, unless the script is installed there too. - Check that the page URL has not changed since the change was created, for example after a slug edit or redirect. 📋 Quick Checklist - The change shows as Deployed in OTTO. - The OTTO script appears in the live page source. - The GoHighLevel page was saved and re-published after the script was added. - You tested in an incognito window after clearing the cache. - You used Inspect, not only View Page Source. - The domain and page URL match your OTTO project. 🛟 When to Contact Support If you have worked through the steps above and the change still does not appear, gather these details to speed things up: - The page URL where the change should appear - The change you deployed in OTTO and when you deployed it - Whether the OTTO script appears in the page source - Whether the page uses a GoHighLevel site, funnel, or custom domain - A screenshot of the OTTO deployment status and the inspected page If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.

🔍 Fixing GA4 Property and Data Stream Issues

🔍 What This Issue Looks Like You have added Google Analytics 4 (GA4) in the Integrations section of Search Atlas, but the property still won't enable, or it connects and no data stream appears. This is usually caused by a setting in your Google account, not by a problem with Search Atlas. The steps below fix most cases. Common signs include: - GA4 shows as added in Integrations, but you can't turn it on for your project. - Your GA4 property is missing from the list of available properties. - The property appears, but no data stream is listed under it. - The connection works, but reports show no data. 💡 Why It Happens Search Atlas can only read GA4 data when three things are in place. If one is missing, the connection can stall. - Correct Google account: The Google account you connected must have access to the GA4 property. - Enough permissions: The account needs at least Viewer access to the property. Editor or Administrator access is recommended. - A web data stream: The GA4 property must contain a data stream for your website. Without one, there is nothing for Search Atlas to read. ✅ Before You Start Check these quick items first: - You are using a GA4 property. Older Universal Analytics properties (IDs starting with UA-) are not supported. - You know which Google account owns or has access to the property. - You are signed in to only that Google account in your browser, or you are using a private window. 🛠️ Step 1: Confirm Your Google Account Has Access 1. Sign in to Google Analytics with the account you connected to Search Atlas. 2. Click Admin (the gear icon in the bottom-left corner). 3. Open the account and property selectors at the top. Make sure your GA4 property appears in the list. 4. If it doesn't appear, ask the property owner to add your Google email under Property Access Management with Viewer, Analyst, or Editor access. 📡 Step 2: Check That a Data Stream Exists 1. In Google Analytics, go to Admin and select your property. 2. Under Data collection and modification, click Data streams. 3. Check that a Web stream exists for your website. 4. If the list is empty, click Add stream, choose Web, enter your website URL and a name, and save. 5. Open the stream and confirm the URL matches the domain in your Search Atlas project. A new data stream can take some time to appear in connected tools. If you just created it, wait a short while before moving on. 🔄 Step 3: Reconnect GA4 in Search Atlas 1. Open the Integrations section in Search Atlas. 2. Disconnect the existing GA4 connection. 3. Reconnect GA4 and sign in with the Google account that has access to the property. 4. When Google asks for permissions, accept all of the requested permissions. If you untick any, the connection may not complete. 5. Select your GA4 property and data stream, then enable the integration for your project. 🧹 Step 4: Clear Common Browser Blockers If the Google sign-in window doesn't finish or the property list stays empty, try these fixes: - Refresh the page and try again. - Open Search Atlas in a private or incognito window. - Allow pop-ups for Search Atlas so the Google permission window can open. - Sign out of other Google accounts so the wrong one isn't selected automatically. - Temporarily turn off browser extensions that block scripts or cookies. 📊 If Connected but No Data Appears If GA4 enables but your reports look empty, check the following: - Tracking is installed: In GA4, open Reports and then Realtime. Visit your site in another tab and see whether your visit appears. - Right domain: The data stream URL should match the website in your Search Atlas project. - New property: GA4 only collects data from the time tracking starts. It doesn't import past history. Reports may take up to 24-48 hours to fill in. - Date range: Make sure the date range in your report covers a period when data was collected. 📝 Quick Checklist - The property is GA4, not Universal Analytics. - The connected Google account has Viewer access or higher. - A Web data stream exists and uses the correct domain. - You accepted all Google permissions during sign-in. - You disconnected and reconnected the integration after making changes. 💬 Still Stuck? If you've gone through the steps and GA4 still won't enable or the data stream is still missing, we're happy to help. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team. To help us resolve it faster, mention your project's domain, the Google account email you connected, and what you see on screen when you try to enable GA4.

🔧 Fix Brand Vault PDF Upload Failures

Overview When uploading a brand book or other PDF to Brand Vault, you may notice the file picker closes after selecting your file but nothing appears to upload. No error message is shown, and the file never appears in your Brand Vault. This article explains what to do if you encounter this issue. What to Have Ready Before Escalating Because the root cause of a silent PDF upload failure can vary, our support team may need to investigate on the backend. To help us resolve this as quickly as possible, please have the following ready when you reach out: - The name of your Brand Vault or the project it is associated with - The exact file name and file size of the PDF you are trying to upload - A description of what happens — for example, whether the file picker closes immediately, whether any partial progress is shown, or whether anything appears briefly before disappearing - The browser and operating system you are using - The approximate date and time when the failure occurred 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.

🔧 Fix WordPress MetaSync Sync Issues

🔎 Understand the issue If MetaSync is not detected or your site is not syncing, confirm that MetaSync is installed and active on your WordPress site. ✅ Check MetaSync 1. Open your WordPress admin dashboard. 2. Go to your installed plugins. 3. Find MetaSync and confirm that it is installed and active. 🚀 Use the OTTO script instead If MetaSync is not detected or cannot be installed, use the OTTO script as an alternative connection method. 1. Open the OTTO installation instructions in Search Atlas. 2. Copy the OTTO script provided for your site. 3. Add the script to your WordPress site as instructed. 4. Save the changes and check whether your site is detected. If the issue continues, confirm that the script was added correctly and that the site is still accessible. 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.

🔌 Fix MCP Authentication Errors

🔍 What the error means The message “Authentication succeeded, action failed” indicates that ChatGPT authentication completed, but the requested Search Atlas MCP action did not. 🛠️ What to check 1. Retry the same action. Run the MCP action again and note whether the result changes. 2. Record the failing action. Identify the specific Search Atlas MCP action that fails. 3. Capture the exact error. Save the complete message shown by ChatGPT. ✅ Before contacting support Record the exact ChatGPT error, the MCP action you attempted, and the selected Search Atlas project. Avoid sharing passwords or access tokens. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.

🛠️ Diagnose OTTO UUID Through Cloudflare

🔍 Understand the UUID warning OTTO uses a unique identifier, or UUID, to connect your website’s Cloudflare setup to the correct Search Atlas project. A “wrong UUID” message does not always mean the UUID shown in your website header is incorrect. Depending on the installation method, the UUID may be stored in a Cloudflare Worker, environment variable, route, or configuration field. It may not appear directly in the page source or header code that you inspect in your browser. 🧭 Check the installation location 1. Open AI SEO → OTTO SEO from the left sidebar. 2. Open the relevant OTTO installation or project settings. 3. Copy the UUID displayed by Search Atlas. Compare the complete value, including every letter, number, and hyphen. 4. In Cloudflare, open the account and zone connected to the website. 5. Check the OTTO Worker, its environment variables, routes, and any associated configuration for the same UUID. Do not compare the UUID only with visible header code. The browser may show a loader or script while the actual UUID is passed through the Worker configuration. ⚙️ Verify Cloudflare configuration - Confirm that you are viewing the correct Cloudflare account and website zone. - Check that the Worker is deployed and assigned to the intended route. - Confirm that the route matches the live domain and does not point to a staging or alternate hostname. - Review Worker variables and replace any outdated UUID with the current value from Search Atlas. - Save the configuration and redeploy the Worker after making changes. - Check that Cloudflare is not blocking the Worker because of account, zone, security, or plan restrictions. 🧪 Test the connection 1. Open the live website in a private browser window. 2. Test the exact domain and URL where OTTO is installed. 3. Use the browser’s developer tools to check the Network and Console tabs for failed Worker requests or connection errors. 4. Return to AI SEO → OTTO SEO and run the available scan or connection check. If the UUID matches but the warning remains, avoid repeatedly creating new Cloudflare tokens or changing unrelated settings. Repeated token creation does not correct a UUID that is being read from a different Worker setting or route. 🚧 Know the current limitation OTTO Pixel’s Cloudflare Worker setup can sometimes show a generic connection error even when token permissions appear correct. In these cases, the available message may not identify whether the issue is caused by the Search Atlas integration or a Cloudflare-side restriction. Without a specific backend error or a confirmed account or zone configuration issue, the warning cannot always be diagnosed from the visible header code alone. Record the affected domain, Cloudflare account and zone, Worker name, route, and the exact error message before requesting help. 💬 Get help with unresolved errors If the UUID matches in Search Atlas and Cloudflare, the Worker is deployed on the correct route, and the connection still fails, further investigation may be required. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.

🔌 WP OTTO Plugin Import Feature Unavailable

🔍 Overview After installing the WP OTTO plugin on your WordPress site, you may see a message indicating that the import feature is unavailable. This article explains what to do when this occurs. ✅ What You Can Do The import feature cannot be used while it is unavailable. Do not rely on the import process until the issue is resolved. If you contact support, have your WordPress site details, the exact message shown, and the time the issue occurred ready so the team can investigate the plugin behavior. 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.

🔧 Fix Shopify 404 Token Exchange Connection Error

What This Error Means When you encounter a Shopify connection 404 token exchange error in Search Atlas, it means the authentication process between Search Atlas and your Shopify store could not be completed. This is typically related to how the Search Atlas app is installed on your Shopify store. The most common cause is that the Search Atlas app is not installed on the Shopify store you are trying to connect, or the installation was not fully completed before attempting the connection. Step-by-Step Fix 1. Confirm your store URL. Make sure you are using the correct .myshopify.com domain (e.g., yourstore.myshopify.com). Custom domains may not work for this connection. 2. Verify the Search Atlas app is installed on your Shopify store. Log in to your Shopify admin and confirm the Search Atlas app is present and fully installed. If it is not installed, install it before attempting to connect again. 3. Wait for the installation to complete fully before retrying the connection. Attempting the token exchange before the app install finishes is a common cause of this error. 4. Retry the Shopify connection in Search Atlas once you have confirmed the app is installed on the correct store. Common Mistakes to Avoid - Using a custom domain instead of the .myshopify.com URL. - Trying to connect before the app installation on Shopify is fully completed. - Installing the app on a different store than the one you are trying to connect. If the Error Persists If you have confirmed the app is installed on the correct store and are still seeing the 404 token exchange error, please have the following information ready when you reach out for support: - Your .myshopify.com store URL - The exact error message you are seeing - The timestamp when the error occurred - A screenshot of the error if possible If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.

🔗 Fix an Incorrect Search Atlas Link

🔍 Identify the link problem If a Search Atlas link does not open the expected page, first check whether the address is complete and current. A link may be incorrect if it opens an error page, redirects to an unrelated location, or shows a missing workspace, project, or report. ✅ Check the link 1. Confirm that the link begins with the official Search Atlas website address. 2. Copy and paste the full link into your browser instead of selecting a shortened or partial version. 3. Check for missing characters, spaces, or punctuation at the beginning or end of the link. 4. Sign in to the Search Atlas account associated with the project or report. 5. Refresh the page and try the link again in a supported, up-to-date browser. 🛠️ Use the correct page If the link still does not work, open Search Atlas directly and navigate to the relevant workspace, project, or report from the platform menu. This can help when an older link has expired or when the link belongs to a different account or workspace. 🔒 Stay safe when opening links Do not enter your password on a page that looks unusual or does not use the official Search Atlas website address. When in doubt, close the page and access Search Atlas directly through the platform login page. 💬 Get help with a missing or incorrect link When requesting help, include the page name, the action you were trying to complete, and the error message shown. Avoid sharing passwords or other sensitive information. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.

🛠️ Fix OTTO WordPress Plugin Connection Failing

🔍 Overview When the OTTO WordPress plugin connection fails because of a stale or incorrect UUID, the plugin cannot establish a connection to Search Atlas. The issue requires the UUID associated with the connection to be reviewed and corrected. ⚠️ Why This Happens A stale or incorrect UUID is associated with the OTTO WordPress plugin connection. When this UUID does not match the expected site connection, the plugin connection cannot be completed. 🛠️ What to Do Because this issue involves the UUID associated with your OTTO connection, contact our support team for assistance. Have the following information ready: - The website domain where the plugin connection is failing. - The exact error message shown by the WordPress plugin, if available. - The approximate time when the connection failure occurred. - Your OTTO site or project name, if available. Our team can review the stale or incorrect UUID and advise on the next steps to restore the connection. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.

🔌 Fix WordPress Plugin Authentication Timeout Errors

🔑 Reauthenticate the WordPress Plugin After API Key V2

🔍 Overview Search Atlas has moved to API Key V2. After the migration, your WordPress plugin may need to be reauthenticated so it can keep communicating with your Search Atlas account. Some customers find that the Search Atlas API Key field in the plugin is locked and cannot be edited. They then wonder whether the Plugin Auth Token field should be overwritten instead. This article explains how to approach that situation safely. ❓ Why You Might See This Issue - The plugin was connected to your account before the V2 migration, so it still holds credentials from the older key. - The Search Atlas API Key field is read-only while the plugin considers itself connected, so you can't type or paste a new key into it. - The Plugin Auth Token is a separate credential the plugin uses to prove its connection. It is not the same thing as your API key. Because these are two different credentials, pasting your new V2 key into the Plugin Auth Token field is not the recommended fix. Doing so can break the connection or cause authentication errors. 🚫 What Not to Do - Do not paste your new API Key V2 into the Plugin Auth Token field. - Do not delete or edit the Plugin Auth Token manually unless a member of our team has told you to. - Do not uninstall the plugin as a first step. This is rarely needed and can remove settings you want to keep. 🛠️ Step-by-Step: Reauthenticate the Plugin 1. Log in to your Search Atlas account and open your account or API settings. 2. Locate your API Key V2. If you don't have one yet, generate a new key and copy it somewhere safe. 3. In your WordPress dashboard, go to the Search Atlas plugin settings page. 4. Look for a Disconnect, Reconnect, Reauthenticate, or similar button. Button names can vary slightly between plugin versions. 5. Select that option to clear the current connection. This should unlock the Search Atlas API Key field. 6. Paste your new API Key V2 into the Search Atlas API Key field and save. 7. Let the plugin generate a fresh Plugin Auth Token automatically. You should not need to enter this value yourself. 8. Confirm that the plugin shows a connected status and that your site data loads as expected. ✅ How to Confirm It Worked - The plugin settings page shows a connected or active status. - There are no authentication or invalid key warnings in the plugin or in your WordPress admin notices. - Your site appears correctly in your Search Atlas account. 💡 Troubleshooting Tips - The API Key field is still locked: Refresh the page and clear your browser cache. Then check again for a disconnect or reconnect option in the plugin settings. - You see an invalid key error: Make sure you copied the full key with no extra spaces at the beginning or end. Also confirm you are using the V2 key, not an older one. - The plugin still appears disconnected: Make sure the plugin is updated to the latest version from your WordPress dashboard, then repeat the steps above. - A caching or security plugin is interfering: Temporarily clear your site cache. Some security plugins can also block the connection request, so check their logs if the problem continues. 🔒 Keeping Your Keys Secure - Treat your API key like a password and never share it publicly. - If you think a key was exposed, generate a new one and reauthenticate the plugin. - Remove old keys you no longer use. 💬 Need More Help? If the API Key field stays locked, or you are unsure which field to update, please don't overwrite the Plugin Auth Token on your own. Our team can check your connection and guide you through the right step. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.

🔗 Squarespace Connector Missing on Links Issues Page

❓ What You May Be Seeing On the Issues page for Links, you may see a message such as Connect your Website on Squarespace to Search Atlas. When you click the link in that message, the screen that opens does not show Squarespace as a choice, so you cannot finish the connection. This article explains why that can happen, what to check, and how to fix your link issues while the connection option is unavailable. 🧠 Why This Happens The prompt is a reminder that Search Atlas can work more directly with your site once it is connected to your content management system (CMS). The connection screen does not always list every platform, so the prompt can appear even when Squarespace is not selectable. Common causes include: - A Squarespace connector is not available for your account or project yet. - The page did not fully load, or a browser extension is blocking part of it. - The project's website address does not match the site you are trying to connect. - You are signed in to an account or workspace that does not own the project. In most cases, you can still see and fix your link issues without the connection. The connection is a convenience, not a requirement for reviewing your issues. ✅ Quick Checks to Try First 1. Refresh the page. Do a hard refresh (Ctrl + Shift + R on Windows, Cmd + Shift + R on Mac) and open the connection link again. 2. Try a private window. Open Search Atlas in an incognito or private window. If Squarespace appears there, a browser extension or cached data was interfering. 3. Turn off blockers. Temporarily disable ad blockers or privacy extensions for Search Atlas, then reload. 4. Try another browser. Chrome, Edge, Firefox, or Safari can behave differently. 5. Confirm your project. Check that the project selected at the top of the platform is the Squarespace site you want to work on, and that the domain is spelled correctly. 6. Check your account. Make sure you are signed in with the account that created the project or has access to it. 7. Check your Squarespace role. If a connection option does appear, you will need Administrator or Owner permissions on the Squarespace site to approve it. 🛠️ Fix Link Issues Without the Connection If Squarespace still does not appear, you can fix most link problems directly in your Squarespace account. Use the Links issues list in Search Atlas as your to-do list. 1. In Search Atlas, open the Links issues page and note the affected page URL and the problem link. 2. Log in to Squarespace and open the page that contains the problem. 3. Edit the page, find the link, and click it to update or remove it. 4. For links that point to pages that no longer exist, either update the link to the correct address or set up a redirect. 5. Save and publish your changes. To create a redirect in Squarespace, go to Settings, then Developer Tools, then URL Mappings, and add a rule that sends the old address to the new one. Menu names can vary slightly depending on your Squarespace version. 🔄 Confirm the Fix - Open the page on your live site and click the link to make sure it works. - Return to the Links issues page in Search Atlas and run a new check or wait for the next scheduled update. - Confirm the issue is no longer listed. If it still appears, allow time for the site to be re-crawled. 💡 Tips to Avoid Confusion - Treat the Connect message as optional. It does not block you from seeing or fixing issues. - Use the exact page URL from the issue list when searching for the link in Squarespace. - Fix the most important pages first, such as your homepage, service pages, and top blog posts. - Keep your project domain consistent, including whether it uses www or not. 💬 Still Need Help? If Squarespace still does not appear after these checks, send us the details so we can look into your account. Include the project name, your website address, the browser you are using, and a screenshot of the connection screen. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.

🔧 WordPress Plugin Fixes and Security Updates

The latest Search Atlas WordPress plugin update (version 2.6.25) fixes several issues that affected your site's SEO output, improves compatibility with certain themes and page builders, and adds important security protections. ✨ What's New SEO output and structured data - Cleaner breadcrumbs: Breadcrumb structured data on archive pages no longer includes an invalid or incomplete item, so search engines get a clean breadcrumb trail. - Editor "Disable" switches now work fully: The six "Disable" switches in the Post/Page Editor now stop the matching output from appearing on your site's frontend. Previously, they only hid the settings box in the editor. - More reliable video sitemaps: Video sitemaps now detect video players that your theme adds when the page loads. Previously, videos could be left out of your sitemap on these themes. - Consistent SEO value priority: When you import SEO values from another plugin, OTTO's values now consistently take priority in every part of the plugin, instead of being overridden unpredictably. Compatibility and stability - Yootheme sites: OTTO no longer removes page content on Yootheme sites. Link and heading updates are now limited to Gutenberg blocks. - Local Business logo repair: If your Local Business logo value becomes corrupted, the plugin now repairs it automatically instead of continuing to show a broken logo URL. - Menu Icon setting: The Menu Icon settings field no longer causes an error when its value contains a percent sign (%). Security improvements - Stronger settings protection: The plugin's settings handling is now stricter, so submitted data can no longer bypass the checks that keep your settings safe. - OTTO Debug page disabled: The OTTO Debug page and its related functions are now fully turned off. Before, any site administrator could reach them. - Safer Whitelabel password recovery: Password recovery now sends a single-use, short-lived reset link instead of emailing your password directly. - Safer Debug Mode backups: When Debug Mode backs up your wp-config.php file, it now saves the backup safely. It no longer leaves backup files in your website's public folder that could expose sensitive information. Admin experience - Cleaner admin pages: The extra WordPress footer space is now hidden on the plugin's admin pages, giving you a tidier workspace. 🛠️ How to Use It 1. Log in to your WordPress dashboard. 2. Go to Plugins and find the Search Atlas plugin in your list. 3. If an update is available, click Update Now. 4. After the update finishes, confirm the plugin shows version 2.6.25 or later. 📋 What to Expect - Most improvements apply automatically after you update. You don't need to change any settings. - If you use the Post/Page Editor "Disable" switches, you may notice that the matching output no longer appears on your pages. This is the intended behavior. Review your switches to confirm they are set the way you want. - If your site uses a theme that adds video players at page load, your video sitemap may now include videos that were previously missing. - If you use Whitelabel password recovery, you will now receive a reset link instead of your password. The link works once and expires after a short time, so use it soon after requesting it. - The OTTO Debug page is no longer available. Use the chat widget if you need help troubleshooting. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.

🔗 Fixing Publisher Live Link Validation Failures

📌 Overview When you submit a published page to Search Atlas Publisher, our system checks that the live link works and meets the order requirements. If the check fails, you may see a validation error. In some cases your Publisher account may also show as inactive. This article explains what the error means, why it happens, and what to do next. 🔍 What Is Live Link Validation? Live link validation is an automatic check that confirms the page you submitted is really published and delivers what the order asked for. It usually looks at whether: - The page URL opens publicly without a login, password, or paywall. - The page loads correctly and does not return an error such as 404 (not found) or 500 (server error). - The required link to the customer's website is on the page. - The link points to the correct target URL and uses the correct anchor text. - The page can be indexed by search engines and is not blocked. - The page does not redirect somewhere else. If any of these checks fail, the live link is marked as not valid. ⚠️ Common Reasons a Live Link Fails - Typo or incomplete URL: The link was pasted with missing characters, extra spaces, or without https://. - Draft or staging page: The page is still a draft, scheduled for later, or on a private test site. - Page not publicly accessible: The page needs a login or is hidden behind a firewall or security rule. - Required link missing: The customer's link was left out, removed, or placed in a part of the page that does not load. - Wrong target URL or anchor text: The link goes to a different page than the one in the order, or the anchor text was changed. - Link attributes changed: The link has an attribute, such as nofollow, that does not match the order requirements. - Noindex or blocked page: The page tells search engines not to index it. - Redirects: The URL sends visitors to another page, so the system cannot find the link. - Content later edited or removed: The page was valid at first but was changed or taken down afterward. - Temporary site issue: The website was slow or offline when the check ran. 🛠️ How to Fix a Failed Live Link 1. Open the submitted URL in a private or incognito browser window. If you cannot see the page without logging in, make it public. 2. Check that the page is fully published and not a draft or scheduled post. 3. Confirm the URL is correct. Copy it directly from your browser's address bar after the page loads. 4. Find the required link on the page. Check that it is visible, clickable, and points to the exact target URL in the order. 5. Confirm the anchor text matches the order instructions. 6. Check that the page is not set to noindex and that it does not redirect to another address. 7. Wait a few minutes after publishing or making changes, then submit the live link again. If the page still fails after these steps, note the exact error message shown in the platform. It will help our team find the cause faster. 🚫 Why Does My Account Show as Inactive? A Publisher account can be set to inactive when the system or our team sees issues that affect quality or reliability. Common triggers include: - Live links that repeatedly fail validation. - Published links that are later removed, changed, or redirected. - Pages that are not accessible when re-checked. - Orders that stay incomplete past their deadline. - Profile or website details that are missing, outdated, or no longer match the site. If your account was reactivated before and became inactive again, it usually means the same issue happened again, or a new validation problem was detected on a previously submitted link. Checking all your recent and past submissions can help you find the cause. ✅ How to Get Your Account Reactivated 1. Review your recent orders and find any with a failed or flagged live link. 2. Fix each issue using the steps above, and make sure every previously approved link is still live and correct. 3. Resubmit the corrected live links in the platform. 4. Check your account status after resubmitting. 5. If the account is still inactive, contact our team and share the order numbers and URLs involved so they can review your account. 💡 Tips to Avoid Future Problems - Always test the live URL in an incognito window before submitting it. - Do not edit or remove the link after it is approved. - Keep the page public and indexable for as long as the order requires. - Avoid redirects, URL changes, or site migrations that alter the page address. - Follow the order instructions exactly, including target URL and anchor text. - Submit the live link promptly after publishing so any problem is found early. - Keep your website and profile details up to date. 💬 Need More Help? If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team. To speed things up, have the following ready: - The order number or numbers affected. - The live link URL you submitted. - The exact error message you saw. - What you have already tried.