Troubleshooting: Platform Conflicts & Caching

🛠️ How to Confirm Shopify Changes Are Live

🔌 Fix WordPress OTTO Installation and Authentication Issues

🔍 Overview Connecting WordPress to OTTO SEO requires two things: the Search Atlas WordPress plugin installed on your site, and a valid Search Atlas account linked during setup. If your site is not connecting or authentication keeps failing, this guide walks you through every step to fix it. ✅ Before You Begin Make sure the following are in place before attempting to connect: - You have admin access to your WordPress site. - You have an active Search Atlas account. - Your WordPress site is live and publicly accessible (not in maintenance mode or behind a login wall). - Your server allows outbound HTTP requests (some managed hosts block these by default). 🛠️ Step 1: Install the Search Atlas WordPress Plugin 1. Log in to your WordPress dashboard. 2. Go to Plugins → Add New. 3. Search for Search Atlas. 4. Click Install Now, then Activate. Important: The plugin does nothing on its own. It must be connected to your Search Atlas account to function. Do not skip Step 2. 🔗 Step 2: Connect WordPress via the OTTO Installation Guide 1. In Search Atlas, go to Left sidebar → OTTO SEO → Installation Guide. 2. Select WordPress as your platform. 3. Follow the on-screen instructions to generate your connection credentials. 4. Copy the credentials provided and paste them into the Search Atlas plugin settings inside your WordPress dashboard. 5. Save your settings and wait for the connection status to update. You can also add or manage connected sites by going to Left sidebar → OTTO SEO → All Sites. ⚠️ Common Reasons Authentication Fails If your site still shows as not connected or authentication is not completing, check each of the following: - Wrong credentials entered: The plugin requires the exact credentials generated in the Search Atlas Installation Guide. Do not use your Search Atlas login username or password here. - Credentials entered in the wrong field: Make sure you are pasting each value into the correct field inside the plugin settings. - Plugin not activated: Verify the plugin is active under Plugins → Installed Plugins in WordPress. - Caching conflict: If your site uses a caching plugin (e.g., WP Rocket, W3 Total Cache), clear the cache after saving the plugin settings. - Firewall or security plugin blocking the connection: Security plugins like Wordfence can block outbound requests. Temporarily disable them to test the connection, then whitelist Search Atlas if needed. - Maintenance mode enabled: Disable any maintenance mode plugin before attempting to connect. - Server-level restrictions: Some hosting providers block external API calls. Contact your host to confirm outbound requests are allowed. 🔄 Step 3: Re-authenticate If the Connection Breaks 1. Go to Left sidebar → OTTO SEO → All Sites. 2. Find the affected site and check its connection status. 3. If the status shows an error, remove the site and re-add it using the steps in the Installation Guide. 4. Generate fresh credentials and re-enter them in your WordPress plugin settings. 📊 Step 4: Verify the Connection Is Working Once credentials are saved, return to Left sidebar → OTTO SEO → Overview. Your WordPress site should appear as connected. You can then run a scan by going to Left sidebar → OTTO SEO → All Sites and clicking Scan. 💡 Tips to Avoid Connection Issues - Always generate fresh credentials from the Installation Guide — do not reuse old ones. - Check that your WordPress version and PHP version meet the minimum requirements listed in the plugin description. - If you manage multiple sites, connect each one individually through OTTO SEO → All Sites. 🆘 Still Not Connecting? If you have followed all the steps above and your WordPress site is still not authenticating, our team can investigate your specific setup. 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 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.

🛠️ Fix OTTO Project Errors After WordPress Migration

🔍 Overview When you migrate a website from WordPress to Website Studio, your existing OTTO SEO project may stop working correctly. This mismatch can cause broken tracking, errors, and project failures. Because resolving this requires backend intervention, this article explains what is happening and what to have ready when you contact our team. ⚠️ Why This Happens OTTO SEO projects are tied to a specific site configuration at the time they are created. When you migrate from WordPress to Website Studio, the underlying site structure and tracking endpoints change. The old OTTO project does not automatically update to reflect the new setup, which can lead to: - Errors when OTTO tries to communicate with the old WordPress installation - Broken internal links and tracking scripts that reference the old site - Project failures if the old and new configurations come into conflict 🚫 What Not to Do Before contacting support, avoid these common mistakes that can make the problem worse: - Do not delete the old OTTO project immediately — deleting it without proper backend cleanup can cause conflicts and corrupt site-level data - Do not create a new OTTO project before the existing issue is resolved — running two projects against the same domain can multiply errors - Do not attempt to reconnect the OTTO widget on the WordPress side — your site has moved to Website Studio and the WordPress connection is no longer valid 📋 What to Have Ready Before Escalating Because this issue requires backend action by our team, please gather the following information before reaching out so we can resolve it as quickly as possible: - The name of the affected OTTO project - The domain that was migrated (both the old WordPress domain and the new Website Studio domain, if different) - The exact error message or error code you are seeing - The date and approximate time the migration took place - Any 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.

🔍 OTTO SEO Compatibility With GoDaddy Website Marketing

🧩 What Is OTTO SEO and How Does It Work? OTTO SEO is Search Atlas's AI-powered SEO automation tool. It applies on-page optimisations, manages deployments, and integrates with your site's infrastructure to improve rankings automatically. To do this, OTTO SEO requires a technical connection to your website — either through a CMS connector (such as WordPress) or a Cloudflare Worker that can intercept and modify your site's content at the edge. ⚠️ Why OTTO SEO Does Not Support GoDaddy Website Marketing GoDaddy Website Marketing is a closed, proprietary website builder. It does not allow third-party tools to install plugins, configure workers, or access the site's underlying code in the way OTTO SEO requires. Specifically, GoDaddy Website Marketing does not support: - CMS connectors — OTTO SEO cannot integrate with GoDaddy's builder as it would with WordPress or other open platforms. - Cloudflare Workers — GoDaddy Website Marketing does not give users access to Cloudflare or equivalent edge-layer configuration, which OTTO SEO uses to deploy optimisations. Because neither integration method is available, OTTO SEO cannot activate, deploy changes, or deliver any SEO improvements on a GoDaddy Website Marketing site. Connecting OTTO SEO to this type of site will not produce results, and activation will fail. ✅ Compatible Platforms for OTTO SEO OTTO SEO works with platforms that support at least one of the required connection methods. Compatible options include: - WordPress — via the Search Atlas WordPress plugin (recommended for full feature access). - Sites hosted on Cloudflare — via Cloudflare Worker deployment, regardless of the CMS used. - Search Atlas Website Studio — built-in compatibility; no additional configuration required. Access it from the left sidebar under Website Studio. If you are considering migrating away from GoDaddy Website Marketing, moving to one of these platforms will allow you to take full advantage of OTTO SEO's automation capabilities. ❌ How to Cancel Your Search Atlas Subscription If OTTO SEO does not meet your needs because your site runs on GoDaddy Website Marketing and you do not plan to migrate, you may cancel your subscription. Follow these steps: 1. Log in to your Search Atlas account. 2. Click your avatar in the top-right corner of the platform. 3. Navigate to Billing → Plans & Top-ups. 4. Use Manage Subscription and follow the on-screen prompts to confirm. Your access will remain active until the end of your current billing period. No charges will occur after cancellation takes effect. If you experience any issues completing the cancellation steps, or if the option is not visible in your account, please reach out for immediate assistance. 💡 Consider These Alternatives Before Cancelling Before cancelling, it is worth knowing that Search Atlas offers a range of SEO tools beyond OTTO SEO that do not require a site connection, including: - Keyword research and content planning tools. - Rank tracking for any domain, regardless of platform. - Backlink analysis and competitor research. - Content Editor for writing optimised content manually. These tools can still add value even if OTTO SEO's automated deployment is not available for your site. You can explore them at any time from the left sidebar in your Search Atlas account. 🆘 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 Cache Conflicts With Hosting Providers

🔍 Overview Search Atlas OTTO applies on-page optimizations — including caching directives — to help improve your site's SEO performance. However, if your hosting provider also runs its own caching layer, these two systems can conflict. The result is often slower page load times, stale content being served, or unexpected behavior after OTTO makes changes. This article explains why the conflict happens and what to do if you experience it. ⚠️ Why This Conflict Happens Many managed hosting providers and CDN services cache your site's pages at the server or edge level. When OTTO also applies cache-related optimizations, both systems may attempt to control what gets cached and for how long. Common symptoms include: - Pages loading more slowly than before OTTO was activated - OTTO changes not appearing on the live site immediately - Mixed or inconsistent page versions being served to visitors - Core Web Vitals scores declining after OTTO deployment 🧩 How To Identify the Conflict 1. Run a speed test on a key page (e.g. using Google PageSpeed Insights or GTmetrix) before and after OTTO activation to confirm the degradation is linked to OTTO. 2. Check your hosting control panel to see whether server-level caching is active. 3. Temporarily purge all caches from your hosting dashboard and retest your page speed. If performance improves, a cache conflict is likely the cause. 🛠️ What To Do Next Because this issue involves an interaction between OTTO's optimization layer and your hosting provider's caching system, resolving it may require investigation by our engineering team. This is a known area where backend configuration changes can be needed. When contacting support, please have the following ready: - The name of the project or site affected in Search Atlas - Your hosting provider's name - A description of the symptoms you are seeing (e.g., slower load times, stale pages) - Approximate date and time when the issue started - Any speed test results or screenshots you have collected Having this information ready will help our team investigate and resolve the conflict as quickly as 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 OTTO 'Not Found' After Cloudflare Setup

Overview If you are seeing a 'not found' status after connecting your Cloudflare API token to OTTO, this may be related to how OTTO's pixel installation interacts with your custom site configuration. Because the details of this issue can vary depending on your specific site setup, our support team will need to review your case directly to identify the correct resolution. What to Have Ready Before Contacting Support To help our team resolve your issue as quickly as possible, please have the following information available when you reach out: - Your site URL where OTTO is being installed. - The exact 'not found' error message or status text shown in the platform. - A description of how you completed the Cloudflare API token connection and any steps you have already tried. - Any screenshots of the error or relevant settings pages. 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 Nameserver Errors Blocking OTTO

🔍 What This Article Covers If you recently moved your domain's nameservers to Cloudflare and now see an "invalid name server" error — or your site is completely down — this guide walks you through fixing the DNS issue first, then reconnecting OTTO. These are two separate problems that must be resolved in order. ⚠️ Understand the Two-Stage Problem Switching nameservers to Cloudflare and connecting a Cloudflare API token are different actions. When customers complete the token connection but then change nameservers without finishing Cloudflare's activation steps, two issues can appear together: - Stage 1 — Site outage: The "invalid name server" error means Cloudflare has not fully activated your domain. Your site may be unreachable until this is resolved. - Stage 2 — OTTO detection failure: OTTO cannot detect your site on Cloudflare because the domain is not yet active on Cloudflare's network. Fixing Stage 1 automatically unblocks Stage 2. Do not troubleshoot OTTO or the API token until your site is back online. Repeating OTTO or Worker steps will not resolve a nameserver activation problem. 🛠️ Stage 1 — Fix the Invalid Nameserver Error Follow these steps to complete Cloudflare domain activation: 1. Log in to your Cloudflare dashboard at dash.cloudflare.com and select your domain. 2. Go to the DNS tab. Cloudflare will display the two nameservers assigned to your account (for example, ava.ns.cloudflare.com and bob.ns.cloudflare.com). These are unique to your account — do not copy nameservers from another domain or a tutorial screenshot. 3. Log in to your domain registrar (GoDaddy, Namecheap, Google Domains, etc.) and open your domain's nameserver settings. 4. Remove all existing nameservers and enter only the two nameservers shown in your Cloudflare dashboard. Save the changes. 5. Wait for propagation. DNS changes typically take 15 minutes to a few hours, but can take up to 48 hours in some cases. Cloudflare will send a confirmation email once your domain is active. 6. Verify activation in Cloudflare. Return to your Cloudflare dashboard. The domain status should change from Pending to Active. If it still shows Pending Nameserver Update, double-check that the nameservers at your registrar exactly match what Cloudflare assigned. Common reasons for the "invalid name server" error: - Nameservers were copied incorrectly or contain a typo. - Old nameservers were not fully removed before adding Cloudflare's. - The registrar requires 24–48 hours to process the change — the error may resolve on its own once propagation completes. - A third nameserver entry was left in place alongside Cloudflare's two. ✅ Stage 2 — Reconnect OTTO After the Site Is Live Once your Cloudflare dashboard shows the domain as Active and your site loads correctly in a browser, complete the following steps inside Search Atlas: 1. In the left sidebar, navigate to OTTO SEO → All Sites (SEO Automation). 2. Open OTTO settings for your site and locate the Cloudflare integration panel. 3. Confirm your Cloudflare API token is still connected. If the token shows an error, disconnect it and reconnect using a token with Zone:DNS:Edit, Zone:Zone:Read, Workers Scripts:Edit, Workers Routes:Edit, and Workers KV Storage:Edit permissions scoped to the correct domain. 4. Click Re-detect site or save the integration to trigger a fresh detection check. OTTO will scan your now-active Cloudflare domain and confirm the connection. If OTTO still shows a detection error after your domain is confirmed active, clear your browser cache, reload the OTTO SEO page, and attempt re-detection once more before contacting support. 🔑 Cloudflare API Token — Quick Permission Check A valid token must include these permissions, or OTTO cannot read or modify your Cloudflare zone: - Zone — DNS — Edit - Zone — Zone — Read - Workers Scripts — Edit - Workers Routes — Edit - Workers KV Storage — Edit - Token must be scoped to the specific zone (domain) you are connecting, not to all accounts. To create or edit a token, go to Cloudflare dashboard → My Profile → API Tokens. 📋 Quick Checklist Before Contacting Support - Domain status in Cloudflare dashboard shows Active (not Pending). - Only two nameservers are set at your registrar — exactly as shown in Cloudflare. - Site loads correctly in a browser without errors. - Cloudflare API token has the correct permissions and is scoped to the right domain. - OTTO re-detection has been attempted after the domain became active. 💬 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.

⚠️ OTTO Cache Serving Blank Pages on WordPress (0-Byte Response)

If your WordPress front-end shows blank pages while /wp-admin and /wp-login.php still load normally, the OTTO full-page cache has likely stored an empty (0-byte) response. This article shows you how to confirm the cause using response headers and restore your site immediately. ⚠️ What a 0-Byte OTTO Cache Response Looks Like A 0-byte cached response produces a specific symptom pattern you can distinguish from a PHP crash or a hosting outage: - Every front-end URL — homepage, posts, and category pages — returns HTTP 200 with a completely blank body - The browser shows a white or empty page with no error message and no partial content - The WordPress admin (/wp-admin), login page (/wp-login.php), and REST API endpoints continue to load normally - All visitors see blank pages — the issue is not limited to one browser or account PHP errors and theme crashes typically break the admin dashboard too, or display a visible error message. A hosting outage returns a 5xx status code rather than HTTP 200. When you see HTTP 200 + blank body + working admin, check the OTTO cache first. 🔍 How to Confirm OTTO Cache Is Serving the Empty Response The x-metasync-otto-cache response header tells you whether OTTO served a page from its cache. A value of HIT combined with a blank page body confirms a 0-byte cache event. Check response headers in browser DevTools 1. Open your browser and press F12 to open DevTools, then select the Network tab. 2. Load your homepage or any blank front-end URL. 3. Click the first document request in the list and open the Headers panel. 4. Under Response Headers, locate the x-metasync-otto-cache header. If the value is HIT and the page is blank, OTTO is serving the stored 0-byte response. If the value is MISS or the header is absent, OTTO is not the cause — check your active theme and plugins instead. Check response headers with curl Run the following command, replacing the URL with your site address: curl -sI https://yoursite.com Look for x-metasync-otto-cache: HIT and content-length: 0 in the output. Both values together confirm the diagnosis. 🛠️ How to Clear the OTTO Cache and Restore Your Site Purging the OTTO full-page cache deletes the 0-byte entry and forces OTTO to re-cache a valid response on the next page visit. Your front-end returns to normal immediately after the purge. Clear the cache from the WordPress admin 1. Log in to /wp-admin — this continues to work even when the front-end is blank. 2. In the left sidebar, go to Search Atlas → Settings (OTTO cache: Clear Page Cache / Clear Post Cache / Clear all cache). 3. Click Clear All Cache and confirm when prompted. 4. Reload your front-end homepage to verify pages are rendering correctly. Clear the cache from the Search Atlas dashboard 1. Log in to app.searchatlas.com and open your site's OTTO workspace. 2. Go to Settings → Full-Page Cache. 3. Click Purge Cache and confirm. You'll see a green confirmation message when the purge completes. After purging, OTTO re-caches a fresh response the next time each page is visited. Reload a front-end URL to confirm the blank pages are resolved. 💡 Why a 0-Byte Response Gets Cached OTTO stores the HTTP response it receives the first time it crawls a page. If that initial response is empty — due to a conflict at that exact moment — the empty response is stored and served to every subsequent visitor until the cache is cleared. Common triggers include: - Page builder initialization failure: Plugins like Elementor Pro can output a blank body if a license check or asset load fails at the moment OTTO first crawls the page. - Theme activation during cache warm-up: Activating or switching a theme (such as Hello Elementor) while OTTO is building its cache can cause an empty response to be stored. - Managed hosting server rules: Hosts like WP Engine apply server-level request filtering that can interfere with OTTO's cache-crawl requests and produce a 0-byte response. - Plugin deactivation while cache is live: Deactivating a plugin that a cached page depends on causes the page to render blank, which OTTO then re-caches as valid content. ⚙️ How to Prevent Future 0-Byte Cache Events Follow these practices to reduce the risk of OTTO caching an empty response: - Clear the OTTO cache before and after any theme change, major plugin update, or hosting migration. - After any maintenance window, reload a front-end page and confirm that x-metasync-otto-cache shows HIT with visible content — not a blank page. - Exclude pages that rely on external license checks or volatile dynamic content (steps below). Exclude specific pages from the OTTO full-page cache If a specific page repeatedly triggers empty-cache events, exclude it so OTTO always serves it dynamically: 1. In /wp-admin, go to Search Atlas → Settings (OTTO cache) → Exclusions. 2. Enter the URL path (e.g., /checkout or /my-account) in the Excluded URLs field. 3. Click Save. OTTO bypasses the cache for those paths and serves them fresh on every request. Excluded pages are always served dynamically and are not affected by future 0-byte cache events. 🎯 You can now confirm a 0-byte OTTO cache event using the x-metasync-otto-cache: HIT header, restore your site by purging the cache from /wp-admin or the Search Atlas dashboard, and reduce recurrence by clearing the cache around theme and plugin changes. For more on configuring OTTO's caching rules, see the OTTO Full-Page Cache Settings article.

🔧 Fix Squarespace /home Path Duplication with OTTO

What Is the Squarespace /home Duplication Issue? Squarespace automatically assigns the path /home to your website's homepage. This means your homepage is accessible at both yourdomain.com and yourdomain.com/home, creating two separate URLs that point to identical content. For OTTO and Search Atlas tracking, this causes a duplication problem: analytics, indexing signals, and SEO data are split across both URLs instead of being consolidated under one canonical address. As a result, your Search Atlas dashboard may show inflated page counts, inconsistent crawl data, or reduced accuracy in performance metrics for your homepage. Why Squarespace Forces This Structure This behaviour is built into Squarespace's platform architecture. Squarespace treats /home as the default internal slug for your homepage and does not allow you to remove it natively. Even if your domain resolves correctly to the root URL for visitors, the /home path remains active and indexable, which means search engines and tracking tools can detect both versions. This is not an OTTO configuration error. It is a platform-level constraint unique to Squarespace that requires a specific workaround to resolve. Recommended Fix: URL Mappings Redirect The confirmed resolution for this issue is to use Squarespace's built-in URL Mappings feature to create a server-side redirect. This permanently redirects /home to your root domain, consolidating all signals to one URL. 1. Log in to your Squarespace account and open your site settings. 2. Navigate to Settings → Advanced → URL Mappings. 3. Add the following mapping on a new line: /home → / 301 4. Save your changes. 5. Return to Search Atlas and allow OTTO to recrawl your site so the updated URL structure is reflected in your dashboard. The 301 redirect tells search engines and OTTO that /home has permanently moved to the root domain. Once the crawl completes, duplication should no longer appear in your dashboard. If you are unsure how to apply this fix or if the duplication persists after completing these steps, please reach out for assistance so our team can review your specific setup. 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 SEO Revert Changes: Timeline and Cache Expectations

🔍 Why Reverted Changes May Still Appear When you revert a change in OTTO SEO — such as an H1 length update — the revert is processed on the Search Atlas side, but the updated content must travel through several layers before it becomes visible everywhere. Even after clearing your browser cache and checking in incognito mode, you may still see the old content. This is expected behavior and does not mean the revert failed. There are four distinct stages between a revert action and full visibility: OTTO processing, your browser cache, your CDN or hosting cache, and Google's search index. Each stage has its own timeline. ⚙️ Stage 1: OTTO Revert Processing Time Once you trigger a revert inside OTTO SEO, Search Atlas processes and deploys the change to your connected site. Propagation time can vary — if you have recently triggered a revert and the change does not yet appear on your live site, allow some time to pass before troubleshooting further. If the change still does not appear after a reasonable wait, please contact support so the team can confirm the revert was applied successfully on the backend. 🖥️ Stage 2: Clear Your Local Browser Cache Your browser stores copies of web pages to load them faster. Even after a revert is live, your browser may serve the old cached version. Incognito mode alone does not always bypass a cached DNS or service worker. Follow these steps to fully clear your local cache: 1. Open your browser settings and navigate to Clear Browsing Data. 2. Select Cached images and files and Cookies and other site data. 3. Set the time range to All time. 4. Click Clear data. 5. Close and reopen your browser, then revisit your site. Alternatively, perform a hard refresh by pressing Ctrl + Shift + R (Windows/Linux) or Cmd + Shift + R (Mac) on the page in question. ☁️ Stage 3: Clear Your CDN and Hosting Cache If your site uses a CDN (such as Cloudflare, Fastly, or a hosting provider's built-in cache), those services cache your pages independently of your browser. The reverted content will not appear until that cache is purged. Steps vary by provider, but the general process is: - Cloudflare: Log in to your Cloudflare dashboard → select your domain → go to Caching → click Purge Everything or purge specific URLs. - WP Engine / SiteGround / other managed hosts: Log in to your hosting control panel and use the built-in cache purge or flush tool. - WordPress caching plugins (WP Rocket, W3 Total Cache, etc.): Go to your plugin settings and click Clear All Cache. After purging, revisit your page in a new browser tab to confirm the updated content is now showing correctly. 🌐 Stage 4: Google's Search Index Even after your live site reflects the reverted change, Google's search index may still display the old version in search results. Google needs to recrawl and reindex your page before the updated content appears in search. You can speed this up by submitting a reindex request through Google Search Console: 1. Log in to Google Search Console and select your property. 2. Paste the affected URL into the search bar at the top and press Enter. 3. Click Request Indexing in the URL inspection panel. Google typically processes priority reindex requests within a few days, though it can take longer depending on your site's crawl budget and overall traffic. 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 and Squarespace Builder Sync Conflicts

Why the Sync Gap Happens OTTO deploys SEO fixes to your website outside of Squarespace's visual editor. Because Squarespace's builder manages its own content separately, it may not reflect changes that OTTO has applied. This creates a sync gap: your live site may be correct, but the Squarespace editor appears unchanged. This is expected behavior and does not mean the changes failed. To confirm what is actually live on your site, always verify by viewing the published page directly in your browser rather than relying on the Squarespace editor view. Common Conflict Scenarios Understanding when conflicts occur helps you choose the right approach before making changes. - Meta descriptions: OTTO applies an optimized meta description to your page. If you later edit the meta description inside Squarespace's editor settings and save, Squarespace may overwrite OTTO's value. - Image alt text: OTTO writes alt text to your images. If you replace or re-upload the same image inside Squarespace, OTTO's alt text may be lost. - Page titles: Squarespace controls title tags through its CMS fields. OTTO can override these, but a Squarespace save event on the same page may restore the original title tag. - Schema markup: OTTO-injected structured data lives outside Squarespace's awareness. However, duplicate schema can occur if structured data is also added manually inside Squarespace. Important: The specific conflict scenarios listed above are general patterns based on how Squarespace and OTTO interact. Your exact situation may differ. If you are unsure which scenario applies to you, please reach out to our support team so an agent can review your account directly. Best Practices: Choosing Your Deployment Method Use the following guidance as a starting point when deciding whether to let OTTO manage a fix or handle it natively inside Squarespace. Because this topic requires hands-on review of your specific site and OTTO configuration, our support team can confirm the right approach for your setup. - Let OTTO manage: Schema markup, canonical tags, robots directives, bulk alt text across many images, and technical meta tags where Squarespace provides no native control. - Use Squarespace natively: Page titles and meta descriptions on pages you actively edit and republish often. Entering these directly in Squarespace's editor fields prevents Squarespace from overwriting OTTO's values after every save. - Coordinate both: If OTTO has already deployed a meta description or title and you want to keep it, copy OTTO's exact value into the corresponding Squarespace editor field. This aligns both systems and removes the conflict. - Avoid duplication: Do not add the same structured data or meta tags manually inside Squarespace if OTTO is already managing them, as this can result in duplicate tags on your live page. Verifying Your Live Site To confirm which values are actually live on your published site, use the following methods: 1. Open the published page in an incognito or private browser window to bypass any cached versions. 2. Right-click the page and select View Page Source to inspect the raw HTML and confirm the meta tags, alt attributes, and structured data that are actually being served. If the live page source does not reflect what OTTO deployed, or if you are unsure how to interpret the results, please escalate to our support team. To help us investigate quickly, have the following ready: your project name, the specific page URL where the conflict is occurring, the exact field or tag that appears incorrect, and a screenshot or copy of what you see in both the Squarespace editor and the live 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.

🛠️ How to Confirm SEO Changes Are Live on Shopify

This article explains the difference between a change being marked as deployed inside Search Atlas and that change actually appearing on your live Shopify storefront — and gives you a clear way to confirm which has happened. 📍 What 'Deployed' Means When Search Atlas marks a change as deployed, it means the platform has attempted to write that change to your Shopify store via the integration. However, there are a few reasons the updated value may not yet be visible on your live site or in Google Search results. 🛠️ Steps to Verify Your Changes 1. Check your OTTO SEO automation dashboard in Search Atlas and confirm that the specific change (e.g., title tag or meta description) shows a deployed status. 2. Go directly to the affected page or product in your Shopify Admin and open the record. Manually check whether the title, meta description, or other field now shows the new value you set in Search Atlas. 3. If the field in Shopify Admin does not yet reflect the change, it is possible there is a sync delay between Search Atlas and Shopify. Wait a short time and check again. 4. If the field in Shopify Admin does match the new value but the change is not yet visible in Google Search results, allow 1–14 days for Google to re-crawl and re-index the page. You can speed this up by submitting the URL for re-indexing through Google Search Console. ✅ How to Confirm It Worked You have two independent checkpoints to confirm a change is truly live: - Shopify Admin check: Navigate to the affected page or product in your Shopify Admin. If the title tag, meta description, or other field displays the new value you set in Search Atlas, the write was successful. - Live page source check: Visit the live Shopify URL in a browser, right-click, and choose View Page Source. Search for the <title> tag or meta name="description" entry. If the new value appears there, your change is live to visitors and search engines. If both checkpoints still show the old value, the deployment did not complete as expected. In that case, please reach out to support and have the following ready: your project name, the specific page or product affected, the change you attempted to deploy, and the approximate date and time you made the 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 OTTO 'not_installed' Status on WordPress

🧭 Overview If your OTTO pixel appears in your page source and your holistic scores are updating, but the OTTO dashboard still shows a not_installed status, you may be experiencing a conflict between a manually inserted script and the Search Atlas WordPress plugin. This article explains what is known about this issue and what to have ready if you need to escalate. 🔍 Why This Happens OTTO uses more than one method to verify a successful pixel installation. A pixel that is manually pasted into your theme or a custom code field may fire correctly for some purposes, but it can still result in a not_installed status if the Search Atlas WordPress plugin cannot recognise the installation as valid. This type of conflict — where the pixel is technically present on the page but the status does not update — is a known issue for WordPress users who have mixed manual and plugin-based installation methods. ✅ What to Do The confirmed resolution for this issue involves removing any manually inserted OTTO pixel script and allowing the Search Atlas WordPress plugin to manage pixel installation exclusively. Having both a manual script and the plugin active at the same time is the primary cause of the not_installed conflict. To get this resolved, please have the following ready when you contact our team: - Your site URL - Confirmation of whether you have a manually inserted OTTO pixel script (e.g. pasted into your theme header or a custom HTML field) - Confirmation of whether the Search Atlas WordPress plugin is currently installed and active on your site - A screenshot of the not_installed status in your OTTO dashboard - Any error messages or unusual behaviour you have observed A support teammate will review your specific setup and guide you through the correct steps to resolve 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.

🔧 Search Atlas Cloudflare Worker: Server-Side HTML Rewriting Explained

🧭 Overview A common misconception is that Search Atlas optimization fixes are applied client-side via JavaScript, meaning bots that do not execute JavaScript — such as GPTBot (ChatGPT), ClaudeBot (Anthropic), and PerplexityBot — would never see those changes. This is incorrect. Search Atlas uses a Cloudflare Worker with HTMLRewriter to transform your HTML before the response ever leaves Cloudflare's edge servers. Every crawler, including AI/LLM bots, receives fully modified HTML in the raw HTTP response — no JavaScript execution required. ⚙️ How the Cloudflare Worker Actually Works When a request reaches your site, Cloudflare intercepts it at the edge. The Search Atlas Cloudflare Worker runs server-side using the HTMLRewriter API, which parses and rewrites the HTML response in a streaming fashion before it is delivered to the requester. This process happens entirely within Cloudflare's infrastructure — not in the visitor's browser. This is fundamentally different from a client-side script tag that injects or modifies the DOM after the browser loads the page. HTMLRewriter operates on the raw HTML bytes at the network level. The requester — whether a human browser, Googlebot, GPTBot, ClaudeBot, or PerplexityBot — always receives the final, already-modified HTML. 🗂️ HTML Elements Modified by HTMLRewriter The Search Atlas Cloudflare Worker uses HTMLRewriter to directly rewrite the following elements in your page's HTML before delivery: - <title> — Page title tags are updated to reflect optimized, targeted titles. - <meta> tags — Meta descriptions, Open Graph tags, and other metadata are rewritten at the edge. - <link rel="canonical"> — Canonical link elements are corrected or injected to prevent duplicate content signals. - <h1>, <h2>, and other heading tags — Heading content can be adjusted to align with on-page SEO recommendations. - img alt attributes — Missing or suboptimal alt text is added or updated directly in the HTML. - Schema markup (JSON-LD) — Structured data blocks are inserted or modified in the <head> or <body> of the document. Because all of these changes happen at the edge before the response is sent, no JavaScript execution is needed by the recipient to see the optimized version of the page. 🤖 What AI Crawlers Actually Receive AI and LLM crawlers such as GPTBot, ClaudeBot, and PerplexityBot send standard HTTP GET requests to fetch page content. They do not run JavaScript. However, because Search Atlas optimizations are applied before the HTTP response leaves Cloudflare, these crawlers receive the exact same fully optimized HTML that a browser would render. To confirm this yourself, you can inspect the raw HTTP response of any page on your site using a tool like curl in your terminal: - Run: curl -A "GPTBot" https://yoursite.com/your-page - Look for your updated <title>, <meta description>, <link rel="canonical">, and JSON-LD schema blocks in the raw HTML output. - These elements will reflect your Search Atlas optimizations without any JavaScript having been executed. 📍 Where to Monitor Your Optimizations in Search Atlas You can review how your pages are being optimized and track AI crawler visibility directly inside the platform: 1. In the left sidebar, navigate to AI Visibility to see how AI-driven crawlers are indexing and surfacing your content. 2. Go to Site Metrics → Overview and select Activate AI Visibility if you have not already enabled this feature for your project. 3. Use Site Metrics → Pages to inspect individual page-level metadata and confirm that your title, canonical, and schema changes are applied as expected. ❓ Frequently Asked Questions - Does Search Atlas inject a script tag to make changes? No. The Cloudflare Worker uses HTMLRewriter to rewrite HTML server-side. There is no client-side script injection involved in applying metadata, canonical, heading, alt text, or schema changes. - Do I need to update my CMS or codebase for this to work? No. The Cloudflare Worker operates independently at the network layer. Your CMS continues to serve pages as normal, and the Worker intercepts and modifies the response before it reaches any requester. - Can I verify the changes are live? Yes. Use curl or any HTTP inspection tool to fetch your page's raw HTML and confirm the optimized elements are present in the response body. - Are changes applied to every request, including cached responses? HTMLRewriter runs on responses passing through the Worker. Cloudflare's caching configuration for your site determines whether cached or fresh responses are used, but Worker transformations apply at the edge regardless. 💬 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 Script Breaking Shopify Mobile Menu

🔍 Overview When you add the Search Atlas tracking script to your Shopify theme's theme.liquid file, you may notice that your mobile menu stops rendering correctly — displaying as plain text or collapsing entirely. This is not a script placement issue or a plugin conflict. The root cause is almost always an HTML tag structure conflict, specifically an improperly nested or duplicated H1 tag introduced alongside the script snippet that disrupts how your theme renders the mobile navigation. This article explains why this happens, how to identify it, and the exact steps to fix it without affecting your tracking setup. ⚠️ Why This Happens Shopify themes use Liquid templating to build page structure dynamically. The mobile menu is typically rendered inside a conditional Liquid block that is sensitive to the surrounding HTML structure. When the Search Atlas script snippet is pasted into theme.liquid with an extra or misplaced <h1> tag in the surrounding markup, the browser's HTML parser attempts to auto-correct the broken structure. This correction shifts or closes elements the mobile menu depends on, causing it to render as unstyled text instead of an interactive component. Common triggers include: - Copying the script from a source that included an accidental <h1> wrapper or heading tag around the snippet - Pasting the snippet inside an existing heading element in the liquid file - A theme that already has a strict heading hierarchy that breaks when a second <h1> is introduced before the menu block ✅ How to Diagnose the Conflict 1. Open your Shopify Admin and go to Online Store → Themes → Edit Code. 2. Open theme.liquid and locate the Search Atlas script you inserted. 3. Inspect the lines immediately before and after the script snippet. 4. Look for any <h1> or other block-level HTML tags that are either unclosed, duplicated, or wrapping the script tag. 5. As a quick test, temporarily remove the script snippet, save, and check whether the mobile menu renders correctly on a mobile viewport. If the menu is restored, the script insertion point or surrounding markup is the cause. 🔧 How to Fix the Issue 1. In theme.liquid, locate the Search Atlas script snippet you previously inserted. 2. Ensure the snippet looks exactly like this — a clean, standalone script tag with no extra HTML elements wrapping it: - Correct format:<script src="YOUR_SEARCH_ATLAS_SCRIPT_URL" defer></script> - Incorrect format: Any version where the script tag is placed inside or immediately after a <h1>, <h2>, or other heading tag 1. Place the script snippet inside the <head> section of theme.liquid, just before the closing </head> tag. This is the safest insertion point and avoids conflicts with Liquid blocks that control navigation rendering. 2. Delete any stray <h1> tags or other block-level HTML that was pasted alongside the script. 3. Save the file and reload your storefront on a mobile device or using your browser's mobile emulator to confirm the menu renders correctly. 📋 Best Practices for Script Installation in Shopify - Always paste into the <head> section — avoid placing scripts inside Liquid conditional blocks, navigation sections, or content areas. - Check for extra markup — when copying a script from any source, paste it first into a plain-text editor to strip any hidden formatting or extra HTML tags before inserting into your theme file. - One H1 tag per page — Shopify themes expect a single <h1> per page template. Introducing a second one in theme.liquid can cause cascading layout issues including broken navigation. - Test on mobile after every theme code change — mobile menus in Shopify themes are among the most fragile elements when HTML structure is altered. - Back up your theme before editing — in Shopify Admin, duplicate your active theme before making any code changes so you can restore it instantly if something breaks. 🚫 What This Issue Is Not This mobile menu problem is specifically caused by an HTML tag structure conflict. It is not related to: - Script placement conflicts similar to WordPress plugin issues - The OTTO Pixel installation method or OTTO SEO settings - Shopify app conflicts or theme app extensions - Search Atlas account permissions or tracking configuration If you have already tried adjusting script placement or reviewed your OTTO Pixel setup and the menu is still broken, return to the HTML structure check in the diagnosis steps above — that is the correct path to resolution. 💬 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.

🌐 Export Website Studio Pages to Permanent Hosting

Overview If you want landing pages you build in Website Studio to remain live independently — on your own domain and hosting — you will need to export them and deploy them to an external host. This article also covers multi-location Google Business Profile (GBP) configuration once your pages are permanently hosted, a common workflow for service-area businesses and agencies managing multiple locations. How to Export Your Landing Page from Website Studio To export a landing page from Website Studio, follow these steps: 1. Open Website Studio from your Search Atlas dashboard and navigate to the project containing the landing page you want to export. 2. Open the landing page, then look for the Export or Download option within the page editor. This will package your page as a set of static files (HTML, CSS, and assets). 3. Save the exported ZIP file or folder to your computer. Deploying to Your Hosting Provider Once you have your exported files, choose your preferred hosting method below: - Netlify or Vercel (recommended for simplicity): Drag and drop your exported folder directly onto the Netlify or Vercel dashboard at netlify.com or vercel.com. Your page will be deployed instantly with a temporary URL. To attach your custom domain, go to Domain Settings in your Netlify or Vercel project and add the domain you own, then update your DNS records as instructed. - cPanel (traditional web hosting): Log in to your cPanel account and open File Manager. Navigate to the public_html folder (or the subdirectory for your domain/subdomain). Upload the exported HTML, CSS, and asset files. Your page will be live at your domain once the files are in place. - FTP upload: Connect to your host using an FTP client (such as FileZilla) with the credentials provided by your hosting provider. Upload the exported files to the correct public directory for your domain or subdomain. After uploading, visit your domain in a browser to confirm the page is loading correctly. Allow up to 48 hours for DNS changes to propagate if you recently pointed a domain or subdomain to your hosting. Configuring a Multi-Location Google Business Profile (GBP) If you are a service-area business or agency managing multiple locations, you can connect each hosted landing page to a separate GBP location. Follow these steps: 1. Log in to Google Business Profile Manager at business.google.com and select the location (or create a new location) you want to associate with your hosted page. 2. In the location's profile settings, set the Website field to the permanent URL of the landing page you just deployed (for example, https://yourdomain.com/location-name). 3. If you are adding a new location for a service-area business, enter the service area instead of a storefront address, then complete the GBP verification process (postcard, phone, or video verification as prompted by Google). 4. Repeat this process for each location, pointing each GBP listing to the corresponding hosted landing page URL. Keeping each location's GBP website URL pointed to a stable, permanently hosted page — rather than a temporary Search Atlas preview URL — helps maintain local SEO consistency across all your locations. What to Have Ready if You Need Help If you run into issues during export or deployment, please have the following ready when contacting support: - The name of the Website Studio project or landing page you want to export - Your preferred hosting provider (for example, Netlify, Vercel, cPanel, or another provider) - The domain or subdomain where you want the page to be permanently hosted - Whether you also need help configuring a multi-location Google Business Profile for the hosted page - Any error messages or screenshots you have encountered while attempting the export 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 Script Unexpected Text on Shopify

🔍 What Is Happening? When the OTTO script is active on a Shopify store, some themes display unexpected or duplicate text on the homepage — often near the logo or top of the page. This happens because OTTO reads and interacts with the semantic HTML structure of your theme, and certain header layouts can cause it to surface hidden or unintended text content. This is not caused by where the OTTO script is placed in your theme.liquid file. The root cause is almost always how your logo or site title is wrapped inside header.liquid. 🧩 Why header.liquid Is the Cause Many Shopify themes wrap the store logo inside an tag on the homepage for SEO purposes. This is a common and valid pattern. However, some themes include visible text inside that tag alongside the logo image — such as the store name as a text fallback. When OTTO scans the page for heading structure, it reads that text as meaningful on-page content and may surface or interact with it in unexpected ways, causing it to appear visually on the page. Common scenarios that trigger this issue: - The logo is wrapped in an that also contains plain text (e.g., the store name as a fallback). - The text inside the is hidden with CSS but not removed from the DOM, making it invisible to visitors but readable by scripts. - A wrapping the logo contains text nodes that OTTO interprets as heading content. 📋 How to Diagnose the Problem Before editing any files, confirm the issue is coming from the header area: 1. Look at your Shopify homepage with the OTTO script active. Note exactly where the extra text appears — is it near the logo, top navigation, or banner area? 2. Right-click the unexpected text in your browser and select Inspect to open browser developer tools. 3. Check whether the text is inside an tag or a wrapper element directly surrounding your logo. 4. In your Shopify admin, go to Online Store → Themes → Edit Code and open the header.liquid file (or sections/header.liquid depending on your theme). 5. Search for <h1 inside the file and review what content is nested within it. ✅ How to Fix the Issue Once you have identified the problematic element in header.liquid, apply one of the following fixes depending on your theme structure: Option 1 — Remove visible text from inside the logo wrapper 1. In your header.liquid file, locate the tag wrapping your logo. 2. If there is plain text (such as your store name) sitting alongside the logo image tag, remove the text node or replace it with an empty string. 3. Save the file and reload your homepage to confirm the extra text is gone. Option 2 — Use an aria-label instead of visible text 1. If the text inside the is serving an accessibility purpose (screen reader label), replace it with an aria-label attribute on the or the anchor tag inside it. 2. For example: with only the image tag inside — no visible text. 3. This keeps your store accessible without exposing text that OTTO can surface. Option 3 — Visually hide the text correctly 1. If a previous developer hid the text using display: none or visibility: hidden, OTTO may still read it. Use a proper visually-hidden CSS class instead (sometimes called sr-only). 2. A visually-hidden element uses position: absolute; width: 1px; height: 1px; overflow: hidden; clip: rect(0,0,0,0); — this keeps it available to screen readers but out of the normal document flow that OTTO processes. ⚙️ Verify OTTO Is Still Working After the Fix 1. In the Search Atlas platform, go to OTTO SEO using the left sidebar. 2. Open your connected Shopify site and run an OTTO scan to confirm all optimisations are still being applied correctly. 3. Check your homepage in the browser with the OTTO script active to confirm no unexpected text remains. 4. Review your H1 tag in OTTO's on-page recommendations to ensure the homepage heading structure is being read as intended. 🚫 What Not to Do - Do not move the OTTO script from its current position in theme.liquid — script placement is not the cause of this issue and relocating it will not fix it. - Do not delete the tag around your logo — this tag carries SEO value on the homepage and should be preserved. - Do not hide text with display: none alone — some scripts, including OTTO, can still access and process text hidden this way. 💬 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.

🔌 OTTO Cache Plugin Third-Party Compatibility Guide

🧩 Overview The OTTO cache plugin installs a header script on your site to enable AI-driven SEO automation. If your site already uses a third-party caching system — such as BionicSpeed — the two layers can sometimes conflict, causing slower load times, stale pages, or script delivery issues. This article explains how those conflicts occur and walks you through a structured self-diagnosis process. ⚙️ How the OTTO Cache Plugin Works When you activate OTTO on a site, Search Atlas injects a lightweight header script into your site's HTML. This script communicates with OTTO's automation engine to apply on-page SEO changes in real time. Because the script lives in the of each page, it must load before most other page elements — including cached versions served by third-party systems. If a third-party cache (like BionicSpeed) serves a fully pre-built HTML snapshot, the OTTO header script may be excluded, delayed, or duplicated, depending on how that cache layer captures and replays pages. ⚠️ Common Conflict Symptoms - OTTO changes are not appearing on the live site even after activation. - Page speed scores have dropped noticeably since installing the OTTO plugin. - The OTTO header script appears more than once in your page source. - BionicSpeed reports cache misses or unusually high bypass rates. - Your site's HTML source shows an outdated version of the OTTO script tag. 🔍 How to Test for a Cache Conflict Yourself Follow these steps in order. Each step isolates a specific part of the problem so you can pinpoint the cause quickly. 1. Check your live page source. Open your site in a browser, right-click anywhere on the page, and select View Page Source. Search for the OTTO script tag (it will reference Search Atlas or OTTO). Confirm it appears exactly once, inside the tag, near the top. 2. Compare cached vs. uncached output. Load your page normally, then reload it with cache bypassed by appending a unique query string to the URL — for example, ?nocache=1. If the content or script differs between the two versions, BionicSpeed is serving a snapshot that does not include the current OTTO script. 3. Check response headers for cache status. Open your browser's Developer Tools (F12), go to the Network tab, reload the page, and click on the main HTML document. Look at the response headers for values like X-Cache: HIT or X-BionicSpeed-Cache: cached. A HIT means BionicSpeed served a stored copy — the OTTO script may not have been present when that copy was captured. 4. Temporarily disable BionicSpeed caching. Pause or disable BionicSpeed on one test page, then reload that page and check the source again. If the OTTO script now appears correctly and your SEO changes are visible, this confirms a cache layer conflict. 5. Test site speed before and after. Use a tool such as Google PageSpeed Insights to run a speed test with BionicSpeed active, then run the same test with it paused. A significant speed difference on the same page points to an integration issue rather than an OTTO script problem on its own. 🛠️ Recommended Fixes Once you have confirmed a conflict exists, use the following approaches to resolve it. - Exclude the OTTO script from BionicSpeed's cache capture. In your BionicSpeed settings, add the OTTO script URL or its containing tag pattern to the exclusion or bypass list. This tells BionicSpeed not to cache that element, so OTTO always delivers a fresh version. - Set cache rules to exclude OTTO-activated pages. If OTTO is active on specific URLs, configure BionicSpeed to bypass caching entirely for those URLs. This guarantees OTTO's real-time changes are always served to visitors. - Adjust cache expiry times. If full exclusion is not possible, reduce the cache TTL (time to live) for pages where OTTO is active. A shorter TTL means BionicSpeed refreshes its snapshot more frequently, reducing the window where an outdated OTTO script is served. - Reinstall the OTTO header script. Navigate to Left sidebar → OTTO SEO → All Sites (SEO Automation) (URL: /seo-automation-v3), locate the affected site, and verify the plugin installation status. If the script shows as inactive or errored, deactivate and reactivate OTTO for that site to force a fresh script injection. ✅ How to Confirm the Conflict Is Resolved 1. Re-enable BionicSpeed after applying your chosen fix. 2. Clear all BionicSpeed cached pages so fresh snapshots are captured. 3. View the page source again and confirm the OTTO script appears once, in the correct position, with no duplication. 4. Run a PageSpeed Insights test and compare results to your pre-fix baseline. 5. Verify that any OTTO SEO changes you previously activated are now visible on the live site. 📋 Important Notes - The steps above apply to BionicSpeed but follow the same logic for other third-party caching systems (WP Rocket, LiteSpeed Cache, Cloudflare, etc.). Look for cache exclusion or bypass settings in each tool. - Do not install the OTTO plugin and a conflicting caching plugin at the same network or server level without configuring proper exclusions — both systems will attempt to control how HTML is delivered to browsers. - If you update your BionicSpeed configuration, always purge the cache afterwards so stale snapshots do not persist. 💬 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 IndexNow Key Not Found Error in WordPress

🔍 Overview When activating Bing IndexNow through OTTO on a WordPress site, some customers encounter an "Index Now key not found" error (HTTP 400). This happens even when the Search Atlas WordPress plugin is correctly installed and a CMS Connector connection is active. This article explains why the error occurs and how to resolve it. ⚠️ Why This Error Happens Bing's IndexNow verification process requires your site to serve a plain-text key file at a specific URL. The error is triggered when Bing cannot access that file. Common causes include: - Your server uses nginx and returns a 403 Forbidden response for .txt files in the site root. - A server-level rule blocks direct access to root-level text files. - A caching layer or CDN intercepts the request before the key file can be served. - The key file was not yet written to disk at the moment Bing attempted verification. - A previous plugin version did not include the virtual serving or keyLocation fallback logic now required for certain hosting environments. ✅ Step-by-Step Fix 1. Update the Search Atlas WordPress plugin. Go to your WordPress dashboard, navigate to Plugins → Installed Plugins, and check for an available update to the Search Atlas plugin. Install the latest version — it includes a fix that serves the IndexNow key file virtually and adds a keyLocation fallback for nginx hosts that previously returned 403 errors. 2. Verify the key file is accessible. After updating, open a browser and go to https://yourdomain.com/<your-indexnow-key>.txt. Replace <your-indexnow-key> with the actual key shown in OTTO. The page should return a plain-text response containing only the key string. If you see a 403 or 404, proceed to the next steps. 3. Check nginx or .htaccess rules. If your host uses nginx, ask your hosting provider to confirm that .txt files in the web root are not blocked. If your host uses Apache, open your .htaccess file and look for any Deny or FilesMatch rules that may block .txt access. 4. Purge your cache. If you use a caching plugin (WP Rocket, W3 Total Cache, LiteSpeed Cache, etc.) or a CDN (Cloudflare, etc.), purge all cached files. Cached 404 or 403 responses can prevent Bing from seeing the key file even after the plugin is updated. 5. Retry activation in OTTO. In the Search Atlas platform, go to OTTO SEO (left sidebar) and open your site's OTTO dashboard. Navigate to Indexing → Bing IndexNow and click Activate (or Retry) to trigger a fresh key verification. 🔎 Confirm the Fix Worked After retrying activation, OTTO will show a green active status next to Bing IndexNow when verification succeeds. If the status remains red or the error persists, use the troubleshooting checklist below before contacting support. 📋 Troubleshooting Checklist - Plugin is updated to the latest Search Atlas version. - Key file URL returns HTTP 200 with plain-text key content in a browser. - No nginx location block or .htaccess rule blocks root .txt files. - Site cache and CDN cache have been fully purged. - WordPress site is publicly accessible (not behind basic auth or maintenance mode). - OTTO activation was retried after completing all steps above. 💬 Still Seeing the Error? If you have completed every step above and the "Index Now key not found" error still appears, our team can investigate your specific 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.

🛠️ 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 Noindex on WordPress Blog Page

🔍 Overview If your WordPress /blog/ (or Posts page) is showing a noindex, nofollow robots meta tag even though your per-page settings and Yoast SEO are set to index, OTTO may be deploying a conflicting robots directive. This article explains why this happens and walks you through the steps to fix it. ⚙️ Why This Happens WordPress has a special page type called the Posts page (also known as the blog index). This is the page you assign under Settings → Reading → Your homepage displays → A static page → Posts page. It behaves differently from a standard post or page — it has no editable content in the WordPress editor, and some SEO plugins treat it as a virtual or system page. OTTO can sometimes apply a noindex, nofollow robots meta tag to this page type due to one or more of the following reasons: - OTTO detects the Posts page as a non-canonical archive or paginated index and applies conservative indexing rules automatically. - A previously deployed OTTO configuration included a noindex directive that is now persisted, even if you have since updated your settings. - A conflict exists between OTTO's deployment layer and another active SEO plugin (such as Yoast SEO), where OTTO's output takes precedence at the rendering layer despite the plugin showing the correct settings. 🔎 How to Confirm the Issue 1. Visit your /blog/ URL in a browser and open View Source (Ctrl+U or Cmd+U). 2. Search for robots in the source code. 3. Check whether the rendered meta tag reads noindex, nofollow — if it does, and your Yoast or plugin settings say otherwise, OTTO is likely overriding them. 4. Also check the page in Google Search Console under URL Inspection to confirm what Googlebot sees. 🛠️ Steps to Fix the Issue 1. Log in to your Search Atlas account and navigate to Left sidebar → OTTO SEO. 2. Locate the OTTO project connected to your WordPress site and open it. 3. Find the deployment settings for your Posts page / blog index URL (typically /blog/ or whichever URL is set as your Posts page). 4. Check whether a robots meta deployment is active for that URL. If a noindex directive has been deployed, update it to index, follow and redeploy. 5. If no explicit robots setting is configured inside OTTO but the noindex is still appearing, this indicates a persisted deployment from a previous OTTO configuration. In this case, use the Disable OTTO toggle for that specific page to suppress OTTO's output, then re-enable it after clearing the cached deployment. 6. After making changes, purge your WordPress cache (via your caching plugin or hosting provider) and wait a few minutes before re-checking the rendered source. 7. Re-run the URL Inspection in Google Search Console and request re-indexing once the correct index, follow tag is confirmed in the source. 💡 Important Notes - The Posts page is not editable in the WordPress block editor. This means per-page Yoast settings may not apply in the same way as regular pages. Always verify the rendered output in View Source rather than relying solely on plugin UI settings. - If you are running Yoast SEO, Rank Math, or another SEO plugin alongside OTTO, there may be a conflict where OTTO's deployment layer outputs its own robots tag independently of the plugin. OTTO's tag will typically appear separately in the and may take precedence with crawlers even if the plugin tag looks correct. - Disabling OTTO on a per-page basis while a bug fix is in progress is a safe interim step — your Yoast or Rank Math settings will then control the robots meta for that URL. 🚀 Prevention Tips - After any new OTTO deployment, spot-check critical pages — especially your homepage, blog index, and key category pages — by viewing the rendered source directly. - Use Google Search Console's URL Inspection tool regularly to confirm what Googlebot sees, not just what your plugin settings display. - When assigning a Posts page in WordPress Settings → Reading, note that URL in your OTTO configuration and verify its robots settings are explicitly set to index, follow. 💬 Still Seeing the Issue? If you have followed all the steps above and the noindex tag is still appearing on your WordPress Posts page, 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.

🔧 Fix Webflow OTTO Connection Conflicts on Your Site

🧭 Overview Connecting OTTO SEO to a Webflow site requires a specific installation method. Because Webflow restricts how custom code is injected, using the wrong method — or mixing two methods — creates a conflict that blocks both OTTO activation and Google Search Console (GSC) verification. This article explains why this happens and how to fix it. ⚠️ Why the Conflict Happens OTTO can be connected to your site in two ways: - Google Tag Manager (GTM) — the pixel fires through an existing GTM container. - JavaScript Pixel — the pixel is pasted directly into your site's code. Webflow sites frequently have both GTM and a custom code section active at the same time. If the OTTO pixel is present in both locations, the duplicate tags conflict with each other. This causes OTTO to fail its site verification check and prevents GSC from confirming site ownership, even if you have followed the setup video exactly. 🔍 How to Diagnose the Conflict 1. In your browser, open your Webflow site and press Ctrl + U (or Cmd + U on Mac) to view the page source. 2. Press Ctrl + F and search for your OTTO pixel ID or the Search Atlas script tag. 3. If the pixel appears more than once in the source, you have a duplicate conflict. 4. Also check whether a GTM container script (GTM-XXXXXXX) is present — this confirms GTM is active on the page. 🛠️ How to Fix the Conflict You must choose one installation method and remove the other completely. We recommend the method that matches how your site is already set up. Option A — Use GTM only (recommended if GTM is already on your site): 1. Log in to your Google Tag Manager account. 2. Open the container for your Webflow site. 3. Create a new Custom HTML tag and paste the OTTO JavaScript pixel inside it. 4. Set the trigger to All Pages and publish the container. 5. Go to your Webflow Designer, open Site Settings → Custom Code. 6. Delete any Search Atlas or OTTO script tags from the Head Code and Footer Code fields. 7. Save and publish your Webflow site. Option B — Use the JavaScript Pixel only (recommended if you do not use GTM): 1. Go to your Webflow Designer, open Site Settings → Custom Code. 2. Paste the OTTO JavaScript pixel into the Head Code field. 3. Make sure the same pixel is not also firing through GTM. Open GTM and delete or pause any existing OTTO/Search Atlas tags. 4. Save and publish your Webflow site. 📊 Reconnect OTTO and Verify GSC After cleaning up the duplicate, complete the reconnection in Search Atlas: 1. In the left sidebar, go to OTTO SEO and open SEO Automation (URL: /seo-automation-v3). 2. Select your project and open the OTTO SEO settings. 3. Click Verify Site. OTTO will re-check for the pixel on your live Webflow URL. 4. Once OTTO verification passes, return to Google Search Console and run the ownership verification again. GSC reads the same pixel tag, so it should now confirm successfully. Important: Always click Publish in Webflow after making any custom code changes. Webflow does not push code changes to your live site until you publish — this is the most common reason verification appears to fail even after following the steps above. ✅ Quick Checklist Before You Verify - The OTTO pixel appears exactly once in your live page source. - You are using only one installation method (GTM or JavaScript, not both). - Your Webflow site has been published after the code change. - You are verifying the exact URL added to your Search Atlas project (www vs. non-www matters). - Your GTM container is published, not just saved, if you are using the GTM method. 💬 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 Unexpected Text on Shopify Homepage from OTTO

🔍 What Is Happening? When the OTTO SEO script is active on your Shopify store, you may notice unexpected or unfamiliar text appearing on your homepage. This is typically caused by OTTO injecting SEO content — such as meta descriptions, structured data labels, or optimised copy — directly into your page in a way that becomes visible to visitors rather than staying hidden in the page source. This is a known compatibility issue between the OTTO script and certain Shopify themes, and it can be resolved by following the steps below. ⚙️ Why This Happens OTTO automates on-page SEO by deploying a JavaScript snippet to your site. In most cases this works seamlessly, but some Shopify themes render JavaScript output in unexpected locations. When that happens: - SEO-optimised text meant for search engines appears as visible copy on the page. - Structured data or hidden schema markup gets displayed in plain text. - Injected content lands outside its intended HTML container. The root cause is usually a theme conflict rather than a fault with OTTO itself, but the fix is straightforward. 🚀 How to Fix It: Step-by-Step 1. Pause OTTO for the affected page. Log in to Search Atlas, navigate to OTTO SEO in the left sidebar and open SEO Automation (or go to /seo-automation-v3), find the affected URL, and temporarily disable OTTO automation for that page to stop new content from being injected while you troubleshoot. 2. Check your Shopify theme for stray text. In your Shopify admin, go to Online Store → Themes → Edit Code. Open your homepage template (usually index.liquid or sections/main-index.liquid) and look for any plain text that does not belong — this may be content OTTO injected that the theme rendered visibly. 3. Remove any stray injected content. If you find unexpected text in the theme files that was added by OTTO, carefully delete only that text. Do not remove any theme code. Save the file and preview your homepage to confirm the text is gone. 4. Clear your Shopify cache. In some cases, the old content may still appear due to caching. Use a hard refresh (Ctrl + Shift + R on Windows, Cmd + Shift + R on Mac) or clear your browser cache, then reload the page. 5. Re-enable OTTO with script placement review. Before turning OTTO back on for this page, return to OTTO SEO in the left sidebar of Search Atlas and open SEO Automation to review the script placement settings for your Shopify integration. Ensure the script is set to inject into the section only, not the body or a theme section block. 6. Test on a duplicate theme first. If you are unsure about any changes, duplicate your Shopify theme before making edits. This gives you a safe fallback if something goes wrong. ✅ How to Confirm the Issue Is Resolved After completing the steps above, verify the fix by doing the following: - Visit your Shopify homepage in an incognito or private browser window to see it without cached data. - Confirm no unexpected text is visible anywhere on the page. - Use a tool such as Google's Rich Results Test or View Page Source to confirm that OTTO's SEO content is present in the source code but not rendered visibly. - Re-enable OTTO automation for the page and monitor for 24 hours to ensure the issue does not return. 🛡️ How to Prevent This in the Future - Always test OTTO on a staging or duplicate theme before applying changes to your live Shopify store. - Review theme update notes — Shopify theme updates can change how JavaScript is rendered and may reintroduce this conflict. - Check OTTO deployment settings in Search Atlas after any major Shopify theme change to ensure script placement is still correct. 💬 Still Seeing the Issue? If the unexpected text persists after following these steps, or if you are not comfortable editing theme files, do not make further changes on your own. 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 Squarespace /home Redirect with OTTO

🔍 Understanding the Squarespace /home Issue Squarespace automatically redirects your root domain (yourdomain.com) to yourdomain.com/home. This behaviour is built into Squarespace's platform and cannot be disabled from within Squarespace itself. When OTTO crawls and optimises your site, this forced redirect can cause it to treat / and /home as two separate pages, leading to duplicate content signals and index confusion. This is a known platform-level limitation with Squarespace, not a bug within OTTO. The sections below explain how OTTO currently handles this and what steps you can take to minimise its impact. ⚙️ How OTTO Handles the /home Redirect OTTO's infrastructure recognises the /home redirect pattern common to Squarespace sites. When OTTO detects this redirect during its crawl, it attempts to consolidate signals from both URLs and treat the root domain as the canonical home page. However, depending on your site's configuration, some duplication flags may still surface in your reports. This is expected behaviour while Squarespace enforces the redirect at the server level. 📊 What You May See in Your Reports - Duplicate page warnings — OTTO or your audit report flags both / and /home as separate URLs with identical content. - Index coverage issues — Google Search Console may show both variants being crawled or indexed. - Home page listed twice — Your site's internal link structure may reference both versions of the URL. These findings do not necessarily indicate a critical SEO problem, but resolving them will improve your site's clarity for search engines. 🚀 Steps to Reduce Duplication Impact 1. Set a canonical tag on your home page. In Squarespace, navigate to Pages → Home Page → SEO Settings and ensure the canonical URL points to your root domain (yourdomain.com/), not yourdomain.com/home. This tells search engines which version is authoritative. 2. Update your internal links. Check that all internal links pointing to your home page use the root domain format (yourdomain.com/) rather than the /home variant. Consistent internal linking reinforces the canonical signal. 3. Submit your preferred URL to Google Search Console. Use the URL Inspection tool in Google Search Console to request indexing of yourdomain.com/ and confirm it is the version Google recognises as canonical. 4. Re-run an OTTO crawl after making changes. In Search Atlas, go to OTTO SEO → All Sites (SEO Automation) in the left sidebar, then trigger a new crawl of your site. This allows OTTO to pick up your updated canonical signals and refresh its analysis. 5. Monitor your index coverage report. After a few days, revisit Google Search Console to confirm that only the preferred URL is being indexed and that duplicate warnings have been resolved. 💡 Squarespace Platform Limitations to Keep in Mind Because the /home redirect is enforced by Squarespace at the infrastructure level, neither OTTO nor any third-party SEO tool can fully prevent Squarespace from issuing this redirect. The steps above represent the most effective workarounds available within Squarespace's constraints. Squarespace has historically maintained this behaviour across plan types, so it is important to manage it proactively rather than waiting for a platform change. If Squarespace releases an update that allows users to disable or modify the /home redirect, OTTO's integration will continue to adapt accordingly. Search Atlas monitors these platform changes and updates OTTO's crawl logic as needed. 🛠️ Still Seeing Issues After Following These Steps? If you have completed all the steps above and are still experiencing duplication warnings or unexpected behaviour with your Squarespace home page in OTTO, our team is here to help investigate your specific site 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 Stuck OTTO Scans on SiteGround Hosting

🔍 Why OTTO Scans Get Stuck on SiteGround SiteGround uses aggressive server-side caching and security rules that can interrupt the crawling requests OTTO sends during a Site Audit scan. When OTTO is installed on a WordPress site hosted on SiteGround, its automated scan requests may be rate-limited, blocked, or silently dropped by SiteGround's Dynamic Cache or security firewall — causing the scan to appear stuck at a processing state indefinitely, sometimes for 3 hours or more. This is one of the most common reasons an OTTO scan stalls shortly after the initial WordPress installation. The good news is that a few targeted configuration changes on SiteGround will resolve the issue quickly. ✅ Before You Begin - Make sure OTTO is installed and activated on your WordPress site. - You should have access to your SiteGround Site Tools dashboard. - You will also need to be logged into Search Atlas and able to navigate to OTTO SEO → All Sites (SEO Automation) in the left sidebar (URL: /seo-automation-v3). ⚙️ Step 1 — Disable SiteGround Dynamic Cache for Your Site 1. Log in to your SiteGround Site Tools. 2. Go to Speed → Caching. 3. Under Dynamic Cache, toggle the setting to Off. 4. Click Confirm to save the change. Dynamic Cache caches PHP-generated responses and can cause OTTO's crawl requests to receive stale or incomplete page data, stalling the audit queue. 🛡️ Step 2 — Whitelist OTTO's Crawl User-Agent in SiteGround Security 1. In SiteGround Site Tools, navigate to Security → IP Manager. 2. Check whether any IP block rules or rate-limit rules could affect automated crawlers. 3. If your site uses the SiteGround Security plugin in WordPress, open it and go to Activity Log → Blocked Requests to check if OTTO's requests are being blocked. 4. If OTTO's user-agent or IP addresses appear in blocked requests, add them to the Whitelist within the plugin settings. If you are unsure which IP addresses OTTO uses, reach out via the chat widget (details at the end of this article) and a teammate can provide the current list. 🔌 Step 3 — Deactivate Conflicting WordPress Cache Plugins SiteGround sites often have additional WordPress caching plugins installed, such as SG Optimizer. These can layer additional caching on top of server-level caching and further interfere with OTTO's scan requests. 1. Log in to your WordPress Admin Dashboard. 2. Go to Plugins → Installed Plugins. 3. Temporarily Deactivate any active cache plugins (e.g., SG Optimizer, W3 Total Cache, WP Super Cache). 4. Once the OTTO scan completes successfully, you can reactivate these plugins. 🔄 Step 4 — Restart the OTTO Scan 1. Log in to Search Atlas and navigate to OTTO SEO → All Sites (SEO Automation) in the left sidebar (URL: /seo-automation-v3). 2. Locate your website in the OTTO dashboard. 3. If the scan shows a stuck or processing state, click the Restart Scan option (or disconnect and reconnect OTTO to trigger a fresh scan). 4. Monitor the scan progress — it should now advance through the audit stages without stalling. 💡 Additional Tips for SiteGround Users - Use a staging environment first: If you are testing OTTO on a new WordPress install, run your initial scan on a SiteGround staging site where caching is typically less aggressive. - Re-enable caching after scanning: Dynamic Cache and other caching tools improve your site's performance — only disable them temporarily to unblock the scan, then re-enable them once the audit finishes. - Keep OTTO updated: Always use the latest version of the OTTO WordPress plugin to ensure compatibility with SiteGround's latest server configurations. 🆘 Still Stuck? If you have followed all the steps above and your OTTO scan is still not progressing, there may be a server-level firewall rule or a hosting configuration specific to your SiteGround plan that requires 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.

⚡ Fix OTTO Shopify Connection and Crawl Failures

Overview When connecting OTTO to your Shopify store, two issues commonly block a successful crawl: theme compatibility problems that prevent OTTO from reading your site structure, and crawler IP blocks that stop OTTO's bot from accessing your pages. This article walks you through diagnosing and fixing both. Step 1: Connect Your Shopify Store to OTTO 1. In Search Atlas, navigate to the OTTO SEO section. 2. Select or create the project for your Shopify store. 3. Follow the on-screen prompts to connect your Shopify store and authorise Search Atlas access. 4. Once connected, trigger an initial crawl from within the project. If the crawl fails immediately or returns zero pages, continue to the sections below. Step 2: Check Theme Compatibility OTTO is compatible with the vast majority of Shopify themes, including all themes from the official Shopify Theme Store. However, certain theme configurations can interfere with the crawl. Configurations that commonly cause issues: - Password-protected storefronts — If your store is in development mode or protected by a password page, OTTO's crawler cannot access any content. Disable the password under Shopify Admin → Online Store → Preferences → Password protection. - Heavy JavaScript-only rendering — Highly customised headless or custom-built themes that render all content exclusively via client-side JavaScript may limit what OTTO can crawl. Standard Liquid-based themes are fully supported. - Geolocation or market redirects — Themes configured to redirect visitors based on location can cause the crawler to land on a redirect loop or a localised page OTTO cannot index. Disable geo-redirects temporarily during the initial crawl. - Maintenance mode apps — Third-party apps such as "Coming Soon" pages or maintenance-mode overlays will block the crawler just like a password page. Deactivate them before crawling. If you are unsure whether your theme is causing the issue, temporarily switch to a default Shopify theme, run a test crawl, and compare results. Step 3: Whitelist OTTO's Crawler IP Addresses The most common reason a crawl fails silently — returning no errors but also no pages — is that a security app, firewall, or Shopify bot-protection setting is blocking OTTO's crawler. You must whitelist Search Atlas crawler IP addresses to allow access. To obtain the exact IP addresses you need to whitelist, please contact our support team (see below). Once you have the IPs, add them to your whitelist in each of the following places that apply to your store: - Shopify Bot Protection settings — In your Shopify Admin, navigate to Online Store → Preferences and review any bot-protection or allowed-crawler settings. - Cloud 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 Not Rendering on React or Lovable SPA Sites

🔍 Why OTTO Changes Don't Appear on Your Live Site OTTO deploys SEO changes by injecting updated meta tags via a script in your site's . On traditional HTML sites this works without issue. On React, Lovable, and other single-page application (SPA) frameworks, these frameworks manage their own metadata through JavaScript libraries (e.g. react-helmet) that run on every page render and overwrite OTTO's injected values. OTTO automatically detects SPA frameworks and uses JavaScript rendering for re-crawls, but this client-side overwrite is a code-level conflict that still requires one of the fixes below. This is why OTTO correctly reports the deployment as Engaged — the deployment is working. The conflict happens after the page loads, when the framework replaces OTTO's tags with its own values. ✅ How to Confirm This Is Your Issue - In Left sidebar → OTTO SEO → All Sites, OTTO shows the deployment as Engaged or Deployed - Clearing cache still shows old title/meta description - Your site was built with React, Next.js, Vite, or generated by Lovable - Lovable sites only — Cloudflare Worker installation: there is a known issue where the Cloudflare Worker install method silently proxies apex and www DNS records, which can break sites hosted on Lovable. If your Lovable-hosted site stopped loading correctly after OTTO installation, switch to the standard script tag installation method while this is being resolved. 🛠️ Two Ways to Fix It 1. Adjust script load order — Modify your app's entry point so the Search Atlas script loads before React's metadata manager initializes. 2. Use the OTTO API integration — Write SEO values directly into your codebase via API. This is the recommended approach for React and Lovable sites. Contact support to request setup credentials and the guide. 💬 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. Additional Notes For Lovable sites, the OTTO script must be added to the index.html file inside the head tag — not inside any React component. Place the script as early as possible in the head section, before any other JavaScript files. Also: check View Page Source vs DevTools Elements tab to distinguish raw HTML vs rendered DOM conflicts.

Fix OTTO Overriding WordPress Blog noindex

🔍 What Is Happening? If your WordPress Posts page (commonly /blog/) is showing a noindex, nofollow robots meta tag in the browser source even though every Yoast SEO setting and per-page setting is explicitly set to index, the cause is almost always OTTO's deployed robots meta tag. OTTO can inject its own robots meta tag directly onto your pages as part of a deployment. This tag is written at the platform level and takes precedence over WordPress and Yoast settings. No amount of adjusting Yoast or your theme will remove it — the override must be resolved inside Search Atlas. ⚠️ Why This Happens When you run an OTTO deployment that includes a robots meta directive, OTTO pushes that instruction to your connected WordPress site. This is intentional behaviour — it allows OTTO to manage crawlability at scale. However, it can create a conflict if: - An earlier OTTO deployment set the Posts page to noindex, nofollow and the setting was never reversed. - A bulk robots meta deployment targeted archive or listing pages and included your Posts page unintentionally. - You updated Yoast after the OTTO deployment, so Yoast now says index but OTTO's previously deployed tag still takes precedence on the live page. In all these cases, your page will remain noindex until you explicitly update or remove the OTTO-deployed tag. 🛠️ How to Check the OTTO-Deployed Robots Tag 1. Log in to Search Atlas and open the relevant project. 2. Navigate to OTTO SEO → All Sites (SEO Automation) for that project. 3. Review any deployed actions related to robots meta, noindex, or crawlability settings. 4. Identify whether a noindex, nofollow directive was deployed to your Posts page URL (e.g. /blog/). ✅ How to Fix the Conflict 1. Inside Search Atlas, locate the OTTO-deployed robots meta action affecting your Posts page. 2. Update the robots directive for that page to index, follow, or remove the deployed tag entirely if you prefer Yoast to manage it going forward. 3. Re-deploy the updated action so OTTO pushes the corrected tag to your WordPress site. 4. Once deployed, view the page source in your browser (Ctrl + U or Cmd + U) and confirm the robots meta tag now reads index, follow. 5. Clear any WordPress, server-side, or CDN cache so search engines receive the updated tag immediately. After these steps, Yoast and OTTO will be in agreement and your Posts page will be crawlable and indexable again. 🔎 How to Verify the Fix Is Live - Browser source check: Search the page source for robots and confirm the meta tag reads index, follow. - Cache cleared: Ensure all caching layers have been purged so the updated tag is served to crawlers. If you have reviewed OTTO's deployed actions and cannot identify the source of the noindex tag, or if the tag persists after re-deploying, please reach out to our support team via the chat icon in Search Atlas so we can investigate further.

🔧 Fix Cloudflare OTTO Worker Redirect Diagnostic Failures

Overview When Cloudflare's OTTO Worker is installed on your www domain but a redirect forwards all traffic to the non-www version, the Worker never executes on incoming requests. The DNS diagnostic then reports a missing header because it checks the www URL, which immediately redirects before the Worker can inject the required response header. This article walks you through identifying and resolving that specific failure. How to Confirm This Is Your Issue Before making any changes, verify that this redirect scenario is the actual cause of your diagnostic failure: 1. Open a terminal or use an online tool such as curl to request your www URL: curl -I https://www.yourdomain.com 2. Check the response. If you see a 301 or 302 redirect pointing to https://yourdomain.com (non-www), the Worker is being bypassed. 3. In your Search Atlas dashboard, go to OTTO SEO (left sidebar) and open your site's OTTO settings. Confirm the diagnostic error references a missing header — not a Worker script error. If both conditions are true, follow the steps below. Step 1 — Review Your Worker Route Configuration A Worker route must match the URL that actually serves content, not the URL that redirects away. Log in to your Cloudflare dashboard and review your OTTO Worker's route assignments: 1. Navigate to Workers & Pages and locate your OTTO Worker. 2. Review the routes currently assigned to the Worker. 3. Confirm that a route exists for your non-www domain: yourdomain.com/* 4. If only the www route exists (www.yourdomain.com/*), add a route for the non-www domain, selecting the correct zone, and save your changes. 5. Keep the www route in place as well so both domains are covered. The Worker must be assigned to the domain that actually responds to requests — in a www-to-non-www redirect setup, that is the non-www domain. Step 2 — Verify Worker Permissions and API Token Scope Even when routes look correct, the Worker can silently fail to execute if the API token used during installation lacks the necessary permissions. Check your Cloudflare API token settings to confirm the token associated with your OTTO integration has sufficient permissions to manage Worker routes and scripts across the relevant zone. If permissions appear incomplete, update the token accordingly. If you are unsure which permissions are required or the issue persists after reviewing your route and token configuration, please contact our support team via the chat icon in your Search Atlas dashboard so we can investigate your specific setup.

🌐 Fixing Cloudflare Nameserver Downtime

🔎 Why Your Site Went Down When you change your nameservers to point to Cloudflare, you are telling the internet to look up your website in a new place. This change does not happen instantly. It needs time to spread across servers worldwide in a process called DNS propagation. During this window, some visitors may reach your site while others see errors or a blank page. In almost every case, downtime after a nameserver change is caused by one of two things: propagation that is still in progress, or missing DNS records inside your new Cloudflare account. The good news is that both are easy to check and fix. ⏱️ How Long Propagation Takes Nameserver changes usually complete within a few hours, but the official window is up to 24 to 48 hours. A site that has been down for around 8 hours is still within the normal range, especially if DNS records were not fully copied over before the switch. If your site is still unreachable after 48 hours, propagation is no longer the cause. At that point, the issue is almost always a missing or incorrect DNS record, which you can correct using the steps below. 🛠️ How to Confirm the Cause Before making changes, confirm what is actually happening: 1. Log in to your Cloudflare dashboard and select your domain. 2. Check the Overview tab. Cloudflare will display a message once it detects that your nameservers are active. 3. Open the DNS tab and review your records. 4. Confirm that an A record or CNAME record points to your correct server or hosting address. If the nameservers show as active but your site is still down, the problem is your DNS records, not propagation. ⚙️ How to Fix the Downtime Follow these steps to restore your site: 1. In the Cloudflare DNS tab, compare your records against those from your previous provider or hosting company. 2. Add any missing records. Most sites need at least an A record pointing to your server IP address and, if applicable, a www CNAME record. 3. Make sure the record for your main domain is set to Proxied or DNS only as recommended by your host. 4. Save your changes. Updates within Cloudflare apply quickly, usually within minutes. 5. Clear your browser cache or test your site in a private window to see the current status. If you are unsure which records you need, your hosting provider can give you the exact values to enter. 🐞 Known Issues With OTTO's Cloudflare Setup If you connected Cloudflare through OTTO, two known issues can cause downtime that the general steps above may not fully explain: - Records proxied unexpectedly on third-party hosting. On sites hosted with certain third-party platforms (such as Lovable), the OTTO Cloudflare Worker installation can silently proxy your apex and www DNS records, which can take the site offline. If your site is hosted on an external platform, open the DNS tab and set the affected records to DNS only instead of Proxied. Our product team is currently reviewing this behavior. - Intermittent Error 1102. Some users see occasional Cloudflare Worker failures (Error 1102) during normal browsing rather than a constant outage. This is a known issue that our engineering team is actively working on. 💡 Tips to Avoid Future Downtime You can prevent most downtime by preparing before you switch nameservers: - Copy all DNS records first. Add every record to Cloudflare before changing your nameservers, not after. - Switch during low-traffic hours. This limits the impact if a short outage occurs. - Lower your TTL in advance. Reducing the Time To Live a day before the change helps updates spread faster. - Keep a record of your old settings. Save a copy of your previous DNS configuration so you can restore it quickly if needed. ✅ When to Expect Full Resolution Once your nameservers show as active and your DNS records are correct, your site should return for all visitors within a short time. If you have waited beyond 48 hours and added the correct records, and your site is still unreachable, it is time to dig deeper into your hosting or record configuration. 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 OTTO Script Unreachable Error on Your Wix SEO Dashboard

Is This the Right Article for You? If your OTTO scripts are showing unreachable on one or more Wix client sites, this article will help you get the right support to resolve it. Why OTTO Scripts Show as Unreachable on Wix An OTTO script can report unreachable on a Wix site for several reasons, including a connectivity issue on the Search Atlas side or a configuration problem with how the site is connected to OTTO. Because Wix has platform-specific limitations, these issues typically require investigation by the Search Atlas support team to resolve. What to Do Because the root cause of an OTTO script unreachable error on a Wix site often requires backend investigation, the recommended step is to contact the Search Atlas support team directly. When you reach out, please provide: - Your Search Atlas account email - The name and URL of the affected Wix site - A description of the issue, including when you first noticed the unreachable status The support team will investigate your account and site configuration and work with you to restore the OTTO connection for your Wix site. Still Need Help? If you are still experiencing this issue, please use the chat widget on this page to contact the Search Atlas support team and mention this article. We're here to help investigate your specific account and site configuration.

🔧 Fix Cloudflare OTTO Worker Installation: DNS Redirect and Header Issues

Understanding the www Redirect Problem When your Cloudflare diagnostic fails and reports a missing OTTO Worker header, it is often because your domain configuration redirects www traffic to non-www (or vice versa). This redirect can bypass the Cloudflare Worker on one domain variant, causing the diagnostic check to fail and preventing OTTO from functioning properly on that version of your site. For example: if visitors access www.yourdomain.com but are redirected to yourdomain.com, the Worker installed on the www variant may never execute, so the diagnostic check finds no OTTO header on that version. Step 1: Identify Which Domain Variant Is Failing 1. Log into your Search Atlas account and navigate to your OTTO installation area. 2. Trigger a diagnostic check for your domain. 3. Review the diagnostic results and note which domain variant shows the missing header error (www or non-www). 4. Take note of the exact error message — it will indicate the domain variant that failed the check. Step 2: Check Your Cloudflare DNS and Redirect Rules You need to verify your Cloudflare configuration to understand how traffic is being routed between www and non-www variants. 1. Log into your Cloudflare account and select your domain. 2. Review your DNS records for both www and non-www variants to confirm they are correctly configured. 3. Check your Cloudflare redirect or rewrite rules to identify any rules that forward www traffic to non-www (or vice versa). 4. Determine whether any redirect rules may be executing before the OTTO Worker has a chance to run, which would prevent the Worker from injecting its required header. Step 3: Ensure the OTTO Worker Covers the Correct Domain Variant A common cause of this issue is that the OTTO Worker is only installed or routed for one domain variant. You need to confirm the Worker is configured to handle traffic on the domain variant your visitors actually land on after any redirects. 1. In your Cloudflare account, review the routes or triggers associated with your OTTO Worker. 2. Confirm the Worker is active for the domain variant that is failing the diagnostic (the one visitors are redirected to). 3. If the Worker is only covering one variant, update your Cloudflare Worker routing settings to extend coverage to the other variant as needed. 4. If you are unsure how to adjust your Cloudflare Worker routing, contact the Search Atlas support team for guided assistance specific to your account configuration. Step 4: Re-run the Diagnostic After Making Changes 1. After updating your Cloudflare configuration, return to your OTTO installation in Search Atlas. 2. Trigger the diagnostic check again to confirm the OTTO Worker header is now detected on the previously failing domain variant. 3. If the diagnostic still fails after making adjustments, reach out to the Search Atlas support team via the chat icon in your dashboard so an agent can review your specific Cloudflare and OTTO configuration directly.

⚠️ 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.

🗑️ How to Clear Your Site Cache After Making Changes in Search Atlas OTTO

🗑️ How to Clear Your Site Cache After Making Changes in Search Atlas OTTO When OTTO deploys or removes content on your website, those changes do not always appear immediately for visitors. Your site's cache stores older versions of your pages and serves them to users until the cache is refreshed. Clearing your cache is a required step any time you disengage OTTO, update injected content, or troubleshoot unexpected content appearing on your site. 🤔 Why Cache Clearing Matters After OTTO Changes OTTO pushes content changes at the server and application level. However, caching layers — whether at the WordPress plugin level, the CDN level, or the hosting level — capture snapshots of your pages and continue serving those snapshots even after the underlying content has changed. ⚠️ If you skip this step, visitors (and you) may continue to see old injected content even after OTTO has been disengaged and the body text field has been cleared. Always clear cache immediately after making changes in OTTO to confirm the fix is live. 🛠️ How to Clear Your Cache by Platform ⚡ WordPress Caching Plugins ✅ WP Rocket: Log in to your WordPress dashboard, go to Settings → WP Rocket, and click the Clear Cache button at the top of the screen. You can also clear cache directly from the WordPress admin toolbar by clicking the WP Rocket icon. ✅ LiteSpeed Cache: In your WordPress dashboard, navigate to LiteSpeed Cache → Toolbox → Clean All. This purges all cached files stored by LiteSpeed on your server. ✅ W3 Total Cache: Go to Performance → Dashboard and click Empty All Caches. If you use a CDN integration within W3 Total Cache, also purge the CDN cache from the same dashboard. ✅ WP Super Cache: Navigate to Settings → WP Super Cache and click Delete Cache under the Easy tab. 🌐 Cloudflare CDN ✅ Log in to your Cloudflare account and select the domain you are working with. ✅ In the left-hand sidebar, go to Caching → Configuration. ✅ Under the Custom Purge or Purge Cache section, click Purge Everything to clear all cached assets across Cloudflare's global network. ⚠️ Important: Purging everything in Cloudflare clears all cached assets site-wide. This is the safest option when troubleshooting OTTO content injection issues, as partial purges may miss the affected pages. 🖥️ Hosting-Level Cache Many managed WordPress hosts — including WP Engine, Kinsta, Flywheel, SiteGround, and Cloudways — maintain their own server-side caching layers that operate independently of any WordPress plugin. ✅ WP Engine: In your WP Engine User Portal, go to your environment and click Purge All Caches. ✅ Kinsta: In the MyKinsta dashboard, navigate to your site, go to Tools, and click Clear Cache. ✅ SiteGround: In the SiteGround Site Tools, go to Speed → Caching and click the flush icon next to Dynamic Cache. ✅ Cloudways: In your Cloudways console, open your application and go to Application Management → Varnish. Click Purge Varnish Cache. ✅ Other hosts: If your host is not listed above, log in to your hosting control panel or contact your host's support team and ask them to flush the server-side or full-page cache for your domain. ✅ How to Confirm the Cache Has Been Cleared ✅ After purging your cache, open a new private or incognito browser window. This prevents your own browser cache from serving a stale version of the page. ✅ Navigate to several pages on your site — including the homepage, a category page, and an inner page — and scroll to the bottom of each. ✅ If the previously injected content no longer appears below the footer, the cache has been cleared successfully and the OTTO change is live. ⚠️ If the content is still visible after clearing all cache layers, contact Search Atlas support. A specialist can confirm whether the OTTO deployment rollback has been applied on the server side and push an additional correction if needed. 🔁 When Else Should You Clear Cache with OTTO? 🔄 Any time you engage or disengage OTTO on a site, clear your cache afterwards to ensure the changes propagate immediately to all visitors. 🔄 After editing content in any OTTO tab — including title tags, meta descriptions, schema markup, or the Miscellaneous body text field — clear your cache so updated deployments are reflected live. 🔄 After completing a troubleshooting session with Search Atlas support involving OTTO deployments, always perform a full cache purge as the final step before confirming the issue is resolved.

🛠️ Fixing Cloudflare Error 1027 with OTTO

🔍 What Error 1027 Means Cloudflare Error 1027 means your website has been temporarily rate-limited or blocked by Cloudflare because of a usage limit on your account. When this happens, visitors may see an error page instead of your site, and your pages can appear inaccessible. This is a Cloudflare-level response, not a problem with your website's actual content or hosting. 🔗 How This Connects to OTTO OTTO deploys its SEO changes to your site through a Cloudflare Worker. When you complete the OTTO Cloudflare integration, a Worker is installed on your Cloudflare account. This Worker runs on every request to your site so it can apply OTTO's optimizations on the fly. Cloudflare's free plan includes a daily allowance of 100,000 Worker requests. If your site receives more traffic than this allowance in a single day, Cloudflare stops the Worker from running and may return Error 1027. Because the OTTO Worker sits in front of your traffic, reaching this limit can make your whole site appear unavailable. ⚙️ Common Causes - High traffic volume: Your daily visits exceed the free Worker request allowance. - Bot or crawler activity: Aggressive crawlers and bots inflate your request count quickly. - Plan limits reached: Your Cloudflare account has hit a usage or billing threshold. - Multiple Workers running: Other Workers on the same account share the request allowance. 🚀 How to Fix It Follow these steps to restore access and prevent the error from returning: 1. Confirm the cause. Log in to your Cloudflare dashboard and open Workers & Pages. Check your daily request usage to see if you have reached the free allowance. 2. Wait for the daily reset. Worker request counts reset every 24 hours. If you have briefly exceeded the limit, access usually returns after the reset. 3. Upgrade your Workers plan. If your traffic regularly exceeds 100,000 requests per day, upgrade to the Cloudflare Workers Paid plan for a much higher allowance. This is the most reliable fix for high-traffic sites. 4. Reduce unnecessary requests. Use Cloudflare's security settings to block or challenge unwanted bots, and enable caching so fewer requests reach the Worker. 5. Verify the OTTO Worker. In your Cloudflare dashboard, confirm the OTTO Worker is still installed and the route is correctly assigned to your domain. ✅ Preventing It in the Future - Monitor your Cloudflare Worker usage regularly, especially during traffic spikes or campaigns. - Keep caching enabled to lower the number of requests that hit the Worker. - Match your Cloudflare plan to your real traffic levels so you stay within your allowance. - Use bot management rules to filter out automated traffic that wastes requests. 💡 Important Notes The OTTO Worker does not create extra traffic on its own. It processes the traffic your site already receives, so Error 1027 reflects your overall site usage rather than a fault in OTTO. Removing the Worker would stop OTTO from applying your SEO changes, so upgrading or optimizing your Cloudflare setup is the recommended path. If your site is still returning Error 1027 after the daily reset and your Worker usage is well within the free allowance, the cause may be a Worker configuration or authentication issue rather than true rate-limiting. Our engineering team is actively building dedicated Cloudflare diagnostics and a Worker debug mode to make these cases easier to identify. If you suspect this, reach out to support so we can investigate. 💬 Need More Help If you need further assistance, click the chat icon in the bottom-right corner of the platform and type "Human Teammate" to start a live chat with a member of our team.