Troubleshooting: Pixel, Cloudflare, GTM & Caching

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

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

🛠️ Fix OTTO Pixel Not Detected via Cloudflare

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

🛠️ Fix OTTO SEO UUID Mismatch with Cloudflare

🔍 What Is a UUID Mismatch? When you activate OTTO SEO on your website, Search Atlas generates a UUID (Universally Unique Identifier) — a unique code that links your site to your OTTO SEO workspace. A UUID mismatch occurs when the UUID that OTTO detects on your site does not match the one stored in your Search Atlas account. This issue most commonly appears when your site is proxied through Cloudflare DNS. Cloudflare's caching and proxy settings can interfere with how the UUID is served and verified, causing OTTO SEO to fail validation even if you followed every setup step correctly. ⚙️ Why Cloudflare Can Cause This Problem Cloudflare sits between your visitors (and Search Atlas) and your origin server. When OTTO SEO attempts to verify your UUID, it sends a request to your domain. If Cloudflare is caching an old version of the page or blocking certain requests, the UUID it returns may be outdated, missing, or from a different deployment entirely. Common contributing factors include: - Aggressive page caching — Cloudflare serves a cached page that does not contain the latest UUID snippet. - Performance features that modify JavaScript — Certain Cloudflare optimizations can defer or alter scripts, which may prevent the UUID from loading correctly at verification time. - Security or bot-filtering rules — Firewall or bot-protection settings may block the Search Atlas verification crawler before it can read the UUID. - Proxied DNS records — Proxy mode routes traffic through Cloudflare, which can alter the response seen by the OTTO verifier. 🚀 What to Do When You Experience a UUID Mismatch Because the exact configuration that causes a UUID mismatch can vary depending on your Cloudflare setup, the most reliable path to resolution is to contact our support team directly. When you reach out, please have the following ready so our team can investigate efficiently: - Your Search Atlas project/site name and the domain experiencing the mismatch - A description of your Cloudflare DNS configuration (e.g., whether the DNS record is proxied or DNS-only) - Any Cloudflare features you have enabled that affect JavaScript delivery, caching, or security/bot filtering - The exact error message or status shown in your Search Atlas account when validation fails - A timestamp of when the issue first occurred or was last observed Having this information ready will allow our team to identify the specific Cloudflare setting interfering with UUID validation and guide you through the correct fix for your 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 Pixel Detection Failures via Cloudflare

Overview When your site runs behind Cloudflare, certain security settings or configurations can block or delay Search Atlas from verifying your OTTO pixel installation. This guide covers general troubleshooting steps for Cloudflare-proxied sites and explains what information to have ready if you need to escalate to our support team. Step 1: Confirm Your Pixel Installation Method Before changing any Cloudflare settings, confirm that the OTTO pixel snippet has been correctly installed on your site using the method recommended for Cloudflare-proxied domains. If you are unsure which installation path applies to your setup, or if you followed a generic installation guide rather than one specific to Cloudflare, reinstalling the pixel using the appropriate method for your site configuration is a good first step. Step 2: Review Cloudflare Security and Bot Protection Settings Cloudflare's security features — including bot protection settings such as Bot Fight Mode and Super Bot Fight Mode — can sometimes treat automated verification requests as bot traffic and block them. If you have aggressive bot protection or Web Application Firewall (WAF) rules enabled, review those settings in your Cloudflare dashboard and consider whether any rules might be preventing Search Atlas's verification crawler from accessing your site. Step 3: Account for DNS and Cache Propagation If you recently added or changed the pixel snippet, allow some time for DNS and cache changes to propagate before re-triggering pixel verification in Search Atlas. You should also purge your Cloudflare cache after making changes to ensure the updated page response is being served correctly. Step 4: Check for Cloudflare Worker Conflicts Cloudflare Workers that modify HTML responses — such as workers that inject scripts, rewrite headers, or alter <head> content — can interfere with pixel delivery. Review any active Workers on your domain and consider whether any might be stripping or modifying the OTTO pixel before it is served. When to Escalate If you have worked through the general checks above and pixel detection is still failing, our support team can investigate further. Please have the following information ready before reaching out: - Your site's domain name and the OTTO project name in Search Atlas - The installation method you used for the OTTO pixel - Which Cloudflare features are currently active on your domain (e.g., Bot Fight Mode, Workers, WAF rules) - Any error messages or status indicators shown in your OTTO settings - The approximate time and date you last attempted pixel verification If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

⚡ OTTO Pixel Setup via Google Tag Manager Troubleshooting

Overview Setting up the OTTO Pixel through Google Tag Manager (GTM) is a common workflow for connecting your site to OTTO in Search Atlas. If you are experiencing issues with the pixel not being detected or seeing an OTTO not found status, this article explains what to prepare and how to escalate so our team can help you resolve it quickly. What Is the OTTO Pixel and Why Use GTM? The OTTO Pixel allows Search Atlas to verify that OTTO is active on your website. Google Tag Manager is a supported installation method that lets you deploy the pixel without editing your site's code directly. Each Search Atlas project generates its own unique pixel code, so the correct code must be installed for the correct project. Common Causes of OTTO Pixel Connection Issues - GTM container not published: Adding a tag in GTM and saving it is not enough — the container must be submitted and published before any tags will fire on your live site. - Wrong project code installed: Each project has a unique pixel code. Using a code from a different project will prevent OTTO from detecting the connection. - Duplicate or conflicting pixel installations: If the OTTO Pixel was previously added manually to your site's theme or a plugin, this can conflict with the GTM-based installation. Only one installation method should be active at a time. - Tag not triggering correctly: The GTM tag must be configured with an appropriate trigger (such as All Pages) to fire on your website. Use GTM's Preview mode to verify the tag is firing as expected. - GSC integration not connected: If you are also experiencing issues with Google Search Console integration alongside the pixel, both may need to be verified or reconnected from within your project settings. What to Have Ready When Contacting Support Because OTTO Pixel issues often require our team to inspect your project configuration directly, please have the following information ready before reaching out: - Your Search Atlas project name and the domain it is associated with - The specific error message or status you are seeing (e.g., OTTO not found) - Whether you are using GTM or another installation method - Whether the GTM container has been published after adding the OTTO tag - Any screenshots of your GTM tag configuration or the OTTO Pixel section in your project - Whether a previous manual pixel installation may still be present on the site If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

⏳ OTTO Pixel Not Detected After GTM Install

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

🔐 Fix CSP Blocking Your OTTO Pixel and GTM

🧩 What Is This Issue? Your OTTO pixel may show as Engaged in the Search Atlas dashboard, yet changes still fail to push to your site. A common cause is a Content Security Policy (CSP) — a browser-level security header — that blocks external scripts, network requests, or tracking pixels from loading on your pages. This is a client-side browser issue, not a server-side crawler or bot-blocking problem. Whitelisting IPs or adjusting bot-protection rules will not resolve it. You need to update your CSP headers to explicitly allow Search Atlas domains. 🔍 CSP vs. Crawler IP Blocking — Know the Difference These are two separate systems and require different fixes: - Crawler IP blocking (403 errors): Your server refuses requests from Search Atlas crawlers. Fix by whitelisting Search Atlas IP ranges in your firewall or WAF settings. - Content Security Policy (CSP) blocking: Your browser refuses to load or communicate with external scripts and endpoints. Fix by adding Search Atlas domains to your CSP header directives. This is the issue described in this article. 🌐 Which Domains Do You Need to Whitelist? The wildcard *.searchatlas.com covers all current and future Search Atlas subdomains, including dashboard.searchatlas.com and bots.searchatlas.com. Using the wildcard is the recommended approach so you do not need to update your CSP each time a new subdomain is introduced. Add the following entries to your CSP header: - script-src: Allows Search Atlas GTM and pixel scripts to execute in the browser. Add *.searchatlas.com. - connect-src: Allows the pixel to send data back to Search Atlas endpoints via XHR or Fetch requests. Add *.searchatlas.com. - img-src: Allows tracking pixels loaded as 1×1 image beacons. Add *.searchatlas.com. If your CSP is managed via an HTTP response header, your updated directives should look similar to this example: script-src 'self' *.searchatlas.com; connect-src 'self' *.searchatlas.com; img-src 'self' *.searchatlas.com; If you also use a meta http-equiv CSP tag in your HTML, apply the same domain additions there. Note that connect-src and some directives are not supported in meta tags — use HTTP headers for full coverage. ✅ Step-by-Step: Applying the CSP Fix 1. Open your server, CDN, or hosting control panel where HTTP response headers are managed (for example, Cloudflare, Nginx, Apache, or your CMS security plugin). 2. Locate your existing Content-Security-Policy header. 3. Add *.searchatlas.com to the script-src, connect-src, and img-src directives. Do not remove any existing trusted domains. 4. Save and deploy the updated header configuration. 5. Open your browser's developer tools (F12), navigate to the Console tab, and reload your page. Confirm there are no remaining CSP violation errors referencing searchatlas.com. 6. Check the Network tab to verify that GTM and pixel requests to searchatlas.com domains return a 200 status rather than being blocked. 📋 Verify GTM Script Placement A correct CSP alone is not enough if your GTM snippet is not placed properly on the page. Confirm the following: - The GTM script tag is placed immediately after the opening <head> tag on every page. - The GTM noscript iframe is placed immediately after the opening <body> tag. - No other script or plugin is stripping or deferring the GTM tags before the CSP evaluation occurs. If you manage your site through a CMS such as WordPress, use an official GTM integration plugin to ensure correct placement and avoid tag removal during theme updates. 🗺️ Reprocess Your Sitemap After CSP Updates Once your CSP is updated and the pixel is confirmed loading correctly in the browser, trigger a sitemap reprocess inside Search Atlas so OTTO can re-evaluate your pages with the pixel now active: 1. In the left sidebar, go to Site Metrics (Site Explorer). 2. Locate your project and open its settings. 3. Resubmit or reprocess your sitemap to prompt a fresh crawl and allow OTTO to detect the correctly firing pixel across all indexed URLs. Changes pushed by OTTO will only apply to pages that are successfully crawled after the pixel is verified as active. 🛠️ Quick Troubleshooting Checklist - Pixel shows Engaged but changes not applying: CSP is the most likely cause — follow the steps above. - CSP updated but errors persist: Check for a separate Content-Security-Policy-Report-Only header that may indicate additional blocked resources. - Changes applied but not visible on site: Clear your CDN or server-side cache after OTTO pushes updates. - Wildcard not supported by your setup: Add dashboard.searchatlas.com and bots.searchatlas.com as explicit entries to each directive. 💬 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 Search Atlas Script Conflicts With Prerender via GTM

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

🏷️ Fix Google Tag Manager Invalid HTML Errors

🔍 Overview When Google Tag Assistant shows cannot connect after you install your GTM snippet, the most common cause is an invalid HTML error in the page where the code was pasted. This article walks you through diagnosing and fixing HTML validation issues, incorrect placement errors, and hosting restrictions so your tags deploy correctly. ⚠️ What Causes Invalid HTML Errors? GTM requires two separate code snippets placed in very specific locations. If either snippet is malformed or placed incorrectly, the browser cannot parse the page cleanly, and Tag Assistant loses its connection. Common causes include: - The <head> snippet pasted outside the <head> tag or after other scripts that close the head section early. - The <body> snippet missing entirely or placed inside a JavaScript block instead of raw HTML. - Special characters (curly braces, quotes, or angle brackets) accidentally modified by a CMS rich-text editor or page builder. - Duplicate GTM container IDs creating conflicting script blocks on the same page. - A theme or plugin that strips or escapes <noscript> tags, breaking the body snippet. ✅ Step 1 — Verify Your Snippet Placement Open your page's raw HTML source (right-click → View Page Source in your browser) and confirm the following: 1. The first snippet begins with <script>(function(w,d,s,l,i) and appears as high as possible inside the <head> tag — before any closing </head>. 2. The second snippet begins with <noscript><iframe src="https://www.googletagmanager.com and appears immediately after the opening <body> tag. 3. Neither snippet is wrapped in additional <script> tags, PHP echo statements, or template literals that could alter the characters. If you cannot locate both snippets exactly as described, re-paste them directly from your GTM account under Admin → Install Google Tag Manager. 🛠️ Step 2 — Validate Your Page HTML Use the free W3C Markup Validation Service (validator.w3.org) to check your page for syntax errors: 1. Go to validator.w3.org and enter your page URL, then click Check. 2. Review any Error lines in the results. Focus on errors near the <head> or <body> sections first, as these directly affect GTM loading. 3. Common fixable errors include unclosed tags before the GTM snippet, stray < or > characters inside attribute values, and duplicate id attributes on the same element. 4. Correct each error in your template or CMS theme file, save, and re-validate until the page passes without critical errors. Note: Minor warnings (such as obsolete attributes from third-party plugins) rarely block GTM. Focus only on Errors, not warnings. 🔒 Step 3 — Check for Hosting or CSP Restrictions Some hosting environments and Content Security Policies (CSP) block external scripts from loading, which produces the same cannot connect symptom even when HTML is valid. - Open your browser's developer tools (F12), go to the Console tab, and reload the page. Look for any message containing Content Security Policy, refused to load script, or googletagmanager.com. - If a CSP error appears, you or your developer must add https://www.googletagmanager.com to the script-src and frame-src directives in your site's CSP header. - If you use a firewall or WAF (such as Cloudflare), temporarily pause it and retest Tag Assistant. If the connection succeeds, create a WAF rule to allow GTM traffic permanently. 🔄 Step 4 — Re-test with Tag Assistant 1. Install the Google Tag Assistant Legacy or Tag Assistant Companion Chrome extension if you have not already. 2. Clear your browser cache and hard-reload the page (Ctrl + Shift + R on Windows, Cmd + Shift + R on Mac). 3. Click the Tag Assistant icon. A green or blue GTM tag icon confirms a successful connection. A grey icon or cannot connect message means the snippet is still not loading correctly. 4. If the tag appears but shows a non-standard implementation warning, recheck snippet placement — one of the two snippets is likely out of position. 🚫 Common Mistakes to Avoid - Do not paste GTM code into a CMS visual/rich-text editor. Always use an HTML or code block, or edit the theme file directly. - Do not add extra quotes or escape characters around the container ID (e.g., GTM-XXXXXX). - Do not install GTM through two different methods simultaneously (e.g., manually in the theme AND via a WordPress plugin) — this creates duplicate containers. - Do not test on a page served from localhost or a staging environment blocked by HTTP authentication, as Tag Assistant cannot connect to password-protected URLs. 💬 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 SEO Tag Not Detected via Google Tag Manager

🧭 Overview When OTTO SEO is deployed through Google Tag Manager (GTM), the platform must detect the tag on your website before activation can proceed. If the tag check fails, your OTTO SEO project will remain inactive even though GTM shows the tag as published. This article covers what to check on your end and how to escalate if the issue persists. ⚙️ How OTTO SEO Tag Detection Works After you connect your domain to an OTTO SEO project, the platform checks whether the OTTO SEO script is present and loading correctly on your site. When the tag is deployed via GTM rather than hardcoded into your HTML, GTM-specific configuration issues can prevent the script from being detected. 🔎 Common Causes of Tag Detection Failure via GTM - GTM container not published: The tag exists in GTM as a draft but has never been submitted and published to the live container. - Incorrect trigger configuration: The tag is set to fire on a specific page or event rather than on all pages, so the detection check may land on a page where the tag never fires. - Content Security Policy (CSP) blocking: Your site's CSP headers restrict third-party scripts, preventing the OTTO SEO script from executing. - Tag firing order or sequencing: Another tag or GTM rule is pausing or blocking the OTTO SEO tag from firing during the initial page load. - Consent Mode / cookie banner interaction: If GTM is configured with Consent Mode, the OTTO SEO tag may be held back until user consent is granted, which can interfere with detection. - Cached page being served: A CDN or server-side cache layer may serve a stale page that pre-dates the GTM container publish, so the tag is absent from the response. ✅ Steps to Try Before Escalating 1. Confirm the GTM container is published. In your GTM workspace, verify that the container version containing the OTTO SEO tag has been submitted and is live. A draft tag will not fire on the live site. 2. Check the trigger scope. Open the OTTO SEO tag in GTM and confirm the trigger is set to fire on all pages. If it is scoped to a specific URL or event only, update it to fire on all pages and republish the container. 3. Use GTM's Preview mode. Load your homepage while GTM Preview is active and confirm the OTTO SEO tag is firing on the initial page view. If it is not firing, review your trigger settings and any tag blocking or sequencing rules. 4. Check your Content Security Policy. Review your site's CSP headers to confirm that third-party scripts required by OTTO SEO are not being blocked. If they are, add the necessary domain to your allowlist. 5. Clear your CDN or server cache. If your site uses a CDN or caching layer, purge the cache after publishing your GTM container so detection checks see the latest version of your pages. 6. Disable Consent Mode temporarily for testing. If your GTM setup uses Consent Mode, check whether the OTTO SEO tag is configured to require consent before firing, and adjust accordingly. 📋 How to Escalate If you have worked through all the steps above and the OTTO SEO tag is still not being detected, please reach out to our support team. To help us investigate as quickly as possible, have the following ready: - Your OTTO SEO project name and the domain in question - Your GTM container ID - A description of which steps you have already tried - Any error messages or console output you have observed - Approximate date and time when the issue started If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 OTTO Pixel Not Detected via Google Tag Manager

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

🔧 Fix OTTO SEO UUID Mismatch with Cloudflare DNS

🧭 Overview If you set up OTTO SEO using Cloudflare DNS and are seeing a UUID mismatch error, the root cause is almost always the same: Cloudflare DNS integration does not automatically inject the correct OTTO UUID into your site's code. Generic troubleshooting steps like clearing cache or re-checking your page source will not resolve this. The fix requires you to disconnect Cloudflare from the OTTO setup and manually paste the correct script directly into your site's HTML. ⚠️ Why This Happens OTTO SEO works by injecting a unique tracking script — identified by a UUID — into your website's code. This UUID links your site to your OTTO workspace in Search Atlas. When customers choose the Cloudflare DNS setup path, they expect Cloudflare to handle the script delivery automatically. However, Cloudflare DNS only manages your domain's DNS records. It does not write, inject, or update the OTTO script in your site's source code. As a result: - Your site may appear connected in Cloudflare but the UUID in your page source is missing, outdated, or belongs to a different site. - OTTO cannot verify your site because the UUID it expects does not match what it finds — or finds nothing at all. - Cache-clearing, script re-validation, and re-checking the Installation Guide will not help because the script was never correctly placed in your code to begin with. ✅ How to Fix It: Manual Script Installation Follow these steps carefully to resolve the UUID mismatch. 1. Navigate to SEO Automation. In the left sidebar, click OTTO SEO, then open SEO Automation inside it. Your URL should show /seo-automation-v3. 2. Open your site's OTTO settings. Select the website that is showing the UUID mismatch error. 3. Copy the correct OTTO script. Locate the installation script in the OTTO setup panel. This script contains your site's unique UUID. Copy the entire script exactly as shown — do not modify any part of it. 4. Do not use the Cloudflare DNS installation method for this step. Close or ignore any Cloudflare-specific instructions. You will install the script directly into your site's code instead. 5. Paste the script into your site's HTML. Open your website's code editor, CMS theme editor, or tag manager. Paste the OTTO script inside the tag on every page where OTTO should be active. If you are using WordPress, paste it via your theme's header file or a header script plugin. 6. Remove any old or duplicate OTTO scripts. Search your site's source for any previously installed OTTO scripts and delete them. Having multiple scripts with different UUIDs will cause continued conflicts. 7. Save and publish your changes. 8. Return to OTTO SEO in Search Atlas and run verification. OTTO will scan your page source for the correct UUID. If the script was pasted correctly, the mismatch error will clear. 🌐 If You Still Want to Use Cloudflare You can continue using Cloudflare for DNS management, CDN, and security — those features are unaffected. The key point is that the OTTO script must live in your actual site code, not be delegated to Cloudflare for injection. Once the script is manually installed in your HTML, Cloudflare will serve it normally as part of your pages without any conflict. 🔍 How to Confirm the Script Is Installed Correctly - Open your website in a browser and right-click anywhere on the page, then select View Page Source. - Use Ctrl+F (or Cmd+F on Mac) to search for otto or your UUID string. - You should see exactly one instance of the OTTO script containing your correct UUID inside the section. - If you see zero results, the script was not saved correctly — repeat step 5 above. - If you see more than one result, remove the duplicates and keep only the current, correct script. 💬 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 Pixel GTM Installation Not Showing Verified

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

🛠️ Fix OTTO Pixel Blocked by Cloudflare

🔍 Why the OTTO Pixel Goes Missing If the OTTO pixel script is not appearing in your WordPress site's page source — even though the Search Atlas plugin is active, your API key is synced, and server-side rendering is enabled — Cloudflare's bot protection is almost certainly the cause. Cloudflare can intercept and strip scripts it identifies as bot-like activity before they ever reach your browser, making it appear as though the pixel was never injected. This is one of the most common reasons for OTTO pixel detection failures and is straightforward to resolve by adjusting your Cloudflare settings. ⚙️ How Cloudflare Blocks the OTTO Pixel Cloudflare sits between your server and your visitors. When its security rules are set too aggressively, they can: - Block or silently remove script tags injected by WordPress plugins - Challenge requests that the OTTO pixel makes during page rendering - Strip scripts flagged as potential bot traffic before the HTML reaches the browser Because the block happens at the CDN layer, the Search Atlas plugin has no way to override it — the fix must be applied inside your Cloudflare dashboard. ✅ Step-by-Step Fix: Whitelist the OTTO Pixel in Cloudflare 1. Log in to your Cloudflare dashboard at cloudflare.com and select the domain where OTTO is installed. 2. Go to Security → WAF (Web Application Firewall) in the left sidebar. 3. Check your Firewall Rules and Managed Rules for any rules that block or challenge JavaScript injection or third-party scripts. Disable or adjust rules that may target plugin-generated scripts. 4. Navigate to Security → Bots and review your Bot Fight Mode setting. If Super Bot Fight Mode or Bot Fight Mode is enabled, it may be challenging the OTTO script. Consider switching to Allow for verified bots, or create an exception. 5. Create a WAF Exception (Skip Rule) to whitelist the OTTO pixel endpoint: - Go to Security → WAF → Custom Rules and click Create rule. - Set the rule to match requests where the URI path contains the OTTO script path or originates from the Search Atlas domain. - Set the action to Skip → All remaining custom rules. - Save and deploy the rule. 6. Disable Rocket Loader for your site temporarily (under Speed → Optimization → Rocket Loader). Rocket Loader rewrites how JavaScript loads and can prevent plugin scripts from injecting correctly. Test whether the pixel appears after disabling it. 7. Clear your Cloudflare cache by going to Caching → Configuration → Purge Everything after making any changes. 🧪 How to Verify the Pixel Is Now Detected 1. Open your WordPress site in a browser and navigate to any page where OTTO is active. 2. Right-click the page and select View Page Source. 3. Use Ctrl + F (or Cmd + F on Mac) and search for otto or your Search Atlas script snippet. 4. If the script appears in the source, the pixel is now being injected successfully. 5. Return to Search Atlas by navigating to OTTO SEO → All Sites (SEO Automation) in the left sidebar (or go to /seo-automation-v3), and confirm that OTTO shows the pixel as detected. 💡 Additional Things to Check - Other security plugins: Plugins like Wordfence, Sucuri, or iThemes Security can also block script injection independently of Cloudflare. Check their settings if the issue persists after the Cloudflare fix. - Caching plugins: WP Rocket, W3 Total Cache, or LiteSpeed Cache may serve a cached version of the page that pre-dates the OTTO pixel. Purge all caches after any configuration change. - Server-side rendering confirmation: Double-check that server-side rendering is toggled on inside the Search Atlas plugin settings on your WordPress site, not just within the Search Atlas platform. - API key sync: Re-save your API key inside the plugin settings to force a fresh connection, then check the page source again. 💬 Still Seeing the Issue? If you have followed all the steps above and the OTTO pixel is still not appearing in your 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.

🔧 Fix OTTO Installation Detection Issues with Cloudflare Proxy

Overview If OTTO cannot detect your Search Atlas plugin installation and your domain uses Cloudflare, the issue may be related to your Cloudflare DNS proxy configuration. Specifically, when your domain's DNS record is set to DNS only (grey cloud) instead of Proxied (orange cloud), OTTO may fail to detect the installation correctly. This article explains why this happens and walks you through the fix. Why This Happens OTTO's installation detection relies on traffic being routed through Cloudflare's proxy. When a DNS record is set to DNS only (grey cloud), traffic bypasses Cloudflare entirely. As a result: - OTTO's installation detection cannot complete successfully. - Search Atlas may not recognize your site as properly installed. This can affect your apex domain (e.g., yourdomain.com), your www subdomain, or both — even if you have completed the installation steps correctly inside Search Atlas. How to Fix It You will need to log in to your Cloudflare account and update the proxy status for the affected DNS record(s). Follow these steps: 1. Log in to your Cloudflare dashboard at dash.cloudflare.com. 2. Select the account and domain that you are connecting to OTTO. 3. Click DNS in the left-hand navigation to open your DNS records. 4. Locate the A record or CNAME record for your apex domain (e.g., yourdomain.com) and your www subdomain if applicable. 5. Check the Proxy status column for each record. If it shows a grey cloud and the label DNS only, the proxy is disabled. 6. Click the grey cloud icon to toggle it to an orange cloud (Proxied) and confirm the change when prompted. 7. Save your changes and allow a few minutes for the update to take effect. Verify the Fix in Search Atlas Once you have enabled the Cloudflare proxy for the affected records, return to Search Atlas and check whether OTTO now detects your installation successfully. If the installation is detected, the issue should be resolved and OTTO will be active on your site. Important Considerations - Check both your apex domain and www subdomain — both records may need to be set to Proxied. - If you are unsure which records to update, review all DNS entries associated with the domain you connected to OTTO. - If you have made the change and OTTO still cannot detect your installation, please reach out to our support team and we can investigate further.