🛠️ Troubleshooting

🛠️ Site Auditor: Fixing "Invalid URL" Errors and Missing Sites on the All Audits Page

Most "Invalid URL" reports in Site Auditor are actually a visibility issue: the site was added successfully but sits below the first page of the All Audits table. Click Load More and refresh the tab first, then use the steps below only if the site is genuinely missing. 📋 What the All Audits Page Does The All Audits page is where you manage every site submitted to Site Auditor. From here you can launch new audits, search and sort existing ones, trigger recrawls, and open detailed audit reports. Navigation: Left Sidebar → OTTO SEO → Site Audit → All Audits Note (June 2026): The All Audits page interface — including pagination, row layout, the top bar, and filters — may change shortly as an updated design rolls out. The steps below describe the current layout and will be revised when the new design ships. 🔍 Find a Site That Is Not Showing in All Audits The All Audits table loads a limited batch of entries at a time, so a site you just added may exist but not appear on the first view. Work through these checks before assuming an audit failed: 1. Scroll to the bottom of the table and click Load More (if available) to retrieve the next batch. Repeat until your target site appears. 2. If a recently added site still does not appear, refresh the browser tab — newly submitted audits sometimes render only after the page reloads. 3. Use the search bar at the top of the table to filter by domain name instead of paging through every entry. Note: A separate known pagination bug affects the Custom URL Based Indexing feature (page size and navigation), which is distinct from the All Audits page covered here. All Audits pagination works normally — if Load More does not retrieve additional entries, contact Support using the steps at the end of this article. Outcome: Your site appears as a row in the All Audits table with its status, and you can open its report. ⚠️ Why You See an "Invalid URL" Error When the Site Is Actually Added In many cases the URL is valid and the audit starts normally — the site is simply hidden by pagination. Support has confirmed identical URLs working on their end while the customer's added sites were already present in the All Audits list, just below the first page. Before troubleshooting the URL itself: - Click Load More at the bottom of the All Audits table to load every entry. - Refresh the browser tab so any just-added sites render. - Search by domain name to confirm whether the site is already listed. If the site is still absent after loading all entries and refreshing, continue with the format and submission checks below. ✅ Verify the URL Format If the site is genuinely missing, confirm the URL is formatted correctly: - Include the protocol: https://yourdomain.com/ or http://yourdomain.com/. - Remove trailing query strings (?), fragments (#), and leading or trailing spaces. - If your domain uses a non-standard TLD (for example .download), it may have been affected by a known validation issue — see the URL Validation Error for Non-Standard TLDs in Site Explorer and OTTO article for current status, then re-add the domain to confirm it works. Outcome: A correctly formatted URL is accepted and the audit begins crawling. 💬 Use the Agent Chat Workaround For persistent errors when adding a domain to OTTO or Site Auditor, Agent Chat may provide an alternative submission path. Verify the exact Agent Chat label and location within your OTTO project first, as the interface can vary. 1. Open the relevant OTTO project and locate the Agent Chat option. 2. Type: Add [your full domain URL] as a new site audit. 3. The agent uses an alternative submission path to add the domain. Outcome: The domain is submitted through Agent Chat and appears in your All Audits list. 🔁 Check for Duplicate or Pending Submissions Submitting the same domain more than once can cause display inconsistencies. Search by domain name on the All Audits page and review any entries showing a Pending or Processing status before re-adding the site. 🧹 Clear Cache and Try a Different Browser - Clear your browser cache and cookies. - Retry in a different browser — Chrome, Edge, or Safari are recommended. - Disable browser extensions that may interfere with the Search Atlas dashboard. 🆘 Contact Search Atlas Support If the URL passes format checks and the site is still missing after loading all entries, contact Search Atlas Support through the in-app Help Widget. Include the exact URL(s), your browser, and the full error message text so the team can reproduce the issue. ⚙️ Other Actions on the All Audits Page - New audit: Click + New Audit and enter your domain URL. - Recrawl: Go to OTTO SEO → Site Audit → Overview (Website Overview) and click the Recrawl Site button. - Open a report: Click the domain name or report icon to view the full audit. - Sort and filter: Click any column header to sort entries; available columns may include date, health score, and status. 🔗 Related Articles - How to Run a Site Audit in Search Atlas - How to Recrawl an Existing Site in Search Atlas - URL Validation Error for Non-Standard TLDs in Site Explorer and OTTO - OTTO Setup and Feature Walkthrough 🎯 You now know to click Load More and refresh the tab before assuming an audit failed, and how to verify URL format or use the Agent Chat workaround for genuine errors. If a site is still missing after these steps, reach out through the in-app Help Widget with your exact URL and error text.

🛠️ Search Atlas — General Platform Issues

Use this guide to diagnose and fix the most common Search Atlas platform errors — dashboard loading failures, stalled OTTO crawls, health score updates, data sync delays, and schema deployment issues. ⚠️ Common Issues & Fixes 🔴 Error: "Something went wrong" when loading projects or OTTO What's happening The dashboard cannot load your project data. How to fix it 1. Hard-refresh your browser: Ctrl + Shift + R (Windows) / Cmd + Shift + R (Mac) 2. Log out and log back in. 3. Try a different browser — Chrome is recommended. 4. Clear cache and cookies for dashboard.searchatlas.com. 5. If you see an error code, copy it and share it with support. After clearing cache and logging back in, the dashboard should load your projects normally. 🕷️ Error: OTTO crawl stuck on "In Progress" What's happening Your site crawl has stalled or is taking longer than expected. How to fix it 1. Wait if your site is large — sites with 10,000+ pages or heavy JavaScript can take several hours. If the crawl exceeds 6 hours without completing, proceed to the restart step. 2. Confirm your site is publicly accessible — no login walls or IP restrictions. 3. Check your robots.txt to ensure crawlers are not blocked. 4. Restart the crawl: Left Sidebar → OTTO SEO → Site Audit → Overview (Website Overview) → Recrawl Site 5. If you are using Cloudflare or a WAF, whitelist crawler IPs — contact Search Atlas support to obtain the current list of crawler IP ranges to add to your firewall rules. Note: A character encoding corruption bug affecting Cloudflare-deployed OTTO scripts has been resolved and the updated script deployed to production. If you previously disengaged OTTO due to special character corruption or display issues, you can now safely reconnect your Cloudflare integration by navigating to your OTTO project's Cloudflare settings and re-enabling the worker. Contact support if you need assistance re-engaging. Once the recrawl completes, the crawl status will update from "In Progress" to a finished state. 📊 Error: OTTO health score not updating What's happening Your fixes have not been revalidated yet. How to fix it 1. Wait at least 30 minutes. 2. Trigger a manual re-crawl: Left Sidebar → OTTO SEO → Site Audit → Overview (Website Overview) → Recrawl Site 3. Confirm your fixes are live on your actual site — not just in OTTO's optimization dashboard. 4. Refresh the dashboard. 5. Use "Validate Fix" on specific tasks to trigger targeted revalidation. After the re-crawl finishes, your OTTO health score will reflect the validated fixes. ➕ Error: Can't create a new project What's happening The domain format is incorrect or the domain already exists in your account. How to fix it 1. Enter the domain without the protocol: ✅ yourdomain.com ❌ https://yourdomain.com 2. Check whether the domain already exists in your projects. 3. Click Create only once to avoid duplicate submissions. 4. Verify your plan limits: Top-right Avatar → Billing → Plans & Top-ups (Billing) 5. Try incognito mode if the issue persists. Once the domain format is correct and your plan has available slots, the project will be created successfully. ⏳ Error: OTTO tasks stuck as "Pending" What's happening Approved tasks have not executed yet. How to fix it 1. Wait up to 15 minutes for the task queue to process. 2. Check Google Search Console (GSC) permissions — you must be an Owner or Full User. 3. If tasks remain pending for more than 24 hours, cancel and re-approve them. 4. Check for noindex tags that may be blocking execution. 5. Confirm your CMS integration is active. Resolving permission or integration issues typically unblocks pending tasks within minutes. 🧩 Error: Schema generation or deployment fails What's happening Schema markup is not being generated or deployed successfully to your site. How to fix it 1. Click the purple Generate button before attempting to deploy. 2. Clear your browser cache and try again. 3. If the AI Agent appears stuck while generating schema in batches, refresh the session and re-prompt. If the issue persists, contact support and include your session link. 4. If the error persists, it is a system-level issue — contact support with your project URL and an error screenshot, as engineering escalation may be required. After generating schema successfully, the Deploy button becomes active and your schema publishes to your site. 🧱 Error: OTTO deployed fix is adding unwanted content to my site What's happening A deployed OTTO fix (for example, Heading Length) is injecting content you did not intend on your front-end. How to fix it 1. Go to your OTTO project. 2. Locate the deployed fix under Optimizations or Deployments. 3. Click Undeploy on the specific fix (for example, Heading Length). Undeploying removes the change from your front-end immediately. 🚫 Error: Quota Exhausted when adding a new OTTO site What's happening You have reached the OTTO site slot limit on your current plan. OTTO site slots are tracked separately from Site Auditor Projects — having available Site Auditor Projects does not mean you have available OTTO site slots. How to fix it 1. Check your plan limits in Top-right Avatar → Billing → Plans & Top-ups (Billing). 2. Confirm whether you have available OTTO site slots (distinct from Site Auditor Projects). 3. If the dashboard count appears inconsistent with your plan, contact support. Once you free up or upgrade your OTTO site slots, you can add the new site. 🧠 Error: Atlas Brain / AI Agent shows "I'm temporarily unable to process your request" or persistent Keyword Gap Analysis errors What's happening The Atlas Brain / AI Agent service is returning an error or failing to process requests. Platform-wide Atlas Brain errors occur occasionally, are monitored by the engineering team, and are typically resolved within 48 hours. How to fix it 1. Wait a few minutes and retry. 2. Hard-refresh the browser. 3. Check the Search Atlas status page. 4. If the error is platform-wide, engineering is typically already aware. Contact support with your session link to confirm whether a known issue is active and get an estimated resolution time — this is more effective than running self-troubleshooting steps that will not resolve a platform-wide outage. If it is a platform-wide issue, the Search Atlas engineering team will resolve it — typically within 48 hours. 🏠 Error: Active Projects panel shows zero values or stale data What's happening The Active Projects panel on the dashboard homepage may display zero values until manually refreshed, while the Portfolio Summary updates automatically. How to fix it 1. Manually trigger a page refresh to repopulate the Active Projects values. 2. If a standard refresh does not update the values, hard-refresh your browser: Ctrl + Shift + R (Windows) / Cmd + Shift + R (Mac) 3. A fix for this behavior has been deployed. If the issue persists after refreshing, contact support. After refreshing, the Active Projects panel will display your current project data. 🔄 Error: Data looks outdated What's happening Data refresh cycles have not completed yet. How to fix it 1. Wait for the next scheduled refresh cycle — typically 24–48 hours. 2. Hard-refresh your browser: Ctrl + Shift + R (Windows) / Cmd + Shift + R (Mac) 3. Verify the date range filter is set correctly. 4. If data still appears outdated after a full refresh cycle, contact support with your project URL. Once the refresh cycle completes, your data will reflect the latest available information. 🎯 This guide covers the most common Search Atlas platform issues. If none of these steps resolve your problem, contact Search Atlas support with your project URL, error screenshot, and session link — the team can escalate to engineering when needed.

🔍 Fix a Stuck or Slow Site Audit Crawl

🧭 Overview A Site Audit crawl typically completes within a few minutes to a couple of hours, depending on your site's size and crawl settings. In some cases, crawls can take longer or appear stuck entirely. This article explains the most common causes and how to fix them. ⏱️ How Long Should a Crawl Take? Crawl duration varies based on several factors: - Small sites (under 500 pages): Usually 5–30 minutes - Medium sites (500–5,000 pages): Typically 1–4 hours - Large sites (5,000+ pages): Can take several hours If your crawl has been running for more than 24 hours without completing, something is likely preventing it from finishing normally. ⚠️ Common Causes of a Stuck or Slow Crawl - JavaScript rendering is enabled: Crawling JavaScript-heavy pages is significantly more resource-intensive. When JS rendering is on and the crawl budget is set to a very low number (1–2), crawls can take 17–31 hours or more. - Low crawl budget setting: A crawl budget of 1–2 pages per second drastically slows progress on larger sites. - Site errors or redirect loops: Pages that loop, return errors, or are unreachable can cause the crawler to stall on a single URL. - Server-side blocking: Some servers detect and block automated crawlers, causing requests to hang indefinitely. - Very large or complex sitemaps: Sitemaps with thousands of URLs or nested structures can slow the initial crawl setup. 🛠️ Step-by-Step Troubleshooting 1. Check your JavaScript rendering setting. If your site does not rely heavily on client-side rendering, disable JS rendering in your audit settings. This is the single most common cause of extremely long crawls. 2. Increase your crawl budget. Navigate to your Site Audit settings and raise the crawl budget above 1–2. A setting of 5–10 is a good starting point for most sites. Higher budgets complete crawls faster. 3. Cancel and restart the crawl. If the crawl has been running for more than 24 hours, cancel it and launch a fresh crawl with the adjusted settings above. Stalled crawls do not self-recover. 4. Verify your site is reachable. Open your website in a browser and confirm it loads without errors, redirects, or login walls. The crawler must be able to access your pages freely. 5. Check for crawl errors in the audit report. After restarting, monitor the audit dashboard for error messages. A message indicating a crawl is failing or looping on a single URL points to a specific page or redirect issue—review that URL directly. 6. Review your robots.txt file. Make sure your robots.txt is not inadvertently blocking the Search Atlas crawler from accessing key sections of your site. 7. Reduce scope for large sites. If your site has tens of thousands of pages, consider limiting the crawl to a specific subdirectory or URL prefix to isolate and test performance before running a full crawl. ✅ Best Practice Settings for Faster Crawls - Disable JavaScript rendering unless your site requires it for content to load. - Set your crawl budget to 5 or higher for most sites. - Keep your sitemap clean and free of redirect chains or broken URLs before initiating a crawl. - Schedule crawls during off-peak hours to reduce the chance of server-side throttling. 💬 Still Need Help? If you have tried the steps above and your crawl is still stuck or failing, our team can investigate 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.

🏷️ Meta Generator Troubleshooting

This article covers: - Meta title generation - meta description generation - URL analysis failures - bulk generation workflows - CMS implementation guidance - project saving behavior - and Google re-crawling delays. The Meta Generator helps create: - SEO-friendly titles - meta descriptions - and search snippets based on: - your live page content - imported URLs - or manually provided content. Because generation depends on: - page accessibility - crawler visibility - AI summarization - and search engine behavior, issues are commonly caused by: - blocked pages - JavaScript rendering - incorrect content inputs - or Google cache delays. ⚠️ Error 1: Meta Generator is not producing results for my URL What's happening The Meta Generator first crawls your page content. If: - the page blocks crawlers - requires login - uses heavy JavaScript rendering - or returns an error, the tool cannot analyze the content properly. Steps to try 1. Confirm the URL loads publicly without login. 2. Open the URL in an incognito/private browser window. 3. Verify the page does not return: - 404 - 403 - 500 - or redirect loops. 4. If your site uses React, Vue, or Next.js rendering, use Manual Content instead of URL import. 5. Paste the visible page text manually into the generator. 6. Disable temporary bot protection if possible. 7. Confirm the page is not blocked by robots.txt. 8. Test another page from the same domain. 9. Retry generation after refreshing the tool. 10. Contact support if all public pages fail consistently. Important Notes - JavaScript-rendered sites are the most common cause of crawl failures. - Publicly accessible HTML pages generate the most reliable results. ⚠️ Error 2: Generated meta title is too long — over 60 characters What's happening AI-generated titles sometimes exceed Google's visible display limits. Google typically truncates: - titles longer than ~60 characters - or titles exceeding pixel width limits. Steps to try 1. Use the built-in character counter. 2. Watch for the red overflow warning. 3. Click Shorten Title if available. 4. Move your primary keyword toward the beginning. 5. Remove filler phrases or unnecessary branding. 6. Avoid duplicate modifiers: - best - top - ultimate - complete - etc. 7. Keep titles concise and readable. 8. Prioritize search clarity over creativity. 9. Compare against top-ranking SERP examples. 10. Re-generate titles using a shorter prompt. Important Notes - Google may still rewrite titles dynamically. - Shorter titles often improve mobile visibility. ⚠️ Error 3: Generated meta description is too short — under 120 characters What's happening Very short meta descriptions: - reduce click-through effectiveness - and may not communicate enough search relevance. Steps to try 1. Click Expand Description if available. 2. Aim for 150–160 characters. 3. Add: - value proposition - CTA - differentiators - and target keywords. 4. Include the primary benefit clearly. 5. Avoid vague generic descriptions. 6. Mention audience intent directly. 7. Add emotional or action-oriented language carefully. 8. Manually extend short outputs where needed. 9. Compare against competitor SERP snippets. 10. Re-run generation with stronger context. Important Notes - Google may rewrite descriptions dynamically. - Better descriptions improve CTR more than rankings directly. ⚠️ Error 4: Meta tags were generated but I cannot see where to apply them to my site What's happening Meta Generator creates: - optimized tag text but does not automatically publish changes unless integrated through: - OTTO - CMS Integration - or automation workflows. Steps to try 1. Copy the generated meta title. 2. Copy the generated meta description. 3. Apply tags manually inside your CMS. 4. WordPress users: - Yoast SEO - Rank Math - All in One SEO. 5. Shopify users: - Product/Page Editor → SEO Section. 6. Webflow users: - Page Settings → SEO Settings. 7. Confirm the tags save correctly. 8. Clear website cache after updating. 9. Use OTTO or CMS Connectors for automation workflows. 10. Verify the final page source after publishing. Important Notes - Meta Generator itself does not modify live pages automatically. - CMS implementation varies by platform. ⚠️ Error 5: Generating meta tags for many pages at once is slow What's happening Bulk generation processes: - URLs sequentially - through AI generation pipelines. Large batches create: - queue delays - longer processing times - and possible timeout risk. Steps to try 1. Leave the browser tab open during processing. 2. Process URLs in batches of 25 or fewer. 3. Avoid running multiple large jobs simultaneously. 4. Prioritize highest-value pages first. 5. Reduce unnecessary regeneration attempts. 6. Verify imported URLs are valid before processing. 7. Retry failed batches separately. 8. Use off-peak hours for very large batches. 9. Save completed results incrementally. 10. Refresh the page only after confirming progress completed. Important Notes - Large jobs naturally process slower. - Batch segmentation improves stability significantly. ⚠️ Error 6: Generated meta description contains information that is not on my page What's happening The AI may: - infer context - hallucinate details - or pull assumptions when: - source content is weak - vague - incomplete - or semantically ambiguous. Steps to try 1. Fact-check all generated descriptions. 2. Add accurate content manually into Manual Content. 3. Avoid vague page copy. 4. Include exact product/service details. 5. Re-run generation after improving source text. 6. Remove unsupported claims. 7. Verify pricing/statistics manually. 8. Compare against actual visible page content. 9. Use shorter, more focused prompts. 10. Never publish generated metadata without QA review. Important Notes - AI-generated metadata should always be reviewed manually. - Better source content produces more accurate SEO snippets. ⚠️ Error 7: Meta Generator results are not saving What's happening Generated metadata is tied to: - the currently selected project. Without an active project: - results cannot persist correctly. Steps to try 1. Confirm a project is selected before generation. 2. Use the top-right project selector. 3. Generate metadata again after selecting the project. 4. Click Save to Project manually. 5. Refresh the page after saving. 6. Check OTTO → On-Page → Meta Tags. 7. Avoid switching projects mid-generation. 8. Ensure you have edit permissions for the project. 9. Retry generation if saving silently fails. 10. Contact support if results disappear repeatedly. Important Notes - No active project = no persistent save behavior. - Project mismatches are a common workflow issue. ⚠️ Error 8: My website is showing old meta tags even after I updated them What's happening Google caches metadata from previous crawls. Even after updating your site: - search results may continue showing old snippets - until Google re-crawls the page. Steps to try 1. Confirm the live page source contains the updated tags. 2. Open the page source directly in your browser. 3. Use Google Search Console → URL Inspection. 4. Click Request Indexing. 5. Submit the URL through Authority Building → Indexer. 6. Clear CDN and site cache. 7. Confirm canonical tags are correct. 8. Avoid conflicting SEO plugins. 9. Wait 24–72 hours after re-crawl requests. 10. Monitor search snippet updates over several days. Important Notes - Google controls final SERP snippet rendering. - Updated tags do not appear instantly. Most Meta Generator issues are not caused by failed AI generation. They are usually related to: - inaccessible URLs - JavaScript-rendered pages - weak source content - CMS implementation gaps - bulk queue delays - or Google re-crawl timing. In many cases, the generator is functioning correctly — the workflow simply requires: - cleaner source content - better SEO structure - stronger implementation practices - or indexing patience. 👉 Strong meta optimization depends heavily on: - accessible crawlable pages - concise title structure - high-quality descriptions - correct CMS implementation - project organization - Google re-indexing workflows - and post-generation QA validation.

🧠 Search Atlas Troubleshooting Guide (Diagnosis Layer)

This guide helps you identify and understand issues across Search Atlas services. ⚠️ Scope: This article covers diagnosis only — it does not contain resolution steps. Once you have identified the issue category, proceed to the relevant fix guide or escalation path. It answers: - What is happening? - Where is it happening? - Why is it happening? Before fixing anything, this is your diagnosis layer. 🧭 How to Use This Article Use this when: - A user reports an issue - A feature is not behaving as expected - You need to classify the problem before escalating 🛠️ Support Tool Health: The Intercom FIN / Search Atlas Connector instability issue (QP-5196) has been resolved. If FIN responses seem incorrect or incomplete, re-verify connector health before relying on its answers to diagnose customer issues. 🔍 SYSTEM DIAGNOSIS MAP 🧠 Root Categories ⚙️ Infrastructure Failures - Database unavailable - Redis down - Service unreachable - Memory crashes 👉 Symptoms: - 503 errors - Timeouts - Data not loading 👉 Next step: For resolution steps, see the Infrastructure Fix Guide or escalate via the Infrastructure / Platform engineering channel. 🔄 Async / Queue Failures - Celery tasks missing - Jobs stuck or never completed - Crawls not finishing 👉 Symptoms: - Spinners forever - “In progress” stuck - No visible error 📌 Known instance: The Atlas Brain indefinite spinner during analysis (LPS-442) is a confirmed example of this pattern — if you see it, check this category first. Note: this is distinct from the Atlas Brain 'no connection' freeze pattern, where the UI may report a false 'Success' state while the underlying deployment fails (see Atlas Brain / Website Studio section below). Both fall under async/queue failures but have different diagnostic indicators and escalation paths. 📌 Site Audit / OTTO sync note: Site Audit and OTTO now use the QP notify-data-change API (OTTO-2082). If data sync issues appear in these modules, verify notify-data-change pipeline health in addition to standard Celery/queue checks. 💳 Credit consumption note: Repeated automatic retries caused by connection errors can consume user credits. If a customer reports unexpected credit depletion, check for correlated Atlas Brain connection errors and retry loops in the same timeframe; if confirmed, escalate to the credits refund team with evidence of retry loops for manual credit restoration. Do not advise customers to re-run the tool until the underlying connection error is resolved. 👉 Next step: For resolution steps, see the Async / Queue Fix Guide or escalate via the relevant service's engineering channel (Linkgraph, Atlas Brain, or Data Pipelines). 🔗 External Dependency Failures - Gemini / OpenAI limits - SEMRush unavailable (now fetched asynchronously via Celery tasks per SE-536 — failures may surface as stuck jobs rather than immediate errors; check the Async/Queue Failures category in parallel) - DataForSEO throttling 👉 Symptoms: - Missing data - AI not generating - Partial outputs 👉 Next step: For resolution steps, see the External Dependency Fix Guide or escalate via the Data Pipelines engineering channel. 🖥️ Frontend / UI Failures - React errors - Graphs not rendering - reCAPTCHA issues - Billing Modal Freeze — The Add Payment Method modal may enter an indefinite loading state after clicking Add Card, with no error shown and no card added. This is a known frontend issue (QPB-697). Do not advise the customer to retry repeatedly; escalate to the billing team. - Press Release / Signal Genesys Publish Blocked by Image Validation — If a customer cannot publish and sees inline image errors in Step 3, the cause is an unsupported image format (WEBP, AVIF, HEIC, BMP, TIFF, ICO) or a corrupt/mislabelled file. This is expected validation behavior as of AB-970, not a system failure. 👉 Symptoms: - White screens - Broken UI elements - Actions not working 👉 Next step: For resolution steps, see the Frontend Fix Guide or escalate via the Frontend engineering channel. 🔀 Inter-Module Pipeline / Bridge Failures - API bridges between modules (e.g., Content Genius → Link Lab) can enter a blocked state - Actions complete on one side but do not propagate to the target module - Reference escalation: 215474220017778 👉 Symptoms: - Source module reports success - Target module never receives the handoff - No visible error in either module 👉 Next step: Escalate to engineering with pipeline telemetry data for the affected modules. 🧩 SERVICE-LEVEL DIAGNOSIS 🔧 Linkgraph (Core API) 🔴 Most Critical Patterns - Metrics not updating → queue issue - 503 errors → DB connection exhaustion - Jobs stuck → Celery worker version mismatch or task queue not processing (workers running an outdated task signature, or queue is backed up / not consuming — observable as tasks staying in PENDING/RECEIVED without progressing) - Crawls stuck → timeout on large sites 👉 Insight: Linkgraph issues are usually backend or queue-related 🤖 Content Assistant 🔴 Most Critical Patterns - AI not generating (hard failure) → Gemini quota (429) - AI reports success but output not applied (silent failure) → backend sync issue; UI may show 'Success' while generated content is not persisted or activated - Content incomplete → keyword service failing - JSON errors → malformed LLM output 👉 Insight: Most failures come from external AI dependencies, but watch for silent successes where the UI confirms an action that did not actually take effect on the backend. 🧠 Atlas Brain / Website Studio 🔴 Most Critical Patterns - Infinite spinner during analysis (LPS-442) → queue/async failure; see Async/Queue Failures category. Diagnostic indicator: UI shows a persistent spinner with no status update. Distinct from the 'no connection' freeze pattern below. - 'No connection' freeze with false success states → backend connection drop causing NLP terms and schema deployment to fail silently while the UI displays 'Success' (escalation 215474307923656). Diagnostic indicator: UI confirms an action that did not propagate to the backend. Different diagnostic path and escalation than LPS-442. - CMS Connector State Mismatch — Atlas Brain may display a disconnected status even when the connector is active on the backend (cases 215474386800374, 215474258075754). Verify via backend admin before advising the customer to reconnect. - AI Agent Schema/NLP Deployment Sync Failure — Success status displayed but terms not activated (case 215474307923656). Check backend sync state. This may require manual deployment and engineering escalation (reference pattern: SPE-692 / AIAGENT-1904). - Publish Blocked by False Disconnection Error — Atlas Brain reports website not connected despite the site being active (cases 215474258075754, 215474386800374). Verify connection state on backend before advising reconnection or manual publish workaround. - Unexpected credit depletion → connection errors can trigger URL Indexer or other jobs to retry automatically and burn credits (case 215474438977629); correlate with Atlas Brain or connector error events, and escalate to the credits refund team if retry loops are confirmed. 👉 Insight: Atlas Brain failures often present as successful UI states masking backend faults — always verify actual backend state before trusting the UI. 🖥️ Customer Frontend 🔴 Most Critical Patterns - Login issues → reCAPTCHA - Graphs missing → null data - App crashes → chunk load errors - Billing Modal Freeze (QPB-697) → Add Payment Method modal hangs after clicking Add Card with no error and no card added; escalate to the billing team rather than advising retries. 👉 Insight: Frontend errors are usually data-state or loading timing issues 🔍 Keyword Explorer 🔴 Most Critical Patterns - No keyword data → ClickHouse failure - Missing enrichment → SEMRush unavailable - Slow results → DataForSEO limits 👉 Insight: This service depends heavily on external data pipelines 🔗 Backlink App 🔴 Most Critical Patterns - Data not loading → DB issues - No major user-facing errors → mostly infra/logging 🧠 KEY INSIGHT 👉 Most issues are not bugs They are: - System limits - Dependencies - Scale problems 🔑 Golden Rule Before fixing anything: 👉 Ask: Is this: UI, Data, Queue, Infrastructure, or Inter-Module Pipeline? ➡️ Next Steps After Diagnosis Once you have classified the issue: - Match the category to the relevant fix guide or runbook - Apply P-level severity classification (P0–P3) based on customer impact and scope - Escalate through the appropriate engineering channel (Linkgraph, Atlas Brain, Frontend, Data Pipelines, or Billing) with the diagnosis category, observed symptoms, and any referenced ticket IDs (e.g., LPS-442, SE-536, SPE-692, QP-5196, QPB-697, OTTO-2082, AB-970) - Hand off to the on-call engineer using the standard escalation protocol if the issue is P0/P1 or customer-blocking

⚠️ Robots.txt "Disallow: /" Warning in the Search Atlas WordPress Plugin

The Search Atlas WordPress plugin flags a Robots.txt "Disallow: /" warning when your robots.txt file contains a rule that blocks all search engine crawlers from your entire website — a single misconfigured line that can silently remove every page from Google search results. Follow the steps below to locate and remove the rule in under two minutes. 📌 Version requirement: This warning requires Search Atlas WordPress plugin version 2.4 or later. A detection bug in earlier versions (fixed May 2026, WP-322) prevented the warning from firing even when Disallow: / was present. Update the plugin before relying on this check. ⚠️ What the "Disallow: /" Warning Means Your robots.txt file tells search engines which pages they are allowed to crawl. The line Disallow: / under a User-agent directive instructs every crawler — including Googlebot — to stay off your entire website. The Search Atlas WordPress plugin flags this as a critical warning because one misconfigured line can de-index your whole site without any visible error in WordPress itself. Common causes include: - A site left in development or staging mode — WordPress automatically writes Disallow: / when the "Discourage search engines" checkbox is enabled under Settings → Reading. - A manually edited robots.txt file containing a leftover or accidental rule. - A third-party plugin or theme that wrote an overly broad rule during initial setup. Removing the rule restores full crawl access immediately. Previously de-indexed pages may take several days to weeks to reappear in Google search results as Googlebot re-crawls the site. 🔍 How to Find the Source of Your Robots.txt in WordPress Your robots.txt file is publicly accessible at https://yourdomain.com/robots.txt. Replace yourdomain.com with your actual domain. For WordPress Multisite or subdomain installs, check robots.txt at the root domain level, not the subsite URL. In WordPress, one of three sources controls its content: - WordPress core setting — Settings → Reading → "Discourage search engines from indexing this site" checkbox. - SEO plugin — Tools such as Yoast SEO, Rank Math, or All in One SEO generate and manage robots.txt from their own settings panels. - Physical file — A static robots.txt file in your site's root directory, editable via FTP, cPanel File Manager, or SSH. Identify which source applies to your site, then follow the matching fix below. 🛠️ How to Fix the "Disallow: /" Warning in WordPress Choose the method that matches how your robots.txt is managed. Fix via WordPress Settings (most common) 1. In your WordPress admin dashboard, go to Settings → Reading. 2. Find the checkbox labeled "Discourage search engines from indexing this site". 3. Uncheck the box. 4. Click Save Changes. WordPress removes the Disallow: / line automatically. Visit https://yourdomain.com/robots.txt in your browser to confirm the line no longer appears. Fix via an SEO Plugin 1. Open your SEO plugin's robots.txt editor — for example, Yoast SEO → Tools → File Editor, or Rank Math → General Settings → Edit robots.txt. 2. Find any line that reads Disallow: / under a User-agent: * block. 3. Delete the line entirely, or replace it with Disallow: (an empty value) to permit full crawl access. 4. Save the file. The updated rule takes effect immediately for all new crawl requests. Fix via a Physical File (FTP or File Manager) 1. Connect to your server using FTP, SSH, or your hosting control panel's File Manager. 2. Open the file robots.txt located in your site's root directory. 3. Delete the line Disallow: /, or change it to Disallow: to allow all crawling. 4. Save and upload the file. Confirm the change at https://yourdomain.com/robots.txt before re-running the Search Atlas audit. ✅ How to Verify the Fix in the Search Atlas WordPress Plugin After editing your robots.txt, confirm the warning is cleared directly in the Search Atlas WordPress plugin: 1. In your WordPress admin dashboard, go to OTTO SEO → Site Audit → Overview (Website Overview). 2. Click the Recrawl Site button to start a fresh scan. 3. Open the Robots.txt section in the audit results — the "Disallow: /" warning should no longer appear. A clean result in the Robots.txt section confirms search engines can crawl your site. If the warning persists, check whether a second source — a plugin or a physical file — is overwriting your robots.txt with the same rule. 💡 Robots.txt Best Practices to Prevent Future Warnings - Reserve Disallow: / for local or staging environments only — it must never appear in a live production site's robots.txt. - Use targeted disallow rules to block specific folders (e.g., Disallow: /wp-admin/) rather than blanket restrictions. - Audit after every site migration. WordPress often retains the "Discourage search engines" checkbox state when a staging site is cloned to production. - Re-run the Search Atlas Site Audit after major plugin updates, theme switches, or server migrations to catch robots.txt regressions early. Following these habits protects your site from accidental crawl blocks before they affect your rankings. 🎯 You now know what the Search Atlas "Disallow: /" warning signals, where the rule originates in WordPress, and how to remove it. Re-run the Site Audit to confirm your robots.txt is clean — then explore the Search Atlas Site Audit overview to identify and resolve any other critical SEO issues on your site.

🛠️ Why Site Audit Stalls or Content Genius Shows Outdated Content in Search Atlas

A stalled Site Audit crawl or a desynced Brand Vault causes Search Atlas to work with outdated data. Use the steps below to identify which issue applies and resolve it. 📍 Navigation Paths Site Audit: Search Atlas → OTTO SEO → Site Audit → All Audits → View Audit Brand Vault: Header (apps-grid icon) → More Features → Brand Vault 🧠 Common Reasons a Site Audit Gets Stuck 🔢 1. Crawl Limit Set Too High If the Pages to Crawl limit is set too high, the crawler may slow down or stall. This is especially common on sites with: - Heavy pages - Slow server response - Many redirects 🔁 2. Redirect-Heavy Pages If the audit reports a large number of redirect pages in the Issues summary, the crawl may appear stuck while processing them. Redirect chains increase crawl time and can delay completion — counts in the high double-digits or above on a single audit are generally enough to noticeably slow the crawl. ⏱ 3. Temporary Processing Delays Crawls do not always complete in strict numerical order. It is normal for an audit to pause near the end while processing remaining URLs. 🤖 4. AI Processing Rate Limits on AI-Graded Audits Previously, AI-graded audits could stall during AI-powered page summary generation if the AI processing layer hit a daily rate limit, with no clear user-facing error. This issue has been resolved on the platform side. If you have an audit that stalled before the fix, re-run it — it should complete normally. 🛰️ 5. OTTO Diagnostics Scan Running Indefinitely This is distinct from the crawl-limit stall above. If an OTTO Diagnostics scan runs indefinitely and surfaces the error "Could not reach homepage, try again later", this was caused by a platform-side issue that has now been resolved. Retry the OTTO Diagnostics scan — it should now complete successfully. ⚙️ How to Troubleshoot a Stuck Site Audit Crawl Step 1 — Lower the Crawl Limit 1. Open the affected audit. 2. Go to Audit Settings. 3. Locate Pages to Crawl. 4. Reduce the limit to 200–500 pages. 5. Save and rerun the audit. Smaller crawls help confirm whether page weight or redirects are causing the delay. Step 2 — Re-run the Audit After lowering the crawl limit, restart the audit and monitor progress in the All Audits view. If the audit completes successfully at a lower limit, the issue is configuration-related. 💡 Why Content Genius References Old Website Content Content Genius generates articles using brand context stored in the Brand Vault. The Brand Vault is populated through RAG (Retrieval-Augmented Generation) ingestion — an automatic process that indexes your site content from the most recent completed Site Audit. If the Brand Vault fails to re-sync after a site update and re-crawl, Content Genius will continue referencing your old website content even when the Site Audit shows a newer crawl date. 📣 Platform note: A previously identified platform-side ingestion bug could cause silent Brand Vault desync independent of any user action — affected crawls were never properly ingested into RAG even when users manually triggered re-syncs. This issue has been resolved. If you experienced stale Content Genius output before the fix, trigger a fresh Brand Vault sync now and verify that generated content reflects your current crawl data. 🔍 Symptoms of a Brand Vault Desync - Content Genius articles reference pages, products, or copy that no longer exist on your site. - Updated page titles or descriptions do not appear in generated content. - The issue persists across multiple Content Genius generations after a site update. 🔄 How to Refresh the Brand Vault After a Site Update 1. Go to Header (apps-grid icon) → More Features → Brand Vault. 2. Confirm your most recent Site Audit shows a Completed status under Site Audit → All Audits. 3. In Brand Vault, select the Re-ingest or refresh option to pull in the latest Site Audit data. 4. Wait for the ingestion process to finish before generating new content. 5. Verify: Generate a test article in Content Genius and confirm it references current site content. If the output still appears outdated, contact support with your Brand Vault ID so the team can confirm your underlying url_sources were properly re-hashed. Once the sync completes, Content Genius will reference your updated website content. 🚨 When This May Be a System Issue Contact support if any of the following apply after troubleshooting: - The Site Audit crawl remains stuck across multiple runs at the same page count. - Lowering the crawl limit does not resolve the stall. - Content Genius still references old site content after the Brand Vault has been refreshed and the Site Audit shows Completed. - Other users on your account are experiencing similar behavior. Support may already be tracking the issue internally. ❓ Frequently Asked Questions ❓ Why does my audit stop at the same number every time? This often indicates redirect-heavy pages or slow server responses near the end of the crawl. Reduce the Pages to Crawl limit and rerun to confirm. ❓ Is a stuck audit caused by my site configuration? Usually yes. Lowering the crawl limit helps isolate the cause. If the audit completes at a lower limit, the issue is configuration-related. ❓ Should I keep rerunning the audit without changing settings? No. Repeated reruns without adjusting settings will not resolve a stall. Reduce the crawl limit first, then rerun. ❓ Why does Content Genius still use my old site content after I updated my website? Content Genius reads brand context from the Brand Vault, which syncs from your latest Site Audit via RAG ingestion. If the Brand Vault did not re-ingest after your most recent Site Audit completed, it will still reference old content. Go to Header (apps-grid icon) → More Features → Brand Vault and trigger a refresh to resolve this. If a test article still looks stale afterward, contact support with your Brand Vault ID. ❓ Do I need to contact support? Only if the crawl remains stuck after reducing the crawl limit and rerunning, or if Content Genius still references old content after a Brand Vault refresh. Most issues resolve through the troubleshooting steps above. 🎯 You now know how to resolve stalled Site Audit crawls and fix Content Genius stale output caused by Brand Vault desync. If issues persist after following the steps above, contact the Search Atlas support team for further assistance.

🔍 OTTO Pixel Installed But Not Detected

🔍 Why the Pixel Shows in Source but Fails the Scan When you add the OTTO pixel to your site and confirm it appears in the page source, your installation is technically correct. The Not Detected status is almost always caused by your site's bot-protection or firewall blocking the Search Atlas crawler before it can read your page HTML at all. Instead of seeing your pixel, the crawler receives an Access Denied, CAPTCHA, or JavaScript-challenge page and reports the pixel as missing. This is not a temporary caching issue and will not resolve on its own. It persists until the Search Atlas crawler IP addresses are explicitly allowed through your security layer. ​ 🚦 How to Confirm Bot-Protection Is the Cause Before changing any settings, check whether your site uses any of the following: Cloudflare (any plan, including free), Shopify's built-in bot protection, Boostmark, or any other web application firewall (WAF), CDN, or security plugin. If your site uses any of these, follow the fix for your platform below. If you are unsure, contact us via the chat widget and we can check our crawler logs for an Access Denied response from your domain. 🛒 Fix: Shopify Bot Protection 1. Log in to your Shopify Admin panel. 2. Go to Online Store → Preferences and confirm your store is not password-protected for external visitors. If your store is still in development mode with a storefront password enabled, the Search Atlas crawler cannot reach your pages at all — disable the password temporarily or add the crawler IPs to your password-page allowlist. 3. If you use a third-party Shopify anti-bot or fraud-protection app, open that app's settings and add the Search Atlas crawler IP addresses to its IP allowlist. The full crawler IP list is available inside Search Atlas at Left sidebar → OTTO SEO → Installation Guide, under the Crawler IP Whitelist section. 4. Save your changes and wait 10–15 minutes, then re-run the scan as described in the How to Re-Run the Scan section below. ☁️ Fix: Cloudflare Bot Protection Cloudflare is the most frequent cause of OTTO pixel detection failures. Even the free plan's Bot Fight Mode will silently block the Search Atlas crawler and serve it a JavaScript-challenge page instead of your actual HTML, making the pixel invisible to the scanner. 1. Log in to your Cloudflare dashboard and select the domain connected to your OTTO site. 2. Go to Security → Bots and note whether Bot Fight Mode or Super Bot Fight Mode is enabled. 3. Go to Security → WAF → Custom Rules and click Create rule. Configure it as follows: set Field to IP Source Address, set Operator to is in, then paste each Search Atlas crawler IP address as values — the complete list is available at Left sidebar → OTTO SEO → Installation Guide, under Crawler IP Whitelist. Set the Action to Skip → WAF managed rules, and if the option appears, also skip Bot Fight Mode for these IPs. 4. Save and deploy the rule. Cloudflare applies custom WAF rules within seconds. 5. Trigger a new pixel scan as described in the How to Re-Run the Scan section below. Important: Do not disable the Cloudflare proxy (orange cloud icon) for your domain — the custom WAF allowlist rule above is sufficient and keeps your site fully protected. 🔒 Fix: Boostmark and Other WAFs or CDNs If your site uses Boostmark or another WAF, security plugin, or CDN not listed above, the fix is the same: whitelist the Search Atlas crawler IP addresses in that platform's trusted-IP or allowlist section. 1. Log in to your WAF or security tool's admin dashboard. 2. Locate the IP allowlist section, commonly labelled Trusted IPs, IP Allowlist, or Whitelist Rules. 3. Add each IP address from the Search Atlas crawler list. The full list is available at Left sidebar → OTTO SEO → Installation Guide, under Crawler IP Whitelist. 4. Save your changes and wait 5–10 minutes before re-running the scan. ✅ How to Re-Run the OTTO Pixel Scan After whitelisting the crawler, trigger a fresh scan to confirm your pixel is now detected: 1. In Search Atlas, navigate to Left sidebar → OTTO SEO → All Sites. 2. Locate your site in the list and click into it to open the site dashboard. 3. Navigate to Left sidebar → OTTO SEO → Overview and find the pixel status indicator at the top of the page. 4. Click Re-scan or Verify Installation. The scan typically completes within a few minutes. 5. If the status changes to Detected, your site is fully connected and OTTO will begin automating SEO tasks on your next scheduled run. 💡 Other Causes to Rule Out If the pixel is still not detected after whitelisting the crawler IPs, confirm the following additional points: - Script placement in Shopify: The OTTO pixel must be placed inside the <head> tag of your theme.liquid file, directly before the closing </head> tag. Do not place it inside a conditional Liquid block or a deferred-load section, as the scanner may not execute those code paths. - Page cache not refreshed: If you use a caching plugin or Cloudflare's cache, purge the full-page cache after installing the pixel script so the scanner reads the updated live HTML rather than a cached version that predates your changes. - Content Security Policy (CSP) blocking: Some Shopify themes or third-party apps inject a CSP header that prevents external scripts from loading. Open your browser's developer console while loading your homepage and check for any CSP-related errors referencing the OTTO script domain. - Script only loads on some page types: Some themes conditionally inject scripts on certain templates. Confirm the pixel appears in the page source of your homepage, which is the page the scanner checks by default. 💬 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.

⚠️ Site Explorer – Current Position (CURR) Sort Error in Position Changes Tab

A known issue causes the view to break when you sort by the Current Position (CURR) column in the Position Changes page (Organic Positions tab), located under Site Metrics in the left sidebar. Your data is intact — sort by any other column to access it while our engineering team deploys a fix. 🔍 What Happens When You Sort by Current Position (CURR) Clicking the Current Position (CURR) column header in the Position Changes page (Organic Positions tab), under Site Metrics in the left sidebar, triggers a backend validation error, causing the view to fail entirely. The tab goes blank and becomes unusable until you select a different sort column. Who is affected: Any Search Atlas user who clicks the Current Position (CURR) column header to sort results in the Position Changes tab. Your data is not lost. All keyword and position change data remains intact and fully accessible when you sort by any other available column. 🛠️ Workaround: Sort by a Different Column Avoid clicking Current Position (CURR) to sort until the fix is deployed. Any other column header loads your data normally. 1. In Search Atlas, open Site Explorer and select your project. 2. Click the Position Changes tab under Organic results. 3. Click any column header other than Current Position (CURR) — for example, PREV, DIFF, TRAFFIC, or MONTHLY S. VOLUME. 4. Your results load and display as expected. After selecting an alternative sort column, your full keyword and position change data is visible and usable. 📡 Engineering Fix Status Our engineering team is aware of this issue and is actively working on a fix. No action is required on your end — the fix will roll out automatically, and the Current Position (CURR) sort will resume working without any changes needed from you. This article will be updated as soon as the issue is resolved. We appreciate your patience. 📞 When to Contact Support The workaround above restores access to your data in most cases. Contact our support team if: - Sorting by other columns also fails to load results in the Position Changes tab. - You cannot access Position Changes data through any column sort. - You see a different or unexpected error message on the Position Changes page. Reach us via the in-app chat bubble — our team will help you get back on track right away. 🌀 Our team is actively working to restore full sort functionality in the Position Changes tab — your keyword data is safe and accessible right now via any other sort column. If the workaround doesn't resolve your issue, reach out through in-app support.

🔧 Fix GSC Indexing Access Toast Surface Errors

🗺️ Overview When you connect Google Search Console (GSC) and attempt to enable indexing access in Search Atlas, you may see a persistent error notification (called a toast surface error) that does not resolve after refreshing the page or reconnecting your account. This article explains what causes these uncatalogued errors and walks you through every resolution path step by step. ⚠️ What Is a Toast Surface Error? A toast surface error is a brief error notification that appears in the corner of your screen during a runtime operation — in this case, while Search Atlas is attempting to authenticate your GSC connection and request indexing access. When the error is uncatalogued, it means the platform encountered an unexpected condition that does not map to a standard error code, making it harder to diagnose at a glance. Common symptoms include: - A red or orange toast notification appears immediately after clicking Enable Indexing Access. - The error reappears even after disconnecting and reconnecting your GSC account. - No specific error code or descriptive message is shown — only a generic failure alert. - The GSC property appears connected in your account settings but indexing access remains inactive. 🔍 Root Causes Uncatalogued toast surface errors during GSC indexing access are most commonly triggered by one or more of the following conditions: - Google permission propagation delay: After granting OAuth permissions in your Google account, Google can take several minutes to propagate access tokens. Attempting to enable indexing access before this completes causes a silent auth failure. - GSC property sync mismatch: If the GSC property you verified in Google Search Console has not fully synced to your Google account's API scope, Search Atlas cannot confirm ownership and will reject the indexing request. - API quota limits: The Google Indexing API enforces daily quota limits. If your Google account or project has exhausted its quota (200 URLs per day by default), all further indexing requests will fail without a descriptive error code. - Incorrect property type: The Google Indexing API only supports URL-prefix properties that use the exact verified format. Domain properties or improperly formatted URLs will cause a runtime failure at the toast level. - Stale OAuth token: Tokens cached from a previous session can become invalid if you changed Google account permissions externally without re-authorising inside Search Atlas. 🛠️ Step-by-Step Resolution 1. Wait and retry after 5–10 minutes. If you recently granted Google permissions, allow time for propagation. Close the modal, wait at least five minutes, then return to your GSC settings and attempt to enable indexing access again. 2. Verify your GSC property type. Open Google Search Console in a separate tab. Confirm the property you are connecting uses the URL-prefix format (e.g., https://www.example.com/) and that ownership is fully verified with a green status. Domain properties are not supported by the Indexing API. 3. Force a fresh OAuth connection. In Search Atlas, navigate to your account settings and fully disconnect your GSC account. Then clear your browser cookies and cache for Google accounts (accounts.google.com). Reconnect GSC from scratch and grant all requested permissions when prompted by Google. 4. Check your Google API quota. Sign in to Google Cloud Console (console.cloud.google.com), locate the project linked to your Search Atlas integration, and open APIs & Services → Quotas. Search for Indexing API and confirm your daily quota has not been exhausted. If it has, you must wait until midnight Pacific Time for the quota to reset. 5. Confirm the authorised Google account matches your GSC property owner. The Google account you use to authenticate Search Atlas must be the owner or full user of the GSC property — not just a restricted user. Delegated or view-only accounts cannot grant indexing access. 6. Try a different browser or incognito window. Browser extensions (particularly ad blockers and script blockers) can interrupt OAuth flows and produce silent toast errors. Retry the connection in a private/incognito session with extensions disabled. ✅ How to Confirm the Issue Is Resolved After completing the steps above, attempt to enable indexing access again. A successful connection will show a green confirmation toast and your GSC property status will update to Indexing Access: Active in your account settings. If the status updates without an error notification, the issue is resolved. 📋 Escalation Criteria Escalate to our support team if any of the following apply after completing all steps above: - The uncatalogued toast error persists across multiple browsers and a fresh OAuth connection. - Your Google Cloud Console shows quota available but the error still occurs. - The GSC property status alternates between connected and disconnected without any action on your part. - You are seeing the toast error on a newly created GSC property that has never been connected before. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ URL Validation Error for Non-Standard TLDs in Site Explorer and OTTO

A bug caused domains with non-standard top-level domains (TLDs) — such as .download — to be incorrectly rejected with an "Invalid URL" error in Site Explorer and OTTO. This issue is now resolved; re-add your domain and it should be accepted. 🔍 What Was Happening Search Atlas's URL validator did not recognize certain non-standard TLDs as valid, even when the domain was live and fully reachable. Affected customers saw this error message: Invalid URL [https://website.groww.download] The error blocked two key workflows: - Adding a domain to Site Explorer for competitive research and backlink analysis - Creating a new OTTO project for SEO automation on that domain Any domain using a non-standard TLD — not only .download — may have triggered this error. 📡 Engineering Status This issue has been resolved for most domains. The URL validator has been updated to correctly accept non-standard TLDs. No changes are required on your end — simply retry adding your domain. If you still encounter the error after retrying, use the workaround below or contact support. ⚙️ Steps to Retry Your Domain 1. Open Site Metrics → Overview or navigate to OTTO SEO in your Search Atlas dashboard. 2. Enter your full domain URL exactly as before (e.g., https://website.groww.download). 3. If you are in Site Explorer, click Analyze. 4. If you are in OTTO, click Create Project. 5. If the domain is accepted, no further action is needed — you are all set. 🧩 Workaround (if the error persists) If the standard OTTO project creation UI continues to reject your domain after retrying, add the OTTO project through the Atlas Agent chat interface as an interim step. Several customers have confirmed this approach successfully creates the project when the standard UI still throws the "Invalid URL" error. Open the Atlas Agent chat and request that it create the OTTO project for your domain. ❓ Not Your Issue? If the "Invalid URL" error appears during WordPress plugin setup or API key entry rather than when entering your domain in Site Explorer or OTTO, this article does not apply. Consult the OTTO WordPress plugin connection guide instead — the root cause is unrelated to TLD validation. ⚠️ Known Limitation If you use MCP to deploy domain-level schemas, you may encounter a separate HTTP 400 error (otto_urls not found). This is a distinct issue currently under active resolution and is unrelated to the TLD validation fix described above. Page-level schema deployment is unaffected. If this affects you, contact support for the latest status. 📞 When to Contact Support If you retry your domain and still see the "Invalid URL" error, contact our support team and include your full domain URL. Our team will investigate your account and domain configuration directly. 🌀 The URL validator fix is live — re-adding your domain to Site Explorer or OTTO should now work without error. If anything still looks off, our support team is ready to step in right away.

🌐 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.

🛠️ Why Does Crawl Monitoring Show 'No Data'? Troubleshooting Guide

Crawl Monitoring in Search Atlas may display No data for several expected reasons — a new or low-traffic domain, a mismatched date range, or a plan that does not include the feature. Use this guide to identify the cause and determine the right next step. 📊 What Crawl Monitoring Tracks Crawl Monitoring shows how search engines and AI bots interact with your website. It captures: - Total crawl requests - Average response time - Total download size - Crawler distribution - Historical crawl activity - Site indexation percentage - Crawl purpose (discovery vs. refresh) - Device / screen size - Load time distribution - Crawl frequency - Crawled pages 🤖 Crawl Analysis by Bot The Crawl analysis by bot subsection lets you filter crawl data by a specific bot and view dedicated donut charts for: - Site indexation % - Crawl purpose - By device - Load time distribution A healthy state shows properly sized donuts, a scrollable bot selector, and aligned legends — all of which render correctly after a recent UI fix. 🔍 Common Reasons Crawl Monitoring Shows No Data The most common causes fall into two scenarios depending on whether the dashboard has ever shown data before. Case 1: The dashboard has never shown data If Crawl Monitoring has never displayed data, one of the following is likely the cause: - The domain is new or recently launched - The domain has not had enough crawl activity yet — newer or low-traffic sites may need several weeks to months before meaningful data appears - The site has limited visibility or low crawler traffic - The account is not on a plan that includes Crawl Monitoring — confirm your tier (Pro, Agency, or Enterprise) on the Search Atlas pricing page - Search engines or AI bots have not crawled the site during the selected Daily, Weekly, or Monthly tab range in OTTO SEO → Crawl Monitoring Case 2: The dashboard previously had data but now shows none If Crawl Monitoring was working before and has suddenly gone empty, check the following: - Confirm the selected Daily, Weekly, or Monthly tab in OTTO SEO → Crawl Monitoring covers a period with known crawler activity - Check whether the domain was recently re-configured, re-verified, or changed in your account - In Crawl analysis by bot, set the bot selector dropdown to All bots or a bot with known activity - Confirm the site is still indexable and has not been blocked by an updated robots.txt - If none of the above explains the drop, this may indicate a data pipeline issue worth escalating to support ✅ What to Check First Run through this checklist before reporting an issue: 1. Confirm the selected tab in OTTO SEO → Crawl Monitoring 2. Try switching between Daily, Weekly, and Monthly tabs 3. Check whether the domain is new or recently launched 4. Confirm the site is indexable and not blocked by robots.txt 5. Confirm the account plan includes Crawl Monitoring 6. In Crawl analysis by bot, confirm the bot selector is set to All bots or a bot with known activity — not a specific low-traffic bot 7. Allow more time for crawler activity to accumulate if the site is new or low-traffic After completing these steps, you will know whether the empty dashboard is expected or signals a real issue that needs investigation. 💡 Crawl Monitoring and Domain Age Crawl Monitoring becomes more useful as your domain builds crawl history. For newer domains, some charts may remain empty until search engines and AI bots begin crawling the site more frequently. ❓ Frequently Asked Questions Does 'No data' mean Crawl Monitoring is broken? Not necessarily. No data is expected for new domains or sites that have not yet accumulated enough crawler activity. How old does a domain need to be before Crawl Monitoring shows data? There is no fixed threshold. Newer or low-traffic domains may need several weeks to months of active crawl activity before meaningful data appears. Is Crawl Monitoring available on every plan? No. Crawl Monitoring is available on Pro, Agency, and Enterprise plans. Check the Search Atlas pricing page to confirm whether your plan includes this feature. 🎯 You now know how to diagnose a "No data" state in Crawl Monitoring and what to do next. If the dashboard remains empty after waiting several weeks and ruling out every cause above, contact the Search Atlas support team so we can investigate further.

🛠️ Fixing Custom HTML Content Module Glitches After OTTO Activation

If your site shows broken headings or banner issues after activating OTTO, the cause is malformed HTML inside your Custom HTML Content module deployments — not OTTO itself. Delete the affected deployments and clear your site cache to restore your layout. 🔍 What Causes Custom HTML Content Module Glitches Malformed HTML structure inside the Custom HTML Content module's deployments causes overwritten headings, broken banners, and layout shifts. OTTO does not generate or modify this content — the problem originates from how the HTML was structured before or during deployment. OTTO's global rollback and undo features do not reach inside the Custom HTML Content module, so each deployment must be individually cleared using the steps below. 🛠️ How to Fix Custom HTML Content Module Glitches In Search Atlas, go to OTTO → Miscellaneous → Custom HTML Content, then follow these steps in order: 1. Click the first deployment in the module menu. 2. Delete all text inside that deployment. 3. Click Edit & Deploy to save the now-empty deployment. 4. Repeat steps 1–3 for every remaining deployment in the list. 5. Clear your site cache through your hosting provider or caching plugin. Reload your site after the cache clears. Your headings, banners, and layout should return to normal. Note: If you are on a White Label plan and custom HTML added via Report Builder disappears automatically, this is a separate known issue currently being resolved — contact support. 💡 How to Prevent Custom HTML Content Glitches on Future Projects Apply these two guidelines when onboarding new clients to avoid repeating this issue: - Validate HTML before deploying. Every entry in the Custom HTML Content module must use well-formed, properly nested HTML. Run your code through an HTML validator before clicking Edit & Deploy. - Leave the module empty if you don't need it. If a client's project does not require custom HTML injections, do not add deployments to the Custom HTML Content module. Unused deployments with malformed markup are the most common trigger for these glitches. 🎯 You now know how to clear malformed HTML deployments from the Custom HTML Content module and prevent site glitches from affecting future client projects. For a broader overview of what OTTO deploys and manages on your site, see the OTTO Activation overview article.

🛠️ Fix Shopify Pixel Errors After Account Reset

🔍 Overview After resetting your Search Atlas account and reconnecting your Shopify store, you may encounter two common issues: a pixel installation error and a site audit crawler that isn't running. These issues are related — the reconnection process requires a few deliberate steps to re-establish the tracking pixel and trigger a fresh crawl. This article walks you through the full resolution process. ⚠️ Why This Happens When you reset your account or disconnect and reconnect your Shopify store, Search Atlas loses its previous link to your site's pixel and audit configuration. The platform treats your store as a new connection and requires you to reinstall the pixel manually and initialise the site audit from scratch. Simply reconnecting the integration is not enough to restore these automatically. ✅ Step 1 — Verify Your Shopify Store Is Connected 1. In the left sidebar, click Site Metrics (Site Explorer). 2. Confirm your Shopify store domain appears in the site list at /site-explorer/list. 3. If your store is missing, use the Add New Site option to reconnect it before continuing. 🔧 Step 2 — Reinstall the Search Atlas Pixel on Shopify The pixel must be reinstalled manually after any account reset. Follow these steps inside your Shopify admin: 1. Log in to your Shopify Admin and go to Online Store → Themes. 2. Click Actions → Edit Code on your active theme. 3. Open the theme.liquid file. 4. Remove any previously installed Search Atlas pixel snippet to avoid duplicate code conflicts. 5. Return to Search Atlas and navigate to Site Metrics (Site Explorer). Locate your site and open its settings to retrieve your unique pixel snippet. 6. Paste the pixel snippet just before the closing </head> tag in theme.liquid. 7. Click Save in Shopify. Once saved, return to Search Atlas and use the Verify Pixel option (if available on your site settings screen) to confirm the pixel is detected correctly. 🚀 Step 3 — Initialise the Site Audit Crawler After the pixel is confirmed, you need to manually start the site audit so the crawler begins indexing your store. 1. In the left sidebar, click OTTO SEO → Site Audit (Site Audit). 2. Select your Shopify store from the site selector at the top of the page. 3. Look for the Audit Site button and click it. 4. The crawler will begin running. Depending on the size of your store, the initial audit may take several minutes to complete. You can also monitor crawl status and site health data by returning to Site Metrics (Site Explorer) in the left sidebar once the crawl has started. 💡 Tips to Avoid This Issue in Future - Before resetting your account, note your pixel snippet and audit settings so you can restore them quickly. - Always verify the pixel immediately after any reconnection — do not assume it carries over automatically. - If you manage multiple Shopify stores, reinstall and verify the pixel for each domain separately. - Clear your Shopify theme's cached files after saving the pixel to ensure the latest version is live. 🛑 Still Seeing a Pixel Error? If the pixel verification continues to fail after following all steps above, check the following before contacting support: - Confirm there are no duplicate pixel snippets in your theme.liquid file. - Make sure your Shopify theme is published and active — pixel changes to an unpublished theme will not take effect. - Disable any third-party script blockers or Content Security Policy (CSP) headers that may be preventing the pixel from loading. If you need further assistance, open 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 Topical Map URL Validation Errors

🔍 Overview When creating a topical map, you may see the URL field greyed out with the message Provide valid url like https://example.com even though your URL looks correct. This is almost always caused by a browser cache or session issue — not a problem with your URL itself. This article walks you through how to fix it quickly. 🧭 How to Navigate to Topical Maps 1. Log in to Search Atlas. 2. In the left sidebar, click Content. 3. Select Topical Maps from the sub-menu. 4. Click Create Topical Map to open the creation form. ⚠️ What This Error Looks Like - The URL input field appears greyed out or is not accepting input. - A message reads: Provide valid url like https://example.com. - The error persists even when you type or paste a correctly formatted URL such as https://yoursite.com. - The Create or Generate button remains inactive. 🛠️ Step 1 — Test in an Incognito or Private Window The fastest way to determine whether your browser session is causing the issue is to open an incognito or private window. 1. Open a new incognito window: - Chrome / Edge: Press Ctrl + Shift + N (Windows) or Cmd + Shift + N (Mac). - Firefox: Press Ctrl + Shift + P (Windows) or Cmd + Shift + P (Mac). - Safari: Go to File → New Private Window. 2. Navigate to Search Atlas and log in. 3. Go to Content → Topical Maps and try creating a topical map again. 4. If the URL field works correctly in incognito mode, your regular browser session has cached data that is interfering. Continue to Step 2. 🧹 Step 2 — Clear Your Browser Cache and Cookies Cached files and stored cookies can cause form fields to behave unexpectedly. Clearing them resolves the issue in most cases. 1. Open your browser settings: - Chrome: Press Ctrl + Shift + Delete (Windows) or Cmd + Shift + Delete (Mac). - Firefox: Press Ctrl + Shift + Delete (Windows) or Cmd + Shift + Delete (Mac). - Edge: Press Ctrl + Shift + Delete. - Safari: Go to Safari → Settings → Privacy → Manage Website Data. 2. Set the time range to All time. 3. Select at least Cached images and files and Cookies and other site data. 4. Click Clear data (or the equivalent button in your browser). 5. Close and reopen the browser completely. 6. Log back in to Search Atlas and return to Content → Topical Maps. 7. Attempt to create a new topical map and enter your URL. 🔄 Step 3 — Additional Browser Checks If clearing the cache does not resolve the issue, try the following: - Disable browser extensions: Some ad blockers or form-autofill extensions interfere with input fields. Disable all extensions temporarily and reload the page. - Try a different browser: If you are using Chrome, try Firefox or Edge (or vice versa) to rule out a browser-specific conflict. - Perform a hard refresh: Press Ctrl + Shift + R (Windows) or Cmd + Shift + R (Mac) to force the page to reload without using cached files. - Check your URL format: Make sure your URL includes the protocol and has no trailing spaces. Use the format https://yoursite.com — no extra characters or slashes at the end. 📄 OTTO Showing Results for Only One Page If OTTO is displaying data for only one page even though your site has multiple pages, this is typically a crawl scope issue. OTTO's results depend on the crawl settings configured for your site. 1. In the left sidebar, go to OTTO SEO → All Sites (SEO Automation) (URL: /seo-automation-v3). 2. Select your website project. 3. Open the crawl or site settings for your connected domain. 4. Confirm that the crawl scope is set to cover the full site, not just the root URL or a single page. 5. Re-run the crawl after updating the settings. 6. Wait for the crawl to complete — large sites may take several minutes — then check whether OTTO now surfaces results across multiple pages. If the crawl settings appear correct but OTTO still shows only one page, the domain may not be fully verified or connected. Verify that your domain is properly linked under the project settings before re-running the crawl. ✅ Summary of Fixes - URL field greyed out → test in incognito mode first, then clear cache and cookies. - Validation error persists → disable extensions or switch browsers. - OTTO showing one page only → check crawl scope settings and re-run the crawl. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔒 Fix Brand Vault Loading Issues via DNS Whitelisting

🧭 Overview If your Brand Vault setup is stuck on a loading wheel — even after a hard reset or re-login — the most common cause is that your DNS provider is blocking Search Atlas crawlers from verifying your domain. Whitelisting these crawlers in your DNS settings resolves the issue in most cases. This article covers whitelisting steps for GoDaddy and other common DNS providers. ⚠️ Before You Begin - Confirm you have admin access to your DNS provider account. - Have your domain name ready. - Search Atlas crawler IPs to whitelist: 52.204.108.93, 34.193.240.22, 54.197.105.6. If you are unsure which IPs apply to your account, open the chat widget for confirmation before proceeding. 🌐 Whitelist Crawlers on GoDaddy 1. Log in to your GoDaddy account and navigate to My Products. 2. Find your domain and click DNS to open the DNS Management panel. 3. Scroll down to the Firewall or Access Control section. If you have GoDaddy Website Security or Sucuri Firewall enabled, click Manage next to it. 4. Select Allowlist (sometimes labelled Whitelist IPs) from the left-hand menu. 5. Click Add IP and enter each Search Atlas crawler IP address one at a time. 6. Set the access type to Allow and save each entry. 7. Return to Search Atlas, open Brand Vault, and click Retry Setup. The loading wheel should resolve within 1–3 minutes. 🔵 Whitelist Crawlers on Cloudflare 1. Log in to Cloudflare and select your domain. 2. Go to Security > WAF > Tools. 3. Under IP Access Rules, enter each Search Atlas crawler IP, set the action to Allow, and choose This Website as the scope. 4. Click Add for each IP, then retry Brand Vault setup. 🟠 Whitelist Crawlers on Namecheap 1. Log in to Namecheap and go to Domain List. 2. Click Manage next to your domain, then select Advanced DNS. 3. If you have Namecheap's Premium DNS or a third-party firewall enabled, access its dashboard and locate the IP Allowlist or Whitelist section. 4. Add each Search Atlas crawler IP with Allow permissions and save. 5. Retry Brand Vault setup in Search Atlas. 🟣 Whitelist Crawlers on Other DNS Providers The steps vary slightly by provider, but the general process is the same for any DNS or WAF platform: 1. Log in to your DNS or firewall dashboard. 2. Locate the IP Allowlist, Whitelist, or Access Rules section. 3. Add each Search Atlas crawler IP and set the permission to Allow. 4. Save your changes and retry Brand Vault setup. Common providers where this setting is found include AWS Route 53 (use Security Groups or WAF IP sets), Google Domains / Squarespace DNS (manage via connected firewall or CDN), and SiteGround (use the IP Manager under Security tools). ✅ Confirm the Fix - After whitelisting, return to Brand Vault in Search Atlas. - Click Retry Setup or refresh the page. - The loading wheel should disappear and your brand profile should begin populating within 1–3 minutes. - If the wheel persists beyond 5 minutes, perform a hard reset: log out, clear your browser cache, log back in, and navigate back to Brand Vault. 🛠️ Still Seeing the Loading Wheel? If whitelisting the crawler IPs did not resolve the issue, consider these additional checks: - Proxy or VPN: Disable any active VPN or proxy on your device and retry. - Browser extensions: Ad blockers or privacy extensions can interfere. Try an incognito window with extensions disabled. - Multiple DNS layers: Some domains route through both a registrar and a separate CDN or WAF. Ensure crawlers are whitelisted at every active layer. - DNS propagation: Changes can take up to 24 hours to propagate fully, though most updates apply within minutes. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 Fix Site Audit Sitemap Detection Discrepancies

🗺️ Why This Discrepancy Happens When Site Audit reports that a page is missing from your XML sitemap, but you can see the page listed in your live sitemap, the most common cause is a data freshness issue. Site Audit captures a snapshot of your site at the time the crawl runs. If your sitemap was updated after the crawl began — or after the last completed crawl — the audit results will not reflect those changes until the next crawl is processed. Other frequent causes include: - Sitemap caching: Your server or CDN may serve a cached version of the sitemap to crawlers. The cached copy Site Audit fetched may have been outdated at crawl time, even if your live sitemap is now correct. - Multiple sitemap files: If your site uses a sitemap index file pointing to several child sitemaps, Site Audit may have successfully fetched some child sitemaps but not others due to a temporary fetch error or timeout. - Conditional serving: Some sitemap plugins or CMS configurations serve different sitemap content based on the requesting user-agent or IP address. The crawler may receive a different response than a browser does. - Redirect chains on the sitemap URL: If the sitemap URL itself redirects before returning XML content, the crawler may not follow all redirect hops, resulting in an incomplete or empty sitemap read. - Recently added pages: Pages added to your sitemap shortly before or during an active crawl may fall outside the crawl window and only appear in the next scheduled audit. 🛠️ How to Troubleshoot the Discrepancy 1. Re-run the Site Audit crawl. Navigate to your Site Audit dashboard and trigger a fresh crawl. Once the crawl completes, check whether the page is still flagged as missing. This is the quickest way to rule out a stale-data issue. 2. Verify the sitemap URL used by Site Audit. Open your Site Audit project settings and confirm the sitemap URL entered matches your actual live sitemap URL exactly, including the protocol (https://) and any subdirectory path. A mismatch here means the tool is checking a different file than the one you are viewing in your browser. 3. Fetch the sitemap URL directly. Paste your sitemap URL into a browser or a tool like Google Search Console's Sitemap report. Confirm the page in question is listed and that the sitemap returns a valid HTTP 200 status with correct XML markup. 4. Check for sitemap caching. Add a cache-busting query string (e.g., ?nocache=1) to your sitemap URL in a browser to see if you get a fresher version with more entries. If the cached and uncached versions differ, work with your hosting provider or CDN to reduce the sitemap cache TTL. 5. Inspect child sitemaps in a sitemap index. If you use a sitemap index, open each child sitemap URL individually and confirm the page appears in the correct child file. If a child sitemap returns an error or is empty, that file needs to be fixed at the CMS or plugin level. 6. Review the page's canonical tag and index status. Occasionally, Site Audit flags a page as missing from the sitemap because the page itself contains a noindex directive or a canonical tag pointing to a different URL. Site Audit may exclude noindexed URLs from sitemap coverage checks by design. Confirm the page is indexable before expecting it to appear as covered. 7. Check for redirect chains on the page URL. If the URL listed in your sitemap redirects to another URL, Site Audit may record the final destination URL as the canonical version. Compare the URL in your sitemap against the URL Site Audit tracked after following redirects. 📋 Best Practices to Prevent Future Discrepancies - Keep your sitemap URL stable and ensure it returns a 200 OK status at all times. - Avoid making large sitemap changes while a crawl is actively running. - Set your CDN or server cache TTL for sitemap files to 1 hour or less so crawlers always receive a near-current version. - Use a single, authoritative sitemap index file rather than submitting multiple disconnected sitemap URLs. - After publishing new pages, allow at least one full audit cycle before expecting them to appear as covered in Site Audit reports. 💡 Understanding the Audit Timestamp Every Site Audit report displays a last crawled timestamp at the top of the dashboard. Always compare this timestamp against the date you last updated your sitemap. If your sitemap was modified after the crawl timestamp, the current report cannot reflect those changes. Re-running the crawl will bring the report up to date. 🙋 Still Seeing the Discrepancy? If you have re-run the crawl and verified all the steps above but the page is still showing as missing, there may be a crawl configuration or account-level issue that requires investigation. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team. Additional Notes Step 2: Clear Your Browser Cache and Reload — A cached version of the Site Audit dashboard can display outdated results even after a new crawl has completed. Clear cached images/files and cookies (Ctrl+Shift+Delete / Cmd+Shift+Delete), set time range to All time, then reopen browser and log back in.

🔍 Why You're Getting an 'Unable to Activate Indexing' Error in Google Search Console

🧭 Overview When connecting Search Atlas to your Google Search Console (GSC) account, you may encounter an 'Unable to activate indexing' error. This error is not caused by a bug in Search Atlas — it originates from a hard limit enforced by Google Search Console itself. This article explains what that limit is, why it triggers the error, and what steps you can take to resolve it. ⚠️ What Causes This Error? Google Search Console enforces a quota on the number of verified service accounts and users that can be added to a single property. When that quota is reached, Google blocks any new service account from being activated — including the one Search Atlas uses to access your indexing data. Common reasons this quota gets hit include: - Multiple SEO tools or agencies have been connected to your GSC property over time and were never removed. - Previous team members or contractors were added as users and their access was never revoked. - Test integrations or deprecated service accounts are still occupying quota slots. - Your organization manages a large number of users across the same GSC property. 🔎 How to Check Your Current GSC Users and Service Accounts 1. Go to Google Search Console at search.google.com/search-console and select the affected property. 2. In the left sidebar, click Settings. 3. Under the Users and permissions section, review the full list of users and service accounts currently associated with the property. 4. Look for any accounts that are no longer in use — including old agency accounts, previous team members, or third-party tool integrations you no longer use. ✅ How to Fix the 'Unable to Activate Indexing' Error 1. Identify and remove unused accounts: In the GSC Users and permissions panel, click the three-dot menu next to any account you no longer need and select Remove access. Focus on removing old service accounts from tools or agencies you are no longer working with. 2. Remove inactive user accounts: If former employees or contractors are listed, remove their access as well. Each removal frees up a slot in your quota. 3. Retry the Search Atlas integration: Once you have freed up sufficient quota space, return to Search Atlas and attempt to activate indexing again. Navigate to Left sidebar → Site Explorer, locate your project, and re-initiate the GSC connection from the Overview sub-page under AI Settings or the integration prompt displayed on your property. 4. Confirm the service account was added successfully: After reactivating, go back to GSC Settings → Users and permissions to verify that the Search Atlas service account now appears as a confirmed user with the appropriate access level. 🛡️ Best Practices to Avoid This Issue in the Future - Regularly audit your GSC users and permissions — at least once per quarter — to remove stale accounts before the quota fills up. - When ending a relationship with an SEO tool or agency, always revoke their GSC access as part of your offboarding process. - Keep a documented record of which tools and team members have been granted GSC access so you can identify and remove unused accounts quickly. - If you manage multiple client properties, apply the same audit practice to each property individually, as the quota applies per property. ❓ Frequently Asked Questions - Does Search Atlas cause this quota limit? No. The quota is set and enforced entirely by Google. Search Atlas requests access through a standard service account, just like any other GSC integration. - How many users can be added to a GSC property? Google does not publicly document the exact quota number, but it is known to be limited. The error appears when the maximum is reached. - Will removing old accounts affect my historical GSC data? No. Removing a user or service account does not delete or affect your historical Search Console data. It only removes their access going forward. - What access level does Search Atlas need? Search Atlas requires Owner permission on your GSC property in order to activate indexing features correctly; Full user permission is not sufficient. 🙋 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.

🔍 Onpage Audit Fails With HTTP 200 Error

🧭 Overview When the Onpage Audit tool returns Auditing URL failed - Status Code: 200, the page itself is loading successfully — the server is responding normally. The failure happens after the page is fetched, during the parsing and analysis stage. This means the cause is unrelated to firewalls or access blocks and requires a different set of troubleshooting steps. Work through the sections below in order to identify and resolve the issue. ⚙️ 1. Check for Content Encoding Problems Encoding mismatches are one of the most common causes of this error. The audit engine expects clean, readable HTML, and certain encoding configurations can corrupt the response before it can be parsed. - Gzip or Brotli compression: If the server sends a compressed response without a correct Content-Encoding header, the tool receives unreadable content. Verify your server is correctly declaring its compression method. - Non-UTF-8 character sets: Pages encoded in legacy formats (e.g. ISO-8859-1, Windows-1252) without a declared charset can cause parsing failures. Set your page's charset to UTF-8 and declare it in both the HTTP header and a <meta charset> tag. - Conflicting charset declarations: If the HTTP header and the meta tag declare different charsets, the parser may fail. Make sure both declarations match. 🤖 2. Check for JavaScript-Rendered Content The Onpage Audit tool analyses the HTML delivered by the server. If your page relies heavily on JavaScript to render its main content, the audit may receive a largely empty HTML document with little parseable structure. - Use your browser's View Page Source (not DevTools) to see the raw HTML the server delivers. If the source is mostly empty script tags, your page is JavaScript-rendered. - For critical pages, consider implementing server-side rendering (SSR) or static generation so the full HTML is available without executing JavaScript. - Alternatively, ensure a meaningful HTML fallback is present in the raw source for the auditor to parse. 🚫 3. Check robots.txt and Meta Robots Directives Even when a page loads with a 200 status, crawl directives can prevent the audit tool from processing its content. 1. Visit yourdomain.com/robots.txt and check whether any Disallow rules apply to the URL you are auditing. 2. View the page source and search for a <meta name="robots"> tag. Values such as noindex, nofollow, or none can interrupt the audit process. 3. Check for an X-Robots-Tag HTTP response header, which applies the same directives at the server level and is often overlooked. If any of these directives are blocking the auditor, update them to permit crawling, then retry the audit. 🛠️ 4. Check for Malformed HTML or JavaScript Errors Broken page structure can cause the parser to fail even when the browser renders the page visually without problems. Browsers are forgiving of HTML errors; the audit engine is not. - Run the URL through the W3C Markup Validation Service (validator.w3.org) to identify unclosed tags, duplicate IDs, or other structural errors. - Open your browser's DevTools Console tab and reload the page. Any red JavaScript errors should be investigated and resolved, as they can halt scripts that build page structure. - Pay particular attention to broken <head> sections — errors here prevent the parser from reading metadata correctly. 🔗 5. Check for Redirect Chains A URL that passes through multiple redirects before reaching a 200 response can cause the audit to fail if the chain is too long or contains inconsistencies. 1. Use a tool such as httpstatus.io to trace the full redirect path of your URL. 2. If the chain has more than two hops, simplify it by updating links to point directly to the final destination URL. 3. Check for mixed-protocol redirects (HTTP → HTTPS → HTTP) or redirect loops, as these will always cause audit failures. 4. Re-run the audit using the final destination URL rather than the original redirecting URL. ⏱️ 6. Check for Rate Limiting by the Origin Server Unlike firewall blocking (which typically returns a 403 or 429 status), some origin servers silently throttle automated requests by returning degraded or incomplete responses with a 200 status. This can cause the audit to receive too little content to process. - Check your server or CDN access logs for the time of the failed audit. Look for entries from automated user agents that received a 200 response but with an unusually small response body size. - If your site uses a CDN (e.g. Cloudflare, Fastly), review bot management or rate-limiting rules that may be serving a challenge page or stripped response disguised as a 200. - Temporarily test the audit on a staging or development environment with rate limiting disabled to confirm whether this is the cause. - If rate limiting is confirmed, whitelist the Search Atlas crawler user agent in your server or CDN configuration. ✅ Quick-Reference Checklist - Content-Encoding header matches actual compression used - Page charset is UTF-8 and declared consistently - Raw HTML source contains meaningful, parseable content - robots.txt, meta robots, and X-Robots-Tag permit crawling - No critical HTML validation errors in the page structure - Redirect chain has two or fewer hops and no mixed-protocol steps - Origin server is not silently rate-limiting automated requests 💬 Still Need Help? If you have worked through all the steps above and the audit is still failing, our team can investigate the specific URL 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 Site Audit Not Crawling All WordPress Pages

🧩 Why This Happens Site Audit relies on being able to discover and access every page on your site. When pages are missing from the crawl, it usually means one or more common barriers are preventing the crawler from reaching them. This is especially common on WordPress sites due to plugin configurations, crawl limits, or technical settings that block or restrict access. ✅ Step 1: Check Your Crawl Settings Before investigating deeper, confirm your project is configured correctly inside Search Atlas. 1. Navigate to OTTO SEO → Site Audit from the left sidebar. 2. Select your site and open Settings or Edit Project. 3. Verify the Start URL is set to your root domain (e.g., https://yourdomain.com) and not a subfolder or inner page. 4. Check the crawl limit. If your site has hundreds or thousands of pages, make sure the limit is set high enough to cover all of them. 5. Ensure crawl subdomains is enabled if you have content hosted on subdomains. 🚫 Step 2: Review Your robots.txt File A misconfigured robots.txt file is one of the most common reasons pages are skipped during a crawl. If your robots.txt is blocking the Search Atlas crawler — or all crawlers — entire sections of your site will be invisible to Site Audit. 1. Open a browser and go to https://yourdomain.com/robots.txt. 2. Look for any Disallow rules that block User-agent: * or specific paths. 3. If important pages or directories are disallowed, update your robots.txt to allow access to them. 4. After updating, return to Site Audit and re-run the crawl. 🔌 Step 3: Disable or Configure WordPress Plugins Several WordPress plugins can interfere with crawling without you realising it. The most frequent offenders include: - Security plugins (e.g., Wordfence, iThemes Security) — these can block crawlers that resemble bots. Whitelist the Search Atlas crawler IP or temporarily disable bot blocking rules to test. - Caching plugins (e.g., WP Rocket, W3 Total Cache) — some caching rules can cause redirect loops or serve incomplete pages to crawlers. - Coming Soon / Maintenance mode plugins — if your site or any section is in maintenance mode, those pages will not be crawled. - Membership or login-required plugins — pages behind a login wall cannot be crawled unless you configure authenticated crawling. Test by temporarily deactivating suspected plugins, then re-running the Site Audit crawl to see if more pages are discovered. 🗺️ Step 4: Verify Your XML Sitemap Site Audit can use your XML sitemap as a reference to find pages. If your sitemap is missing pages, outdated, or broken, the crawl may not discover all content. 1. Go to https://yourdomain.com/sitemap.xml (or your custom sitemap URL). 2. Confirm all important pages are listed. 3. If you use a WordPress SEO plugin like Yoast SEO or Rank Math, check the sitemap settings to ensure all post types and taxonomies are included. 4. Regenerate the sitemap if needed, then re-submit it in Site Audit settings. 🔗 Step 5: Fix Internal Linking Gaps The Site Audit crawler discovers pages by following links. If some pages have no internal links pointing to them (orphan pages), the crawler cannot find them through link traversal alone. - Add internal links from other pages to any orphaned content. - Ensure your navigation menus, category pages, and footer links cover all key areas of your site. - Use your XML sitemap alongside crawling to maximise page discovery. 🔄 Step 6: Re-Run the Crawl After making any of the changes above, always trigger a fresh crawl so Site Audit can process the updated site. 1. Go to OTTO SEO → Site Audit → Overview (Website Overview) in the left sidebar. 2. Select your project and click Recrawl Site. 3. Wait for the crawl to complete, then review the Page Explorer report to confirm all expected pages are now listed. 4. Check the Issues report to view and action any errors that were previously missed. 💬 Still Need Help? If you have followed all the steps above and Site Audit is still not crawling all pages on your WordPress site, If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Fix WordPress Schema Errors and Plugin Conflicts

🔍 Understanding the Problem After activating OTTO SEO, some customers notice new ImageObject metadata validation errors appearing in Google Search Console (GSC). At the same time, others wonder whether installing a third-party schema plugin alongside OTTO will cause conflicts. This article explains both issues and how to resolve them quickly. ⚙️ Why ImageObject Errors Appear After Switching to OTTO When you activate OTTO SEO, it takes over schema markup generation for your entire site. If a previous plugin or theme was outputting incomplete or differently structured ImageObject schema, GSC may flag the transition as new errors — even if OTTO's output is technically correct. Common reasons these errors appear include: - Images on your pages are missing alt text, which is required for valid ImageObject schema. - Featured images are not set on posts or pages, leaving the contentUrl or url property empty. - Your theme outputs its own image schema that conflicts with OTTO's output, producing duplicate or malformed markup. - GSC is still processing a cached version of your previous schema and will resolve automatically within a few days. 🖼️ How to Fix ImageObject Validation Errors 1. Add alt text to all images. In the WordPress Media Library, open each flagged image and fill in the Alt Text field. For bulk updates, use the Media Library grid view to edit images quickly. 2. Set featured images on all posts and pages. Go to each post or page in the WordPress editor, open the Featured Image panel, and assign a relevant image. 3. Check for theme-generated schema. Some themes (such as Astra or GeneratePress) include built-in schema output. Open your theme settings and disable any structured data or schema markup options to prevent duplication. 4. Re-validate in GSC. After making changes, open Google Search Console → Enhancements → Schema errors, select the affected URLs, and click Validate Fix. GSC typically re-crawls within a few days. 5. Use the Rich Results Test. Paste any affected URL into Google's Rich Results Test tool to confirm your schema is clean before requesting validation. 🔌 Will Installing a Schema Plugin Conflict with OTTO? Yes — in most cases, running a dedicated schema plugin alongside OTTO SEO will cause conflicts. OTTO SEO generates its own comprehensive structured data for your site, including Organization, WebPage, Article, BreadcrumbList, and ImageObject schema. Adding a second plugin that outputs the same schema types produces duplicate markup, which can confuse search engines and trigger additional GSC errors. Plugins known to conflict with OTTO's schema output include: - Yoast SEO (when schema is enabled) - Rank Math (when schema module is active) - Schema Pro - Schema & Structured Data for WP & AMP - All in One SEO (AIOSEO) with schema features enabled ✅ Recommended Setup for Schema in WordPress Follow these best practices to keep your schema clean and conflict-free: - Use OTTO SEO as your single schema source. Do not install additional schema plugins. OTTO deploys schema per page/URL after you approve or publish the recommendation (or automatically if OTTO auto-deploy is enabled). - Disable schema output in your theme. If your theme has structured data settings, turn them off. - Disable schema in any remaining SEO plugins. If you use another SEO plugin for features OTTO does not yet cover (such as a sitemap from a legacy setup), navigate to that plugin's settings and disable only its schema or structured data module — you do not need to uninstall the entire plugin. - Audit your schema regularly. After any plugin update or theme change, re-run a spot-check in the Rich Results Test to catch new conflicts early. ⏱️ How Long Until GSC Errors Clear? Once you have fixed the underlying issues, GSC errors do not disappear instantly. Expect the following timeline: - 1–3 days for Googlebot to re-crawl your most frequently visited pages. - Up to 2 weeks for validation to complete across all flagged URLs. - Clicking Validate Fix in GSC speeds up the process by prompting Google to prioritise re-crawling those URLs. If errors persist beyond two weeks after your fixes, re-check the affected pages using the Rich Results Test to confirm there is no remaining conflicting output. 💬 Need More Help? If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 Fix 'Unable to Activate Indexing' Error in GSC

🧭 Overview When you add Search Atlas as a service account in Google Search Console (GSC), you may see an "Unable to activate indexing" error. This is not a bug in Search Atlas. It is caused by a Google-side quota limitation on their Indexing API. This article explains what the error means, why it happens, and what steps to take. ⚠️ What This Error Means Google limits the number of websites that can use their Indexing API at any given time. When their quota is full, no new service accounts — including Search Atlas — can be activated for indexing, regardless of how the setup is performed. The error message "Unable to activate indexing" is Google's way of communicating that their system is not accepting new indexing activations at that moment. This is a known, recurring limitation on Google's infrastructure and is outside the control of Search Atlas. ✅ How to Confirm the Setup Is Correct Before waiting for the quota to reopen, confirm that you have completed the Search Atlas service account setup correctly in Google Search Console: 1. Go to Google Search Console and select your property. 2. Navigate to Settings → Users and permissions. 3. Click Add user and enter the Search Atlas service account email address provided in the platform. 4. Set the permission level to Owner. 5. Click Save. If these steps are complete and the error still appears, the issue is the Google quota limitation described above — not a configuration problem on your end. ⏳ What to Do Next Because this limitation is controlled entirely by Google, the only action required is to wait. Here is what to expect: - Google periodically opens quota availability, but there is no fixed schedule or public timeline. - You do not need to remove and re-add the service account. Leave the Search Atlas service account in place as an Owner in GSC. - Once Google opens quota availability, the indexing activation will complete automatically without any further action needed from you. - You will be able to use all other Search Atlas features normally while you wait. 🔄 How to Check if Indexing Has Activated After some time has passed, you can verify whether Google has opened quota and activated indexing for your property: 1. Log in to Search Atlas. 2. In the left sidebar, navigate to Site Metrics. 3. Check whether indexing data has begun populating for your site. 4. Alternatively, return to Google Search Console under Settings → Users and permissions and confirm the Search Atlas service account is still listed as Owner. If the account is still showing as Owner in GSC but indexing has not activated after several days, follow the troubleshooting steps in the next section. 🛠️ Troubleshooting Steps If the Issue Persists If indexing has not activated after a reasonable waiting period, try the following: - Re-check permissions: Confirm the Search Atlas service account is set to Owner, not just Viewer or Full User. Indexing API access requires Owner-level permission. - Verify the correct property: Make sure you added the service account to the correct GSC property (the exact domain or URL prefix that matches your site). - Remove and re-add the service account: If the permission looks correct but indexing still fails, remove the service account from GSC, then re-add it using the service account email from the Search Atlas platform and set it to Owner again. - Check for GSC property verification: Your property must be fully verified in Google Search Console before indexing integration can work. ❓ Frequently Asked Questions Is this a Search Atlas bug? No. The error originates from Google's Indexing API quota system. Search Atlas has no ability to override or bypass Google's quota limits. Will I lose any data while waiting? No. Your existing Search Atlas data and all other features remain fully accessible. Only the GSC indexing activation is pending. Do I need to contact Google to request quota access? Generally, no. Google manages quota allocation automatically. There is no public form or support channel to request priority access. How long does it typically take? There is no guaranteed timeframe. Some users see activation within a few days; for others it may take longer depending on Google's quota availability at the time. 💬 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 Crawler Installation and Whitelisting Issues

🔍 Overview After installing OTTO SEO, some customers notice that the crawler only indexes a single page — typically the homepage — instead of crawling the entire website. This usually happens because a security plugin, firewall, or server-level rule is blocking the Search Atlas crawler bot after its first request. This article walks you through how to identify the cause and whitelist the crawler correctly so OTTO can index your full site. ⚙️ How the OTTO Crawler Works When OTTO is activated for your website, the Search Atlas crawler visits your pages to gather SEO data and apply optimizations. If anything on your server interprets repeated bot requests as suspicious activity, it may block the crawler after the first visit — leaving OTTO with only partial data to work with. Common causes of this issue include: - Security plugins (e.g., Wordfence, Sucuri, iThemes Security) blocking unrecognized bots - Cloudflare or CDN firewall rules that rate-limit or challenge bot traffic - Hosting-level bot protection that restricts crawlers automatically - robots.txt rules that unintentionally disallow the Search Atlas crawler 🛠️ Step 1 — Whitelist the Search Atlas Crawler User-Agent The Search Atlas crawler identifies itself with the following user-agent string: SearchAtlas/1.0 You need to add this user-agent to the allowlist in any tool that filters bot traffic on your site. Follow the steps below based on your setup. 🔒 Step 2 — Whitelist in Your Security Plugin If you are using a WordPress security plugin, here is how to allow the crawler: 1. Log in to your WordPress dashboard. 2. Navigate to your security plugin settings (e.g., Wordfence → Firewall → Allowlisted IPs or Bots). 3. Locate the option to whitelist a bot or user-agent. 4. Add SearchAtlas/1.0 as a trusted user-agent. 5. Save your changes. If your plugin does not support user-agent whitelisting, check whether it allows you to whitelist by IP address. Contact our support team via the chat widget (see below) to request the current list of Search Atlas crawler IP addresses. ☁️ Step 3 — Whitelist in Cloudflare or Your CDN If your site uses Cloudflare or another CDN with bot management, follow these steps: 1. Log in to your Cloudflare dashboard and select your domain. 2. Go to Security → WAF → Custom Rules (or Firewall Rules, depending on your plan). 3. Create a new rule that allows traffic where the user-agent contains SearchAtlas. 4. Set the action to Allow and save the rule. 5. If you use Cloudflare Bot Management or Super Bot Fight Mode, ensure verified bots or the Search Atlas user-agent are not being challenged or blocked. 📄 Step 4 — Check Your robots.txt File Your robots.txt file may be blocking the Search Atlas crawler. To check: 1. Open a browser and go to yourdomain.com/robots.txt. 2. Look for any Disallow rules under a wildcard agent (User-agent: *) that might block large portions of your site. 3. If needed, add a specific entry to explicitly allow the Search Atlas crawler: User-agent: SearchAtlas/1.0 Allow: / Add these lines above any wildcard disallow rules so they take priority. Save and re-upload the file to your server root if you edit it manually. 🚀 Step 5 — Re-Trigger the OTTO Crawl Once you have completed whitelisting, you need to prompt OTTO to re-crawl your site: 1. In Search Atlas, go to OTTO SEO in the left sidebar, then open SEO Automation. 2. Select the website where OTTO is installed. 3. Locate the crawl or re-crawl option and initiate a new crawl. 4. Wait for the crawl to complete — this may take a few minutes depending on your site size. 5. Review the crawled pages count to confirm all pages are now being discovered. ✅ Confirm the Issue Is Resolved After the re-crawl, check the following to confirm everything is working: - The total pages crawled matches the expected number of pages on your site. - OTTO is surfacing SEO recommendations across multiple pages, not just the homepage. - No new error messages appear in the OTTO dashboard related to crawl access. If the crawled page count is still lower than expected, double-check that all layers of protection on your site — including hosting-level firewalls and CDN rules — have been updated. 💬 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 Site Explorer Quota Error After Downgrade

🔍 What Is This Error? When you try to add a site in Site Explorer (found at Left sidebar → Site Metrics), you may see a message like: - "You have hit the limit by adding 0 projects. Please upgrade your plan to create more." This error can appear even when you believe you have available project slots. It is a known quota synchronisation issue that can occur after a plan downgrade or, in some cases, after plan changes of any kind. The good news: your data is safe and this is fixable. ⚙️ Why Does This Happen? When your account moves to a lower-tier plan, the system sometimes fails to correctly reassign your Site Explorer project quota. As a result, your quota counter displays 0 available slots even though your current plan should allow more. This is a backend synchronisation issue — it does not reflect your actual entitlement under your plan. ✅ Steps to Resolve the Error 1. Confirm your current plan. Go to your account billing or subscription settings and verify which plan is active. Make note of how many Site Explorer projects your plan is supposed to include. 2. Check your existing saved projects. Navigate to Left sidebar → Site Metrics and review any projects already listed. If the count shown is lower than your plan limit, the quota is out of sync. 3. Refresh your session. Log out of Search Atlas completely, then log back in. Occasionally a fresh session triggers a quota re-check. 4. Wait a short time and retry. Quota updates can take a few minutes to propagate after a plan change. Wait 5–10 minutes, then try adding your site again. 5. Contact support if the error persists. If you have completed the steps above and still see the zero-quota error, this requires a manual quota correction on our end. See the section below for how to reach us. 📋 Information to Have Ready for Support To help our team resolve your issue as quickly as possible, please have the following details available before opening a chat: - Your account email address - The plan name you are currently on (e.g. Starter, Pro, Agency) - The date your plan was changed or downgraded - A screenshot of the error message, if possible - The number of Site Explorer projects currently showing in your account 🚫 What Not to Do - Do not upgrade your plan solely to bypass this error — the issue is a quota sync problem, not a genuine plan limitation. - Do not delete existing projects hoping to free up space. Because the quota counter is already showing 0, removing projects will not resolve the underlying sync issue. 💡 Additional Notes This issue has been identified and resolved in our engineering systems for most affected account types. However, accounts that were downgraded during a specific window may still experience the incorrect quota display until a manual correction is applied. Our support team can apply this fix in minutes once they locate your account. 🙋 Still Need Help? If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

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

🔍 Fix a Failing On-Page Audit Fast

🧭 Overview When an On-Page Audit shows a Failed status with no additional detail, it usually means the audit could not complete one or more critical checks on your URL. This article walks you through a structured diagnostic process so you can pinpoint the cause and get your audit running successfully. 🗺️ How to Access On-Page Audit Navigate to Left sidebar → Content → On-Page Audit. Enter your target URL and start the audit from this page. If the audit returns a Failed status, work through the steps below before re-running it. 🔎 Step 1 — Confirm the URL Is Accessible The most common cause of a silent failure is that Search Atlas cannot reach the page. Check each of the following: - Open the URL in a private/incognito browser window. If the page does not load for you either, the site or page is down — the audit cannot run until it is back online. - Check for a login wall or paywall. If the page requires a password or account to view, the crawler is blocked. Audit publicly accessible pages only. - Check for a CAPTCHA or bot-detection screen. Security tools like Cloudflare's "I am not a robot" challenge will block the crawler. Contact your hosting provider or IT team to whitelist Search Atlas. - Try a direct page URL, not a redirect chain. Paste the URL into a redirect checker (e.g., type it into your browser and watch the address bar). If the final destination URL is different from what you entered, use the final destination URL in the audit. 🤖 Step 2 — Check Your robots.txt and Meta Robots Tags Even if a page loads in a browser, it may be blocking crawlers at the server level. - Visit yourdomain.com/robots.txt and look for any Disallow rules that match your target URL path. - View the page source (right-click → View Page Source) and search for a meta name="robots" tag. If its content includes noindex or nofollow, the audit may be restricted. - If either block is in place and is intentional, the audit cannot be run on that URL. If it is unintentional, update your robots.txt or meta tag and re-run the audit. ⚙️ Step 3 — Verify the URL Format An incorrectly formatted URL will always cause a failure. Before re-running the audit, confirm: - The URL begins with https:// or http:// (include the protocol). - There are no trailing spaces, hidden characters, or broken special characters copied from another tool. - The URL points to a specific page, not a JavaScript-only single-page app route that returns a blank HTML shell to crawlers. 📋 Step 4 — Note the Exact Conditions of the Failure If the audit still fails after the checks above, gathering the right details will help our team resolve it quickly. Before contacting support, note the following: - The full URL you entered (e.g., https://oakknollranch.com/page-name). - The exact time and date you ran the audit. - Whether this is the first time you have tried this URL or whether it worked before. - Whether other URLs on the same domain audit successfully. - Any browser console errors if you are comfortable opening browser developer tools (press F12 → Console tab). 🔄 Step 5 — Clear and Re-Run the Audit Once you have confirmed the URL is reachable, not blocked, and correctly formatted, try the following before escalating: 1. Navigate back to Left sidebar → Content → On-Page Audit. 2. Delete the failed audit entry if the option is available. 3. Re-enter the URL carefully and start a new audit. 4. Wait at least two full minutes before checking the status — large pages can take longer to process. ⚠️ Common Causes at a Glance - Site is down or returning a 4xx/5xx error — wait for the site to recover, then retry. - Cloudflare or similar firewall blocking the crawler — whitelist Search Atlas crawlers with your hosting provider. - robots.txt Disallow rule — update the rule if the block is unintentional. - Redirect loop or broken redirect — use the final destination URL. - JavaScript-rendered page with no static HTML — audit a static version of the page if possible. - URL typo or missing protocol — re-enter the URL with https://. 💬 Still Failing? Contact Support If you have worked through every step above and the audit continues to fail, our team can investigate the specific error at the server level. Please have the details from Step 4 ready when you reach out — this allows us to diagnose the issue without back-and-forth delays. If you need further assistance, open 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 Site Audit Credits Showing as Depleted

🔍 Overview Some customers see a message saying they are out of Site Audit credits and need to upgrade, even though they have unused slots remaining and an active paid subscription. This is a known display issue and is usually straightforward to resolve without changing your plan. ⚙️ Why This Happens Site Audit credits can appear depleted for a few common reasons: - Pending or processing audits: Credits are reserved the moment an audit is queued, even before it finishes running. If multiple audits were triggered — including any automatic reschedules — those reservations can temporarily appear to consume your full quota. - Cached quota data: The credit counter displayed in the platform can sometimes reflect a stale snapshot. A refresh or brief wait is enough to correct it. - Duplicate or unintended audit runs: Accidentally submitting the same site more than once in a short window reserves credits for each submission, which can make the quota look exhausted. - Subscription sync delay: After a payment is processed or a plan is renewed, there can be a short delay before your refreshed credit allowance is reflected in the platform. 🚀 Steps to Resolve the Issue 1. Hard-refresh your browser. Press Ctrl + Shift + R (Windows) or Cmd + Shift + R (Mac) to clear cached page data and reload your current quota balance. 2. Check for queued or in-progress audits. Navigate to Site Metrics → Site Explorer in the left sidebar. Review your list of sites and look for any audits with a Pending or In Progress status. Credits tied to these runs are reserved until the audit completes or is cancelled. 3. Cancel unneeded duplicate audits. If you see the same site queued more than once, cancel the duplicate entries. Reserved credits will be released back to your quota shortly after cancellation. 4. Wait up to 15 minutes after payment. If your subscription recently renewed or you just completed a payment, allow a short window for the platform to sync your updated credit balance, then refresh again. 5. Log out and log back in. A fresh session forces the platform to pull the latest quota data from the server, which resolves most persistent display discrepancies. ✅ How to Confirm Your Credits Are Restored After completing the steps above, your available Site Audit credit count should update to reflect your correct remaining quota. You can verify this by returning to Site Metrics → Site Explorer in the left sidebar. If the counter still shows zero despite unused slots, proceed to the next section. 💡 Preventing This Issue in the Future - Avoid submitting the same site for auditing multiple times in quick succession. - If you schedule recurring audits, review your schedule settings to ensure only the intended frequency is set — unintended high-frequency schedules can consume credits faster than expected. - After any billing event, wait a few minutes before running new audits to allow your quota to sync. 🆘 Still Seeing Depleted Credits? If your credit counter still appears empty after following all the steps above and you can confirm you have unused quota on your current plan, our team can investigate and manually correct the balance if needed. If you need further assistance, open 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 Nginx 444 Errors in OTTO Projects

🔍 What Is the Nginx 444 Error? When you try to add a site to an OTTO project and see a "No sites found" error, the root cause may be your web server silently dropping the connection before Search Atlas can crawl the site. A 444 status code is specific to Nginx — it instructs the server to close the connection immediately without sending any response. Unlike a standard 403 or 429 error, a 444 response produces no error message, making it harder to diagnose. This is not a problem with your OTTO configuration. It means the Nginx server hosting your site is actively blocking the Search Atlas crawler before the crawl can begin. ⚙️ Why Nginx Returns a 444 to Search Atlas Nginx servers can be configured to return a 444 for requests that match certain conditions, including: - Requests from unrecognised or unlisted user-agent strings - Requests from IP address ranges not explicitly permitted in the server configuration - Security rules that treat automated crawlers as malicious traffic by default - Rate-limiting or bot-mitigation rules that trigger on crawl patterns Because the connection is dropped silently, the Search Atlas platform receives no usable response and cannot confirm the site exists — which is why OTTO reports "No sites found" instead of a clear access-denied message. ✅ How to Whitelist the Search Atlas Crawler To allow the Search Atlas crawler through your Nginx server, you need to permit its user-agent and/or IP ranges in your Nginx configuration. Follow the steps below or share them with your hosting provider or developer. 1. Identify your Nginx configuration file. This is typically located at /etc/nginx/nginx.conf or inside /etc/nginx/sites-available/ for your specific domain. 2. Whitelist the Search Atlas user-agent. Add a rule that allows requests from the Search Atlas crawler user-agent. Your developer should add a condition that checks for the Search Atlas bot user-agent string and ensures it is not matched by any return 444 or deny directive. Contact support via the chat widget below to obtain the exact current user-agent string for the Search Atlas crawler. 3. Whitelist Search Atlas IP ranges. Add the Search Atlas crawler IP addresses to your allowlist before any deny-all or connection-drop rules. Contact support via the chat widget below to obtain the current list of Search Atlas crawler IP addresses. 4. Check the order of your Nginx rules. Nginx processes rules sequentially. Ensure your whitelist rules appear before any blanket bot-blocking or rate-limiting rules, otherwise the allow rule will never be reached. 5. Reload Nginx to apply changes. Run sudo nginx -t to validate the configuration syntax, then run sudo systemctl reload nginx to apply the changes without downtime. 6. Re-add your site in OTTO. Navigate to OTTO SEO in the left sidebar and open All Sites (SEO Automation), open your OTTO project, and attempt to add the site again. The crawler should now be able to reach the site and the "No sites found" error should be resolved. 🛡️ If You Use a Third-Party Firewall or CDN Alongside Nginx If your Nginx server sits behind an additional layer such as a CDN or a web application firewall, the 444 block may be applied at the Nginx level even if your CDN settings appear to allow crawlers. Check both layers: - Nginx configuration — review all return 444 and deny directives, particularly inside if blocks that evaluate the user-agent or remote address. - WAF or CDN rules — confirm that bot-fight or challenge modes are not re-blocking the crawler after Nginx has been updated. Refer to your CDN provider's documentation for steps to whitelist specific user-agents or IP ranges at the CDN level. Both layers must permit the Search Atlas crawler for the connection to succeed. 🔎 How to Confirm the Block Is Resolved After updating your configuration, you can verify the fix before re-adding the site in OTTO: - Use a tool such as curl -A "[Search Atlas user-agent]" https://yourdomain.com from a terminal to simulate a crawler request and confirm the server returns a 200 response instead of dropping the connection. - Check your Nginx access logs (/var/log/nginx/access.log) to confirm requests from the Search Atlas user-agent are no longer returning 444. - Once confirmed, navigate to OTTO SEO in the left sidebar and open All Sites (SEO Automation), then retry adding the site to your OTTO project. 💬 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 & Site Audit Improvements and Fixes

We've shipped a batch of improvements and bug fixes across OTTO and Site Audit to make metrics more accurate, schema handling cleaner, and core features more reliable. ✨ What's New This release focuses on sharper reporting, clearer brand settings, and a smoother overall experience. The most notable enhancements include: - Percentage change calculations have been added to holistic pillar metrics, so you can quickly see how performance is trending. - A deprecation banner now appears on the legacy OTTO version to guide you toward the current experience. - A tooltip was added to the ISO 6523 code field in brand settings, explaining what the field is for. 🛠️ How to Use It 1. Open OTTO SEO or Site Audit from the left sidebar (Left sidebar → OTTO SEO → Site Audit). 2. Review your holistic pillar metrics to see the new percentage change indicators. 3. Visit brand settings to find the ISO 6523 code tooltip when configuring brand details. 4. If you're still on the legacy version, follow the prompt in the deprecation banner to move to the current version. 📋 What to Expect Alongside the improvements above, we resolved several issues affecting accuracy and reliability: - Domain-level metrics and authority data now update correctly. - Exchange rate functionality works as expected. - The schema deployment filter now shows the correct count for not-deployed page-level items. - Instant indexing activation errors have been fixed. - OTTO-suggested FAQ schema no longer appears as found schema. - Internal linking opportunities now appear correctly in the URL filter. - Internal schema fields are now stripped from the JSON-LD preview and original schema display. These changes apply automatically with no action required on your part. 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.

🛠️ Fix OTTO Pixel & Slow Crawl on GoHighLevel

🔍 Overview Two common issues arise when connecting OTTO SEO to a GoHighLevel (GHL) site: the OTTO pixel not being detected after installation, and the site crawl taking an unusually long time (three hours or more). This article walks you through the most effective fixes for both problems. ⚙️ How to Access OTTO SEO To get started, navigate to OTTO SEO in the left sidebar of your Search Atlas dashboard, then open SEO Automation inside it (URL: /seo-automation-v3). Select the property connected to your GoHighLevel site and proceed from there. 📋 Part 1: OTTO Pixel Not Being Detected If OTTO reports that the pixel has not been found, the most common causes are an incorrect placement of the pixel code or a caching layer that is serving an outdated version of your page. Follow these steps in order: 1. Copy the pixel code exactly. In the OTTO SEO dashboard, open your connected property and locate the pixel snippet. Copy the entire code block without adding or removing any characters. 2. Paste into the GoHighLevel header. In your GHL account, go to Sites → Your Website → Settings → Custom Code and paste the pixel into the Header section. Do not place it in the footer, as OTTO requires the pixel to load early in the page lifecycle. 3. Save and publish your changes. Click Save and then republish your site inside GoHighLevel. Changes that are saved but not published will not appear on the live page. 4. Clear GoHighLevel's cache. Navigate to Sites → Your Website → Settings and use the Clear Cache option if available in your plan. If your site sits behind Cloudflare or another CDN, purge the cache there as well. 5. Trigger a re-detection in OTTO. Return to the OTTO SEO dashboard, open the property settings, and click Re-check Pixel (or Verify Installation). Allow up to five minutes for the check to complete. 6. Confirm with a live page inspection. Open your GoHighLevel site in a browser, right-click, select View Page Source, and search for your OTTO pixel ID. If the snippet is visible in the source, the pixel is live and OTTO should detect it on the next check. If the pixel ID appears in the source but OTTO still reports it as undetected, the page may be behind a login wall or a password-protection layer that prevents OTTO's crawler from reading it. Temporarily disable any password protection, run the pixel check, and then re-enable it. 🐢 Part 2: Site Crawl Running for 3+ Hours A slow or stalled crawl on a GoHighLevel site is usually caused by one of the following: a very large number of pages, JavaScript-heavy rendering, crawl-blocking rules, or server rate limiting. Try the steps below to resolve it: 1. Check your robots.txt file. In a browser, visit yourdomain.com/robots.txt. If you see a Disallow: / rule or a rule blocking all bots, GoHighLevel's default settings may be restricting the crawler. Update your robots.txt inside GHL under Sites → Settings → SEO to allow crawling. 2. Reduce the crawl scope (if available). In the OTTO SEO dashboard, check whether you can limit the crawl to specific folders or page types. Crawling only your most important pages first will return faster results. 3. Disable JavaScript-only page features during the crawl window. OTTO's crawler can time out on pages that rely heavily on client-side JavaScript to load content. Where possible, ensure critical content is available in the raw HTML. 4. Pause and restart the crawl. If the progress bar has not moved for more than 30 minutes, cancel the current crawl from the OTTO SEO dashboard and start a new one. Transient server timeouts are often resolved simply by re-initiating the process. 5. Check GoHighLevel server status. Occasionally GHL experiences platform slowdowns that affect crawl speeds. Visit the GoHighLevel status page to confirm there are no active incidents. 6. Avoid crawling during peak hours. If your site is under heavy traffic, scheduling the crawl for off-peak hours (early morning or overnight) can significantly reduce completion time. ✅ Quick-Reference Checklist - Pixel pasted into GHL Header section, not footer - Site saved and published after adding the pixel - Cache cleared in GHL and any connected CDN - robots.txt allows crawler access - Crawl restarted if stalled for more than 30 minutes - JavaScript-heavy redirects or splash pages temporarily bypassed 💬 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.

🔍 Search Atlas Score Drop Troubleshooting Guide

🧭 Overview A sudden drop in your Search Atlas score — especially to a very low number like 1/100 — can be alarming. This article explains the most common root causes, defines key terms like orphaned pages, and walks you through the steps to diagnose and resolve the issue. 📊 What Is the Search Atlas Score? The Search Atlas score is a composite health metric that evaluates multiple on-site and off-site SEO factors across your domain. A dramatic drop to 1/100 typically signals that one or more critical issues have been detected — not necessarily that your domain authority has collapsed overnight. Important: The Search Atlas score is an internal diagnostic metric. It reflects the health of your SEO setup as measured by the platform. It is separate from third-party domain authority scores. 🚨 Common Root Causes of a Dramatic Score Drop A score drop to 1/100 is usually triggered by one or more of the following: - Orphaned pages detected: Pages with no internal links pointing to them are flagged heavily and can significantly lower your score. - New site crawl completed: If a fresh crawl was recently run, previously undetected issues may now appear in your score for the first time. - Major technical issues found: Broken links, missing meta tags, duplicate content, or crawl errors introduced by a site update. - Project reconfiguration: A change in your project settings, tracked URL, or sitemap can trigger a re-evaluation that surfaces historical issues. - Indexability problems: Pages blocked by robots.txt, noindex tags, or redirect chains that affect a large portion of your site. ❓ What Are Orphaned Pages? An orphaned page is any page on your website that has no internal links pointing to it from other pages on the same site. Search engine crawlers discover pages by following links. If a page has no internal links leading to it, crawlers may never find it — and neither will users navigating your site. Orphaned pages hurt your score because they: - Cannot receive internal link equity (PageRank) from the rest of your site. - Are at high risk of not being indexed by search engines. - Often indicate structural gaps in your site architecture. Common sources of orphaned pages include deleted menu items, old blog posts never linked to from other content, landing pages created for campaigns but not integrated into the site, and pages removed from navigation without a redirect. 🔎 How to Diagnose Your Score Drop 1. Go to the left sidebar and select Content → Onpage Audit. 2. Open the relevant tab for your site or page (for example, the domain-level tab). 3. Click Run Audit to run a fresh audit if one has not been completed recently. 4. Review the report for flagged issues. Look specifically for: - Orphaned pages listed under structural or linking issues. - Broken internal or external links. - Missing or duplicate title tags and meta descriptions. - Pages with noindex tags or crawl blocks. 5. Use the Topical Terms and Questions tabs to identify any content gaps contributing to the score. 6. Export your findings using the Export button on the Topical Terms or Questions tabs for further analysis. 🛠️ How to Fix Orphaned Pages 1. Identify all orphaned pages from your Onpage Audit report. 2. For each orphaned page, decide whether it should be kept or removed: - Keep the page: Add at least one internal link to it from a relevant, already-indexed page. Ideally, link to it from your site navigation, a category page, or a related blog post. - Remove the page: Set up a 301 redirect to the most relevant existing page, or remove it and update any remaining references. 3. Re-run the Onpage Audit after making changes to confirm the orphaned pages issue has been resolved. ⚠️ When a Score Drop Is Not an Emergency In some cases, a dramatic score drop is a data artifact rather than a real site problem. This can happen when: - A new project or domain was just added and the first crawl is incomplete. - A crawl ran during a period of site maintenance or downtime. - The scoring model was recently updated to include additional ranking factors. If your site appears healthy in Google Search Console and your organic traffic is stable, re-run the audit and compare results before taking action. ✅ Next Steps After Fixing Issues - After resolving orphaned pages and other flagged issues, return to Content → Onpage Audit and click Run Audit to refresh your score. - Use Mark as Done on resolved items to keep your audit organised. - Monitor your score over the following days. Improvements may take one or two crawl cycles to fully reflect. - Use the Home dashboard (left sidebar → Home) to track overall project health and review playbooks for additional optimisation recommendations. 💬 Still Need Help? If you have reviewed your audit report and are still unable to identify why your score dropped, or if the score remains at 1/100 after resolving flagged issues, our team can help you investigate further. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Fix Persistent Issues in Search Atlas

🔍 Overview If you are experiencing a persistent issue in Search Atlas — something that keeps coming back no matter what you try — this guide will walk you through the most effective troubleshooting steps. Following these steps in order resolves the majority of recurring technical problems without needing to contact support. ⚙️ Step 1: Perform a Hard Refresh Cached browser data is one of the most common causes of persistent platform issues. A hard refresh forces your browser to reload all files fresh from the server. - Windows / Linux: Press Ctrl + Shift + R - Mac: Press Cmd + Shift + R After the refresh, check whether the issue still occurs before moving to the next step. 🧹 Step 2: Clear Browser Cache and Cookies If a hard refresh does not help, clearing your full browser cache and cookies will remove any corrupted or outdated stored data that may be interfering with the platform. 1. Open your browser settings. 2. Navigate to Privacy and Security (or equivalent). 3. Select Clear browsing data. 4. Check Cached images and files and Cookies and other site data. 5. Set the time range to All time. 6. Click Clear data, then reload Search Atlas. 🌐 Step 3: Try a Different Browser or Incognito Mode Browser extensions, settings, or profiles can sometimes conflict with platform functionality. Testing in a clean environment quickly confirms whether your browser is the source of the problem. - Open a private or incognito window in your current browser and log in to Search Atlas. - Alternatively, try a different browser entirely (for example, switch from Chrome to Firefox or Edge). If the issue disappears in a clean environment, a browser extension is likely the cause. Try disabling extensions one at a time to identify the culprit. 🔌 Step 4: Check Your Internet Connection An unstable or slow connection can cause features to load incorrectly, time out, or behave unpredictably in ways that appear to be platform bugs. - Run a speed test at a site like fast.com to confirm your connection is stable. - If you are on Wi-Fi, try switching to a wired connection. - Restart your router if speeds are unusually low. 🚀 Step 5: Identify the Specific Feature or Page Narrowing down exactly where the issue occurs makes it much faster to resolve — both on your own and with our support team. Before escalating, try to note the following: - Which feature or tool is affected (for example, a specific tool or page within Search Atlas). - What action triggers the problem (clicking a button, loading a page, saving a setting). - How often it occurs and whether it happens consistently or intermittently. - Any error messages displayed — copy the exact wording if possible. - Your browser name and version, and whether you have already tried the steps above. Having this information ready will significantly speed up resolution if you need to contact support. 📞 Still Experiencing the Issue? If the steps above have not resolved your problem, our support team can investigate further. Please have the following ready when you reach out: the feature or page affected, the exact error message (if any), the steps you have already tried, and the browser and device you are using. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 Fix Dashboard Issue Count and Page Indexing Problems

🧭 Overview Two common questions come up together: your dashboard still shows a large issue count even after you have fixed and deployed everything, and only some of your pages appear in Google's index. This article walks you through both situations step by step so you can confirm your fixes are recorded correctly and understand why certain pages may not be indexed yet. 📊 Why Your Dashboard Still Shows Issues After Fixing Them The issue count on your dashboard reflects the state of your site the last time Search Atlas crawled it. Deploying fixes to your live site does not automatically update the count — the platform needs to re-crawl your pages to detect the changes. There are three common reasons the count stays high after you have made fixes: - No re-crawl has run yet. Your fixes are live but Search Atlas has not crawled those pages since the changes were deployed. - Fixes were saved in the editor but not published to your live site. Changes made inside Search Atlas do not push directly to your CMS or server unless you explicitly export or publish them. - Some issues belong to pages or issue types you have not reviewed yet. The total count includes every open issue across all pages, not only the ones you worked on. 📍 How to Locate All 1,599 Open Issues To see exactly where your remaining issues are and confirm which ones are resolved, follow these steps: 1. Go to Home from the left-hand navigation bar. 2. Locate the Site Audit or Issues section on your dashboard and click View All Issues. 3. Use the filters at the top of the issue list to sort by issue type, priority, or page URL. This helps you identify patterns — for example, all missing meta descriptions or all broken internal links grouped together. 4. Check the Status column. Issues marked Open have not yet been confirmed as fixed by a crawl. Issues marked Fixed were detected as resolved during the most recent crawl. 5. If an issue you fixed still shows as Open, trigger a manual re-crawl by going to OTTO SEO → Site Audit → Overview (Website Overview) and clicking Recrawl Site. Once the crawl completes, the status will update automatically. After the re-crawl finishes, return to the issue list. Any issues correctly resolved on your live site will move to a Fixed status and the total count will decrease accordingly. 🗂️ Where to Find Fixes Inside Content Optimizations If you used the Content Optimizations tool to make on-page edits, your changes are stored inside that tool and must be exported or applied to your live site separately. To review them: 1. Navigate to Content Optimizations from the main menu. 2. Select the page you edited. 3. Review the Recommendations panel to see which suggestions were accepted, which are still pending, and which were skipped. 4. If you accepted changes but did not publish them, copy the optimized content and update your live page manually, or use the export option if your integration supports it. Changes that exist only inside Content Optimizations and have not been applied to your live site will not reduce your dashboard issue count because the crawler reads your published pages, not your drafts inside the platform. 🌐 Why Only 23 of Your 33 Pages Are Indexed Having fewer pages indexed than you expect is a separate issue from your dashboard issue count. Google decides independently which pages to include in its index. Search Atlas can surface data that helps you diagnose the cause, but the indexing decision itself belongs to Google. Common reasons pages are not indexed include: - Pages are too new. Google may not have crawled them yet. New pages can take days to several weeks to appear in the index. - Crawl budget limitations. On smaller or newer sites, Google may not crawl every page on every visit. - Noindex tags or directives. A noindex meta tag or an X-Robots-Tag HTTP header tells Google explicitly not to index the page. - Blocked in robots.txt. If your robots.txt file disallows Googlebot from crawling certain paths, those pages will not be indexed. - Thin or duplicate content. Google may choose not to index pages it considers low-quality, near-duplicate, or lacking original value. - Pages not included in your sitemap. If your XML sitemap is missing URLs, Google is less likely to discover them quickly. 🔧 Steps to Troubleshoot Missing Indexed Pages 1. Check Google Search Console. Open GSC and go to Pages under the Indexing section. Look for the Not indexed tab. GSC will show you exactly why each page was excluded — for example, Crawled – currently not indexed, Excluded by noindex tag, or Blocked by robots.txt. 2. Audit your noindex settings. In Search Atlas, run a crawl and filter your issue list for noindex tags. Confirm that the 10 missing pages do not have an accidental noindex directive applied. 3. Review your robots.txt file. Check that the paths for your missing pages are not blocked. You can use Google's robots.txt Tester inside GSC to verify access for Googlebot. 4. Submit your sitemap. In GSC, go to Sitemaps and confirm your XML sitemap is submitted and has no errors. Make sure all 33 pages are listed in the sitemap. 5. Request indexing for specific pages. In GSC, use the URL Inspection tool, enter the page URL, and click Request Indexing. This signals to Google that the page is ready to be crawled and considered for inclusion. 6. Improve page quality. If Google has crawled the page but chosen not to index it, review the content for thin text, duplicate sections, or missing structured information. Use Search Atlas Content Optimizations to strengthen the page before requesting re-indexing. ⏱️ How Long Does Re-Indexing Take? After you request indexing through GSC, Google typically processes the request within a few days for most sites, though it can take up to a few weeks in some cases. There is no guaranteed timeline. Continue monitoring the Pages report in GSC weekly to track progress. Once a page is indexed, it will move from the Not indexed list to the All submitted pages or Indexed view. 💬 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 Meta Description Override Issues

🔍 Overview If Search Atlas is leaving your meta descriptions blank or injecting unexpected content — such as keywords or meta titles — into your pages, the most common cause is a crawler access restriction. When the Search Atlas crawler cannot reach your page, it cannot read or preserve your existing meta description, which causes it to fall back to a blank or auto-generated value. This article walks you through diagnosing the problem and whitelisting the Search Atlas crawler IPs so your meta descriptions are processed correctly. ⚠️ Symptoms of This Issue - Your meta description appears blank in search results or in the Search Atlas dashboard. - Search Atlas is injecting keywords or the meta title into the description field against your instructions. - The issue persists on specific pages even after you have manually set and saved a meta description. - The problem affects one or more URLs but not your entire site. 🧠 Why This Happens Search Atlas uses a crawler to read your pages and apply on-page optimisation settings, including meta descriptions. If your server, firewall, CDN, or security plugin blocks the crawler's IP addresses, the crawler cannot retrieve your existing meta description. As a result, Search Atlas either leaves the field blank or substitutes it with automatically generated content. This is not a bug in your settings. It is a connectivity issue between the Search Atlas crawler and your web server that must be resolved at the server or security layer. ✅ Step 1 — Confirm the Crawler Is Being Blocked Before whitelisting any IPs, confirm that a block is actually occurring: 1. Log in to your hosting control panel, firewall dashboard, or CDN provider (for example, Cloudflare, Sucuri, or Wordfence). 2. Navigate to the access logs or blocked requests section. 3. Search for any blocked requests originating from the Search Atlas crawler. 4. Note the timestamps and the specific URLs being blocked. If you see blocked requests in the logs, proceed to Step 2. If logs are unclear or inaccessible, proceed directly to the whitelist step — adding the IPs causes no harm and resolves the issue in the majority of cases. 🔧 Step 2 — Whitelist the Search Atlas Crawler IPs Add the Search Atlas crawler IP addresses to the allowlist in your firewall, CDN, security plugin, or hosting control panel. To obtain the exact list of current Search Atlas crawler IPs, please contact the support team using the instructions at the bottom of this article. The exact steps for adding IPs to your allowlist depend on your platform. In general: - Cloudflare: Locate the IP allowlist or firewall rules section in your Cloudflare dashboard and add each crawler IP as an allowed address. - Wordfence: In your WordPress admin panel, navigate to the Wordfence settings and add each IP to the whitelist under the firewall allowlist options. - Other firewalls or security plugins: Refer to your provider's documentation for adding IP addresses to an allowlist or trusted IPs list. ✅ Step 3 — Verify the Fix 1. After whitelisting the IPs, return to the affected page in your Search Atlas dashboard. 2. Trigger a re-crawl or wait for the next scheduled crawl cycle. 3. Confirm that your meta description is now being read and preserved correctly. If the meta description is still blank or incorrect after re-crawling, double-check that all crawler IPs were saved correctly in your firewall or security settings. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Troubleshooting Cloud Stack Generation Failed Errors

This article addresses the "Cloud stack generation failed. Please try generating again" error that can appear when uploading images within the platform. This error is typically triggered by image file issues, upload timing problems, or exceeding system constraints — even when you believe you are within the allowed limits. Follow the steps below to identify and fix the root cause. 🔍 Common Causes - Unsupported file format or corrupt image: The platform requires standard image formats (JPG, PNG, WebP). Corrupt files or uncommon formats can silently fail during cloud processing. - File size too large: Even if you have selected fewer than the maximum number of images, an individual file may exceed the per-image size limit. - Image dimensions out of range: Extremely large or unusually small pixel dimensions can cause the cloud stack to fail during generation. - Temporary upload or server timeout: A slow connection or a brief platform instability can interrupt the cloud processing step. - Metadata or EXIF data conflict: Some images carry embedded data that can interfere with cloud stack processing. 🛠️ Step-by-Step 1. Check your image file format. Confirm each image you are uploading is saved as JPG, PNG, or WebP. If your file is in HEIC, TIFF, BMP, or another format, convert it to JPG or PNG using any free image converter before re-uploading. 2. Check individual file size. Even if you selected fewer than 4 images, verify that each individual file is under 5 MB. Large files can exceed the cloud processing limit on their own. Compress or resize any oversized images before retrying. 3. Check image dimensions. Ensure your images are not excessively large (e.g., raw camera exports at 8000×6000 px or higher). Resize to a web-friendly resolution such as 1200×800 px and attempt the upload again. 4. Strip image metadata. Use a tool such as Squoosh (squoosh.app) or your operating system's export options to save a clean copy of the image without EXIF metadata, then try uploading the cleaned file. 5. Retry the generation. After addressing any file issues, dismiss the error message, re-select your images, and click the generate button again. Wait for the progress indicator to complete fully before navigating away. 6. Try a single image first. If the error persists with multiple images, isolate the problem by uploading one image at a time to identify which specific file is causing the failure. 7. Clear your browser cache and retry. A stale session can contribute to upload failures. Clear your browser cache, log back in, and attempt the upload in a fresh session or a different supported browser (Chrome or Edge recommended). ✅ How to Confirm It Worked After retrying, the cloud stack generation is successful when: - The progress indicator completes without displaying the "Cloud stack generation failed" message. - Your uploaded image or images appear as previews or thumbnails within the interface where you initiated the upload. - Any associated content or feature that depends on the image (such as a schema entry or GBP post) shows the image attached and ready to use. If the error reappears on a specific image even after following all steps above, save the file name, its format, and its size so our team can investigate a potential processing issue on that file type. If you need further assistance, open 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 Confirm you are selecting fewer than 4 images — deselect all images and reselect them one at a time to rule out a selection state error in the UI. Also: try a different browser or clear your cache / open in incognito window, as stale cache can interfere with upload processing.

🔍 Fix Site Audit Zero Pages Crawled Issue

🧭 Overview If your Site Audit shows zero crawled pages, or you notice that features like JS Rendering appear enabled on a plan that does not include them, this article will help you understand what is happening and what to have ready when you contact our team. 🔍 Why Is My Site Audit Showing Zero Crawled Pages? There are several common reasons why the Site Audit crawler returns zero pages: - Incorrect start URL: The crawl URL may be missing the correct protocol (https://) or may point to a redirected or blocked page. - Robots.txt blocking the crawler: Your site's robots.txt file may be disallowing the Search Atlas crawler from accessing any pages. - Invalid or missing sitemap: If the sitemap URL is incorrect or returns errors, the crawler may fail to discover pages and report zero results. - Crawl quota or configuration issue: Your account may have reached its crawl quota limit, or there may be a backend configuration problem preventing the crawl from completing correctly. - Plan feature conflict: Certain features such as JS Rendering may appear active on plans that do not include them, which can indicate an account configuration issue requiring backend review. ⚙️ What to Check Before Escalating Before reaching out to our team, please review the following and have the details ready: - The exact project or site name affected in your Site Audit. - The start URL configured for the audit and whether it is accessible in a browser. - The sitemap URL you are using and whether it loads correctly in a browser. - Any URL exclusion rules you have set — overly broad exclusions can block the crawler from discovering pages. - The exact error message or behavior you are seeing (e.g., zero pages shown, a specific feature appearing enabled). - The timestamp of when the issue first occurred or when the affected crawl was run. - Your current plan name (e.g., Starter), so our team can verify which features should be active on your account. Having these details ready will allow our team to investigate and resolve the issue as quickly as possible. 🚫 JS Rendering Appearing on My Plan JS Rendering is a premium feature not included in all plans. If you see it appearing as enabled in your Site Audit settings on a plan that should not include it, this is a backend account configuration issue that requires our team to investigate directly. Please do not attempt to toggle this setting on your own, as the underlying configuration needs to be corrected at the account level. If you need further assistance, open 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 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.

🤖 Fix Unexpected Disallow Entries in robots.txt

🔍 Overview If your live robots.txt file contains Disallow entries that do not appear in the Search Atlas robots.txt editor, those rules are almost certainly being added by your hosting provider, WordPress plugin, or another third-party tool — not by Search Atlas. This article explains why this happens and what you can do about it. ⚠️ Why Extra Disallow Entries Appear Search Atlas generates and previews the robots.txt rules that it controls. However, your website's final, publicly served robots.txt file is assembled by your hosting environment. Common sources of extra Disallow entries include: - Hosting provider defaults — Many managed hosts (e.g. WP Engine, Kinsta, SiteGround) automatically inject their own robots.txt rules, sometimes blocking AI crawlers or staging paths. - WordPress plugins — SEO plugins such as Yoast SEO, Rank Math, or All in One SEO can override or append to the robots.txt file independently of Search Atlas. - CMS-level settings — Some CMS platforms have a built-in robots.txt editor in their admin dashboard that takes priority over other tools. - Server-level configuration — A physical robots.txt file stored in your site's root directory will override virtually generated rules. Because Search Atlas only previews the rules it manages, any entries injected upstream will not appear in the Search Atlas editor — but they will appear when you fetch the live file directly. 🛠️ How to Identify the Source 1. Open your browser and go to https://yourdomain.com/robots.txt to see the live file. 2. Compare that output with what is shown in the Search Atlas robots.txt editor. 3. Any Disallow lines present in the live file but absent from the Search Atlas preview are coming from an external source. 4. Log in to your hosting control panel and check for a robots.txt management section or firewall/crawl settings. 5. In your WordPress dashboard (if applicable), check Settings → Reading and any active SEO plugin for robots.txt controls. 6. Use FTP, SFTP, or your host's file manager to check whether a physical robots.txt file exists in your site's root (/public_html/ or equivalent). ✅ How to Remove the Unwanted Entries Once you have identified the source, follow the appropriate steps below. - Hosting provider rules: Contact your host's support team and ask them to remove or disable any automatic robots.txt injection. Some hosts provide a toggle in their dashboard under crawl or bot-management settings. - Physical robots.txt file: If a static file exists in your root directory, delete it or edit it to remove the unwanted Disallow lines. Search Atlas can then manage the file virtually. - WordPress SEO plugin: Open the plugin's settings, locate its robots.txt editor, and remove any conflicting entries. If you want Search Atlas to be the sole manager, disable the plugin's robots.txt feature entirely. - CMS built-in editor: Navigate to your CMS robots.txt settings and clear any rules that conflict with your Search Atlas configuration. 🔄 Verifying the Fix 1. After making changes, wait a few minutes for your server cache to clear. 2. Reload https://yourdomain.com/robots.txt in your browser. 3. Confirm that the unwanted Disallow entries are gone. 4. Return to Search Atlas and verify that the preview matches the live file. 💡 Best Practices - Designate one tool only as the robots.txt manager for your site to avoid conflicts. - After any hosting migration or plugin update, re-check your live robots.txt file to catch newly injected rules early. - Keep a record of what each Disallow entry is for so you can quickly spot anything unexpected in the future. 🙋 Need More Help? If you have followed the steps above and are still seeing unexpected Disallow entries in your live robots.txt file, If you need further assistance, open 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 Connection Stuck in Processing or Crawling

🔍 What This Issue Looks Like After installing the OTTO script on your website and attempting to connect your site, the connection process does not complete. The status remains stuck — either in a processing or crawling state — even after waiting several hours or days. The site never fully activates in OTTO. ⚠️ Why This Happens In some cases, OTTO's background crawl process can stop silently without returning an error message. The platform appears to be working, but the crawl has actually stalled internally. This is a known issue that has been identified and addressed by the Search Atlas engineering team. However, if your site is currently stuck, the steps below can help you resolve it. ✅ How to Fix It 1. Remove the OTTO script from your website. Log in to your website's backend and delete the OTTO script that was installed during the connection setup. 2. Delete the existing OTTO project. In the Search Atlas platform, go to Left sidebar → OTTO SEO → All Sites (SEO Automation) and remove the project associated with your stuck site. 3. Wait a few minutes before proceeding to allow the system to fully clear the previous connection attempt. 4. Create a fresh OTTO project. Still in Left sidebar → OTTO SEO → All Sites (SEO Automation), create a new project for your website as if connecting it for the first time. 5. Reinstall the OTTO script. Follow the setup instructions to install the OTTO script on your site again, using the installation steps provided within the OTTO SEO section of the platform. 6. Trigger a new connection. Once the script is reinstalled, attempt to connect your site again and monitor the status over the next 15–30 minutes. 📊 After Reconnecting If the connection completes successfully, your site will move past the processing stage and OTTO will begin its full setup. You can monitor the progress from the OTTO SEO section of the platform. 🚨 If the Issue Persists The fresh-connection approach resolves this issue in most cases. However, if your site remains stuck after following all the steps above, this may indicate a deeper infrastructure issue that requires engineering intervention — similar to cases where the crawl dies silently and cannot self-recover. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team. When you reach out, please have the following information ready to help the team investigate quickly: - Your website URL - The date and time you first attempted to connect - Confirmation that you have already removed and reinstalled the script - A description of the curr

🛠️ Fix Whitelabel Domain Script Unreachable Errors

🔍 Overview If you see a Script Unreachable status in your OTTO SEO dashboard even though your whitelabel domain appears to be correctly configured, there is likely a misconfiguration in your DNS, CNAME, or redirect settings that is preventing the OTTO script from loading. This article walks you through the most common causes and how to fix them. ⚙️ Why This Happens The OTTO script is served through your whitelabel domain. If the domain is not resolving correctly, the script cannot be reached — even if the domain settings look correct inside Search Atlas. Common root causes include: - CNAME target mismatch: Your DNS provider is pointing to an outdated or incorrect target hostname. - Redirect loop: Your whitelabel URL is returning ERR_TOO_MANY_REDIRECTS, which blocks the script from loading. - DNS propagation delay: Recent changes to your DNS records have not yet fully propagated across all servers. - False unreachable status: In some cases, the platform may incorrectly report the script as unreachable even when it is accessible. This is a known issue that has been resolved in recent updates. 🗺️ Step 1 — Verify Your Whitelabel Domain Settings 1. In Search Atlas, go to More Features → Agency Whitelabel (URL: /agency-settings). 2. Under White Label Setup, confirm that your custom domain is entered correctly with no trailing slashes or typos. 3. Note the CNAME target value shown in the platform — this is the exact hostname your DNS record must point to. 🌐 Step 2 — Check Your DNS CNAME Record 1. Log in to your domain registrar or DNS provider (for example, Cloudflare, GoDaddy, or Namecheap). 2. Locate the CNAME record for your whitelabel subdomain (for example, seo.youragency.com). 3. Confirm that the Value or Points to field matches exactly the CNAME target shown in Search Atlas. Even a small difference — such as a missing subdomain segment or an extra character — will cause a mismatch and break the script. 4. If the values do not match, update the CNAME record to use the correct target provided in the platform. 5. Allow up to 48 hours for DNS changes to propagate, though most updates take effect within a few hours. 🔄 Step 3 — Check for Redirect Loops A redirect loop on your whitelabel domain will prevent the OTTO script from loading entirely. To check for this: 1. Open a new browser tab and navigate directly to your whitelabel domain URL. 2. If the browser shows an ERR_TOO_MANY_REDIRECTS error, there is a redirect conflict in your DNS or hosting configuration. 3. Common causes include forcing HTTPS at both the DNS level and the hosting level simultaneously, or conflicting redirect rules in your .htaccess file or server configuration. 4. Disable any duplicate redirect rules and ensure HTTPS is enforced at only one layer. ✅ Step 4 — Recheck the Script Status in OTTO 1. After updating your DNS or redirect settings, go to Left sidebar → OTTO SEO → Installation Guide. 2. Click Continue installation to trigger a fresh script status check. 3. If the status still shows Script Unreachable after DNS has propagated and your settings are correct, the platform may be reporting a false status. Proceed to the next step. 🔎 Step 5 — Manually Verify the Script Is Accessible You can independently confirm whether the script is actually reachable before escalating: 1. Open your browser's developer tools (press F12 or right-click the page and select Inspect). 2. Go to the Network tab and reload your website. 3. Search for the OTTO script URL in the network requests. If it returns a 200 OK status, the script is loading correctly and the unreachable warning may be a display error that will clear on its own. 4. If the script request fails or returns an error code, the misconfiguration is confirmed and you should review Steps 2 and 3 again. 💡 Quick Reference — Common Issues and Fixes - CNAME target mismatch: Update your DNS CNAME record to match the exact target shown in More Features → Agency Hub (Agency Whitelabel). - ERR_TOO_MANY_REDIRECTS: Remove duplicate HTTPS redirect rules from your DNS and server configuration. - Script unreachable after correct setup: Wait for DNS propagation and use browser dev tools to verify the script loads with a 200 status. - False unreachable status in the dashboard: If the script is confirmed accessible via dev tools, the status should update automatically. If it does not, contact support. 💬 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 Crawler Blocks and Recrawl After Updates

🧭 Overview Search Atlas does not automatically recrawl your site when you make website changes. To see updated audit results, you must trigger a manual recrawl. Additionally, if your WordPress robots.txt file is blocking the Search Atlas crawler, your audit will fail or return incomplete data. This article walks you through both fixes. 🔄 How Site Audits Work in Search Atlas Search Atlas runs site audits based on snapshots taken at the time of the crawl. Unlike Google, the platform does not passively monitor your site for changes. This means: - Updates you make to your website are not reflected automatically in your audit results. - You must manually trigger a new crawl after making changes to see updated data. - Results shown in your dashboard represent the state of your site at the time of the last completed crawl. Waiting for a Google crawl will not update your Search Atlas audit — these are independent processes. 🚀 How to Manually Recrawl Your Site 1. Log in to your Search Atlas account. 2. Navigate to the site audit section of the platform for the project you want to update. 3. Locate the project for the website you have updated. 4. Open the site audit for that project. 5. Look for the option to run a new crawl or trigger a recrawl for that project and select it. 6. Wait for the crawl to complete — this may take a few minutes depending on site size. 7. Once finished, your audit results will reflect the current state of your website. Tip: Run a manual recrawl any time you publish significant content changes, fix technical SEO issues, or update your site structure to keep your audit data accurate. 🛠️ Why the Search Atlas Crawler Gets Blocked The most common reason a site audit fails to run is that the Search Atlas crawler is being blocked by your website's robots.txt file. This happens frequently on WordPress sites, especially after plugin updates or security setting changes. Signs that your crawler is blocked include: - The site audit fails to complete or returns no data. - You see an error indicating the crawler could not access your site. - Only a very small number of pages are returned in the audit results. ⚙️ How to Fix a WordPress robots.txt Crawler Block 1. Access your WordPress site and navigate to your robots.txt file. You can view it directly by going to yourdomain.com/robots.txt in your browser. 2. Look for any Disallow rules that may be blocking all crawlers or specifically blocking the Search Atlas user agent. A common culprit looks like this: Disallow: / under a User-agent: * rule. 3. To edit your robots.txt file in WordPress, access your WordPress dashboard and use an SEO plugin (such as Yoast SEO or Rank Math) that includes a robots.txt editor, or edit the file directly via your hosting file manager or FTP. 4. Remove or update the Disallow rule that is blocking crawlers so that the Search Atlas crawler can access your site. If you only want to block specific bots, replace the broad User-agent: * rule with more targeted entries. 5. Save your changes and verify the updated robots.txt by revisiting yourdomain.com/robots.txt in your browser. 6. Once the block is removed, return to Search Atlas and trigger a manual recrawl as described above to get updated audit results. Note: If you are unsure which plugin or setting is generating your robots.txt rules, temporarily deactivating recently updated security or SEO plugins can help identify the source of the block. If you need further assistance, open 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 Site Audit CORS and Sync Errors

🔍 Overview If your Site Audit is not picking up changes you made in Search Atlas — or you are seeing a Google Rich Results error or a CORS policy error blocking resource access — this article will explain why these issues occur and walk you through the steps to resolve them. ⚙️ Why Your Site Audit May Not Reflect Recent Changes Search Atlas Site Audits crawl your live website. This means the audit can only detect changes that have already been published and deployed to your site. Changes made inside Search Atlas (such as optimised meta tags, structured data, or content edits) will not appear in a new audit until they are pushed live on your actual website. Common reasons your audit results appear outdated: - Changes were saved in Search Atlas but not yet implemented on your website by your developer or CMS. - Your site uses a caching layer (CDN, server cache, or plugin cache) that is serving an older version of your pages. - The audit was re-run before your server had fully propagated the updates. - A previous crawl result is still being displayed — a fresh audit has not been triggered since the changes went live. 🚫 Understanding the CORS Policy Error A CORS (Cross-Origin Resource Sharing) error occurs when your website's server blocks external requests to load certain resources — such as scripts, stylesheets, or fonts — from a different origin. During a Site Audit, Search Atlas crawls your pages and attempts to access linked resources. If your server's CORS headers do not permit these requests, the audit flags the affected resources as inaccessible. This is a server-side configuration issue on your website, not a Search Atlas platform error. It must be resolved by updating your server or CDN headers to allow the necessary cross-origin requests. ✅ How to Fix Sync Issues (Changes Not Appearing) 1. Confirm your changes are live: Open your website in an incognito or private browser window and verify the updates are visible on the published pages. 2. Clear your site cache: Purge any caching plugin, CDN cache (such as Cloudflare or Fastly), or server-side cache so the latest version of your pages is served to crawlers. 3. Wait for propagation: After publishing and clearing caches, allow at least 15–30 minutes before re-running the audit. 4. Run a new Site Audit: Navigate to Left sidebar → OTTO SEO → Site Audit, locate your project, and trigger a fresh crawl. Do not rely on a cached audit result from before your changes went live. 5. Check your implementation: If the audit still does not reflect your changes after a fresh crawl, confirm with your developer that the correct code or meta data was deployed to the production environment, not just a staging server. ✅ How to Fix the CORS Policy Error 1. Identify the blocked resources: Review the Site Audit report to note exactly which URLs or resource types are being blocked by the CORS policy. 2. Update your server headers: Work with your developer or hosting provider to add the appropriate Access-Control-Allow-Origin header to your server or CDN configuration. For most sites, setting this to * (wildcard) or to the specific origins required will resolve the error. 3. Check CDN settings: If you use a CDN such as Cloudflare, check the CORS settings within your CDN dashboard. Some CDNs cache CORS headers separately and may require a cache purge after updating rules. 4. Re-run the audit: Once your headers are updated and caches are cleared, trigger a new Site Audit to confirm the CORS errors are resolved. 🌟 How to Fix the Google Rich Results Error A Google Rich Results error in your audit typically means that structured data (schema markup) on one or more of your pages is missing required fields, contains invalid values, or is not formatted correctly according to Google's specification. 1. Identify the affected pages: Review the Site Audit report to find which pages have Rich Results errors and what specific fields are flagged. 2. Test your structured data: Copy the page URL and paste it into Google's Rich Results Test tool (search.google.com/test/rich-results) to get a detailed breakdown of the errors. 3. Correct the schema markup: Update the structured data on your page to include all required properties for your schema type (e.g., Article, Product, FAQ). Ensure values match the expected format. 4. Re-publish and re-audit: Once corrections are live and your cache is cleared, run a fresh Site Audit to confirm the Rich Results errors are resolved. 💡 Tips to Prevent These Issues in the Future - Always verify changes are deployed to your live production site before running a new audit. - Set up a cache-clearing workflow as part of your deployment process so crawlers always see the latest version of your pages. - Validate structured data with Google's Rich Results Test tool before and after making schema changes. - Ensure your server's CORS headers are configured correctly as a baseline, especially if you use a CDN or third-party resource hosting. 🆘 Still Seeing the Error? If you have followed all the steps above and your Site Audit is still not reflecting your changes or continues to show CORS or Rich Results errors, If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Fix Shopify Crawl-Delay in robots.txt

🔍 What Is the Crawl-Delay Issue? If your Search Atlas dashboard is flagging a crawl-delay directive as a critical error in your robots.txt file, you are not alone. This is a common issue for Shopify store owners. Shopify automatically inserts a crawl-delay: 1 directive into every store's robots.txt file — and it cannot be removed or edited by the store owner. The directive looks like this inside your robots.txt file: - User-agent: * - Crawl-delay: 1 This means Shopify is instructing all bots to wait 1 second between each page request when crawling your site. While this protects server performance, it can slow down how quickly search engines index your content. ⚠️ Why Can't I Delete It? Shopify does not allow merchants to directly edit the robots.txt file in the same way a WordPress or custom-built site would. The platform generates this file automatically, and the crawl-delay line is hard-coded into Shopify's default template. Even if you use Shopify's robots.txt customisation feature (available on certain plans), fully removing the crawl-delay directive is not straightforward and depends on your Shopify plan and theme setup. This is a platform-level limitation, not a misconfiguration on your part. 📊 Does Crawl-Delay Actually Hurt My SEO? The impact depends on your site size and your crawl budget: - Small stores (under 500 pages): The 1-second crawl-delay is unlikely to cause meaningful indexing delays. Googlebot and other major crawlers often ignore or deprioritise this directive. - Large stores (500+ pages, frequent updates): A crawl-delay can slow down how quickly new or updated pages are discovered and indexed, which may affect time-sensitive content like product launches or price changes. - Google specifically: Google has publicly stated that Googlebot does not support the crawl-delay directive. However, other bots (Bingbot, and various third-party crawlers) do respect it. Search Atlas flags this as a critical error because it represents a technical SEO risk that should be reviewed — even if the real-world impact varies by site. 🛠️ What Can You Do About It? While you cannot fully remove the directive on standard Shopify plans, there are steps you can take to manage and mitigate the issue: 1. Verify the directive is present: Go to yourdomain.com/robots.txt in your browser and confirm the crawl-delay line exists. This helps you understand exactly what search engines are seeing. 2. Check your Shopify plan: Shopify Plus merchants have access to a liquid-based robots.txt template that allows more granular customisation. If you are on Shopify Plus, work with a developer to modify the robots.txt.liquid template and remove or override the crawl-delay directive. 3. Submit your sitemap manually: Compensate for slower crawling by ensuring your XML sitemap is submitted in Google Search Console and Bing Webmaster Tools. This gives search engines a direct map of your pages regardless of crawl speed. 4. Use Google Search Console's URL Inspection tool: For high-priority pages (new products, landing pages), use the Request Indexing feature in Google Search Console to prompt faster indexing without relying on a crawl. 5. Monitor crawl coverage regularly: Inside Search Atlas, use the OTTO SEO section (left sidebar → OTTO SEO → All Sites (SEO Automation)) to track crawl errors and indexing status over time. This helps you catch any pages that are falling behind on indexation. ✅ How to Mark This Error as Acknowledged in Search Atlas If you have reviewed the issue and determined the impact is low for your store size, you can acknowledge the error inside Search Atlas to keep your dashboard clean while you monitor the situation: 1. Navigate to the site audit section of your Search Atlas dashboard. 2. Locate the crawl-delay critical error in your robots.txt findings. 3. Review the recommendation details and confirm you have followed the mitigation steps above. 4. Use the available acknowledgement or dismiss option if your workflow allows for it, and add a note referencing this article for your records. Acknowledging the error does not fix the underlying directive, but it signals that your team is aware and has taken appropriate action given the platform constraints. 💡 Key Takeaways - The crawl-delay directive in Shopify robots.txt is added automatically by Shopify and cannot be removed on standard plans. - Google ignores the crawl-delay directive, but other bots respect it. - The real-world SEO impact is low for small stores but worth monitoring for large or frequently updated catalogues. - Shopify Plus merchants can customise the robots.txt.liquid file to remove the directive. - Submitting your sitemap and using URL inspection tools in Google Search Console are the best workarounds for all Shopify plans. If you need further assistance, open 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 Method 1: Check for Apps Injecting the Directive — third-party SEO/security apps (e.g. SEO Manager, Plug in SEO) may inject crawl-delay. Disable apps one at a time, check live robots.txt, or find crawl settings within the app and set value to 0. Wait 24–48 hours then re-crawl in Search Atlas.

🔍 Fix Yoast Noindex Settings After Search Atlas Import

🧭 Overview When you import your Yoast SEO data into the Search Atlas plugin, most settings transfer automatically. However, in some cases, pages that were previously set to noindex in Yoast may appear to lose that setting after the import. This article explains why this happens and how to fix it. ⚠️ Why This Happens The most common cause is a known issue with how Yoast stores advanced robots directives. Yoast saves these settings in a WordPress database field called _yoast_wpseo_meta-robots-adv. In some installations, this field contains an array instead of a plain text string. When Search Atlas runs its import process (import_yoast_indexation()), it expects this field to be a string. If it receives an array instead, the import step fails silently and the noindex directive is not applied in Search Atlas — leaving those pages indexable. This affects only the advanced robots directives (such as noindex applied via Yoast's Advanced tab per post or page). Standard on/off indexing controlled through Yoast's main SEO settings may import correctly. 🛠️ How to Fix Affected Pages Follow these steps to manually restore noindex settings for any pages that were affected after the import. 1. Identify affected pages: Review your site for pages that should be noindex. You can cross-reference your original Yoast settings or use a crawl tool to find pages that are now being indexed unexpectedly. 2. Open the Search Atlas plugin in WordPress: Log in to your WordPress admin dashboard and navigate to the Search Atlas plugin settings. 3. Go to the affected post or page: Open the individual post or page editor in WordPress. 4. Locate the Search Atlas SEO meta box: Scroll down to the Search Atlas SEO section below the content editor. 5. Set the robots directive to noindex: In the Search Atlas SEO Meta Box (MetaSync plugin), note that no Robots/No-Index control is available; only a Disable SEO Meta Box toggle exists. 6. Save the page: Click Update or Publish to save your changes. 7. Repeat for all affected pages: Go through each page that needs the noindex tag restored and apply the same steps. ✅ How to Verify the Fix After saving, confirm that the noindex tag is being applied correctly: - Visit the page in your browser and view the page source (right-click → View Page Source). - Search for noindex in the source code. You should see a meta tag such as: <meta name="robots" content="noindex"> - If your site uses the X-Robots-Tag HTTP header instead of a meta tag, use a tool like Google's URL Inspection tool or a browser extension to check response headers and confirm the noindex directive is present. 🔄 Re-Running the Import If you have a large number of affected pages, you may want to re-run the Yoast import from within the Search Atlas plugin after the underlying data issue is resolved. Before doing so: - Ensure your Search Atlas plugin is updated to the latest version, as a fix for this import bug has been released. - Back up your WordPress database before re-importing to avoid overwriting any settings you have already corrected manually. - After updating the plugin, navigate to the Search Atlas import settings and run the Yoast data import again. The updated import process handles non-string values in the robots field correctly. 🚫 A Note on X-Robots-Tag HTTP Headers If your site's noindex directives were set via the X-Robots-Tag HTTP header rather than a standard meta tag, these are managed at the server or plugin level and are separate from Yoast's per-post settings. Search Atlas does not currently raise a distinct warning when noindex is set only via this method. Check your server configuration or any additional plugin managing HTTP headers to ensure this directive is still active after your migration. 💡 Best Practices Going Forward - After any plugin migration or data import, audit your most important noindex pages to confirm directives are in place. - Keep the Search Atlas plugin updated to benefit from the latest import compatibility fixes. - Use Google Search Console's URL Inspection tool periodically to spot any pages that should not be indexed. 🙋 Need More Help? If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔧 Fix Google Search Console Country Connection Errors

Understanding the Error When connecting Google Search Console (GSC) to Search Atlas, you may encounter an error related to your GSC domain property not being accessible for the country selected during the connection setup. This is typically related to your GSC configuration or the country setting chosen in Search Atlas, rather than a bug within Search Atlas itself. Why This Happens This error can appear when there is a mismatch between your GSC property's available data and the country setting used during the connection in Search Atlas. GSC domain properties (sc-domain) may have limited or no data for certain countries, which can cause the connection to fail when a specific country is selected. Self-Serve Steps to Resolve 1. Try changing the country selection in Search Atlas. When setting up or reconnecting your GSC integration, select a different country — ideally the primary country where your site has indexed data in GSC. If you are unsure which country to select, choose the country where your site receives the most organic traffic. 2. Verify your GSC property exists and is verified. Log in to Google Search Console and confirm that the property you are trying to connect is listed and verified under the same Google account you use with Search Atlas. 3. Check that your GSC property has data for the selected country. In Google Search Console, go to Performance and filter by country to confirm that your property has indexed data for the country you are trying to use in Search Atlas. If no data exists for that country, select a country that does have data. 4. Reconnect your GSC integration. In Search Atlas, disconnect and reconnect your Google Search Console integration, then select the country confirmed in the previous step. 5. Allow time for new properties. If your GSC property was created recently, Google may not yet have sufficient data for country-level results. Wait a few days and try reconnecting. If the Issue Persists If you have followed the steps above and the connection still fails, please have the following ready when you contact our team: - Your Search Atlas project or site name - The GSC property identifier you are trying to connect - The country you selected during setup - The Google account email connected to Search Atlas - A screenshot of the error if possible If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Fix Shopify Mobile Menu After Script Install

🔍 What Is Happening and Why When you add the Search Atlas tracking script directly to your Shopify theme's theme.liquid file, it can interfere with how Shopify loads JavaScript for interactive elements like the mobile menu. Instead of rendering as a collapsible menu, the navigation may appear as plain, unstyled text. This happens because script placement affects the order in which the browser parses and executes JavaScript on the page. ⚠️ Before You Begin Always back up your theme before editing any liquid files. In your Shopify Admin, go to Online Store → Themes → Actions → Duplicate to create a safe copy. This ensures you can restore your site instantly if anything goes wrong. ✅ Step-by-Step Fix 1. Log in to your Shopify Admin and navigate to Online Store → Themes. 2. Next to your live theme, click Actions → Edit Code. 3. In the file list on the left, open Layout → theme.liquid. 4. Locate the Search Atlas script you previously added. It will look similar to a <script> tag containing your unique tracking ID. 5. Cut the script tag from its current position. 6. Scroll to the very bottom of the file and paste the script immediately before the closing </body> tag. Placing the script here ensures all page elements — including your mobile menu JavaScript — load fully before the tracking script runs. 7. Click Save. 8. Open your storefront on a mobile device or use your browser's mobile preview mode to confirm the menu is working correctly. 💡 Why Script Placement Matters Shopify themes rely on JavaScript to power dynamic components like mobile menus, drawers, and sliders. When an external script is placed inside the <head> tag or early in the <body>, it can block or conflict with the theme's own scripts as they load. Placing third-party scripts just before the closing </body> tag is a best practice that prevents these conflicts and keeps your store's functionality intact. 🚫 Common Mistakes to Avoid - Do not place the script inside the <head> tag. This is the most common cause of mobile menu breakage. - Do not add the script mid-way through the <body>. This can still interrupt theme JavaScript depending on your theme structure. - Do not add the script to section or snippet files. The script should only appear once, in theme.liquid, before the closing </body> tag. - Do not skip the backup step. Editing live theme code without a duplicate is risky. 🔄 If the Menu Is Still Broken After Moving the Script If repositioning the script does not resolve the issue, the problem may be related to your specific Shopify theme's JavaScript architecture. Try the following additional steps: - Open your browser's developer tools (right-click → Inspect → Console) and check for any JavaScript errors that appear when the page loads. Share these error messages with support if needed. - Temporarily remove the Search Atlas script entirely, save, and test the mobile menu. If the menu works without the script, the script is confirmed as the source of the conflict. - Check whether your theme uses a defer or async attribute on its own script tags. If so, try adding defer to the Search Atlas script tag as well: <script defer src="...">``</script>. 📋 Quick Reference — Correct Script Placement - Correct location: Immediately before </body> in theme.liquid - Incorrect location: Inside <head>, at the top of <body>, or inside any section or snippet file - One instance only: The script should appear exactly once across your theme 💬 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.

🛠️ Troubleshoot PR Distribution and CloudStacks Issues

🔍 Overview If you are experiencing issues with PR Distribution or CloudStacks in Search Atlas, this guide walks you through the most common problems and how to resolve them quickly. Follow the steps below before reaching out to support. ⚙️ Common PR Distribution Issues and Fixes PR Distribution allows you to publish and syndicate press releases across a network of sites. If something is not working as expected, try the following steps: 1. Check your submission status. Navigate to your PR Distribution dashboard and confirm whether your press release shows a status of Pending, Processing, or Failed. A Pending status means it is queued and will process shortly. 2. Review your content for compliance. Press releases that contain prohibited content, broken links, or formatting errors may be rejected. Re-read the content guidelines and ensure your release meets all requirements before resubmitting. 3. Verify your account credits or plan limits. Press release distribution draws from your shared Hyperdrive Credits (HDC) balance — if that balance is exhausted, new submissions will be blocked. Go to the Avatar Menu (👤) (Avatar Menu (👤), top-right) → Billing → Plans & Top-ups to check your current Hyperdrive Credits usage and balance. 4. Clear your browser cache and retry. Occasionally, stale cache data can cause submission forms to behave unexpectedly. Clear your cache, refresh the page, and attempt your submission again. 5. Check for platform status updates. If multiple submissions are failing at the same time, there may be a temporary service disruption. Check the Search Atlas status page or the in-app notification banner for updates. ☁️ Common CloudStacks Issues and Fixes CloudStacks is a powerful link-building feature that creates a network of cloud-based properties pointing to your target URLs. Here are the most common issues and how to address them: 1. Stack not building or stuck in progress. If your CloudStack has been stuck in the Building state for more than 24 hours, first check whether your target URL is accessible and returns a 200 status code. Broken or redirected URLs can stall the build process. 2. Properties not indexed. Newly created cloud properties can take several days to be indexed by search engines. This is normal behaviour. Allow 5–10 business days before expecting indexation results. 3. Incorrect target URL submitted. If you submitted the wrong URL for a CloudStack, contact support immediately. Depending on the build stage, the team may be able to update the target URL before the stack is fully deployed. 4. Stack shows as complete but links are not visible. Confirm you are viewing the correct project in your dashboard. Use the filter or search function to locate the specific stack by name or date created. If the stack report appears blank, try refreshing the page or switching browsers. 5. Duplicate stack submission. Submitting the same URL multiple times does not always improve results and may affect your link profile. Review your active stacks before creating a new one for the same target URL. 🔗 Issues Affecting Both PR Distribution and CloudStacks If you are experiencing problems with both features at the same time, the issue is likely related to one of the following: - Account or billing issue. A lapsed subscription or failed payment can restrict access to multiple features simultaneously. Go to the Avatar Menu (👤) (Avatar Menu (👤), top-right) → Billing to verify your subscription status and update your payment method if needed. - Browser or device compatibility. Both features require a modern browser. Ensure you are using the latest version of Chrome, Firefox, Edge, or Safari. Disable browser extensions that may interfere with the platform, such as ad blockers or script blockers. - Session or login issue. Log out of your Search Atlas account, clear your cookies, and log back in. This resolves many unexpected UI or submission errors. - API or integration conflict. If you are using the Search Atlas API or a third-party integration, verify that your API key is valid and that your requests are formatted correctly according to the latest API documentation. 📋 Before You Contact Support To help our team resolve your issue as quickly as possible, gather the following information before starting a chat: - The name or ID of the affected PR submission or CloudStack - The target URL associated with the issue - A description of what you expected to happen versus what actually happened - Any error messages you saw on screen - The date and time you first noticed the issue 💬 Still Need Help? If the steps above did not resolve your issue, our support team is ready to assist. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔧 Fix Stuck OTTO Site Audit Scans

Overview If your OTTO Site Audit scan has been processing for an extended period without completing — especially on SiteGround hosting — a server-level cache conflict may be preventing the crawler from finishing its work. This article explains the general cause and what steps you can take, and what to have ready if you need to escalate to our team. Why Scans May Get Stuck on SiteGround SiteGround includes a built-in caching system that can interfere with OTTO's crawler by serving cached page responses instead of live content. This can cause the scan to receive incomplete or inconsistent data, leading to the crawl stalling rather than finishing or failing cleanly. Other hosting environments that apply aggressive server-side caching may exhibit similar symptoms. Step 1 — Clear Your SiteGround Cache Before retrying your OTTO scan, clear any active caches through your SiteGround hosting controls or any SiteGround-related caching plugin installed on your WordPress site. The exact steps will depend on the tools your hosting setup uses. In general: - Log in to your WordPress admin dashboard. - Locate any caching plugin or hosting-level cache management tool provided by SiteGround. - Clear or purge all cached content. - If your setup allows it, temporarily disable server-side caching while the OTTO scan runs. - Save any changes before proceeding. If you are unsure how to manage caching for your specific SiteGround configuration, consult SiteGround's official support documentation or contact their support team for guidance. Step 2 — Retry Your OTTO Site Audit Scan After clearing your cache, return to Search Atlas and attempt to start a new OTTO Site Audit scan for your connected website. If a previous scan is still showing as active or stuck, wait for it to time out or contact our team to have it cleared on the backend before starting a fresh crawl. Step 3 — Re-Enable Caching After the Scan Completes Once your scan has completed successfully, re-enable any caching you disabled in Step 1 to restore normal site performance for your visitors. If the Scan Remains Stuck If your OTTO Site Audit scan continues to stall after clearing your cache and retrying, our support team can investigate on the backend. To help us resolve this as quickly as possible, please have the following ready when you reach out: - The domain or project name connected to the stuck scan. - The approximate time the scan was started and how long it has been stuck. - Your hosting provider and any caching plugins currently active on your site. - Any error messages or unusual statuses visible on your OTTO dashboard. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 Why Site Audit Isn't Crawling All Pages

🧭 Overview Search Atlas Site Audit crawls your website by following the URLs listed in your XML sitemap. If your sitemap does not include all of your pages, Search Atlas will only crawl the pages it can find there — even if those pages exist on your live site and are accessible to other tools. This is the most common reason customers see a lower crawled page count than expected. 📋 How Search Atlas Discovers Pages Unlike some crawlers that spider every link on a page, Search Atlas primarily relies on your submitted XML sitemap to discover and audit pages. This means: - Pages listed in your sitemap will be crawled and audited. - Pages not listed in your sitemap will be skipped, even if they are live and indexable. - A third-party tool that crawls by following internal links may report a higher page count simply because it uses a different discovery method. If you have 500+ pages on your site but only 114 appear in your sitemap, Search Atlas will audit approximately 114 pages — not 500+. ✅ Step 1 — Check How Many URLs Are in Your Sitemap Before investigating anything else, verify your sitemap is complete: 1. Open your sitemap directly in a browser. The most common location is yourdomain.com/sitemap.xml. 2. Count the total number of <url> entries, or use a free sitemap checker tool to get an accurate count. 3. Compare that number to the total number of pages you expect to be crawled. 4. If the sitemap count is significantly lower than your total page count, your sitemap is incomplete — this is the root cause. 🛠️ Step 2 — Fix an Incomplete Sitemap If your sitemap is missing pages, you need to regenerate or update it so all intended pages are included. How you do this depends on your platform: - WordPress: Use an SEO plugin such as Yoast SEO, Rank Math, or All in One SEO. Navigate to the plugin's sitemap settings and ensure all post types, pages, and taxonomies you want crawled are enabled. Save and regenerate the sitemap. - Shopify: Shopify generates a sitemap automatically. If products or pages are missing, confirm they are published and not set to hidden. - Custom or headless sites: Work with your developer to ensure your sitemap generation script includes all relevant URLs and is not filtering out pages unintentionally. - Large sites with sitemap indexes: If your site has more than 50,000 URLs, you may need a sitemap index file that references multiple individual sitemaps. Confirm all child sitemaps are linked from the index. After updating your sitemap, re-submit it in Google Search Console under Sitemaps to keep your data consistent across tools. 🔄 Step 3 — Re-Submit Your Sitemap in Search Atlas Once your sitemap is updated and includes all the pages you want audited, re-run your Site Audit in Search Atlas: 1. Navigate to your project in Search Atlas. 2. Open Site Audit and locate the sitemap or crawl settings for your project. 3. Confirm the correct sitemap URL is entered. If you have updated the sitemap URL or added a sitemap index, update this field accordingly. 4. Start a new crawl and wait for it to complete. 5. Verify the crawled page count now matches the number of URLs in your updated sitemap. ⚠️ Other Reasons Pages May Be Missing If your sitemap is complete but pages are still not appearing in your crawl results, check the following secondary causes: - Noindex tags: Pages with a <meta name="robots" content="noindex"> tag or an X-Robots-Tag: noindex HTTP header may be excluded from audit results intentionally. - robots.txt blocks: Open yourdomain.com/robots.txt and confirm that the Search Atlas crawler or the Disallow rules are not blocking sections of your site. - Canonical tags pointing elsewhere: Pages with a canonical tag pointing to a different URL may be treated as duplicates and consolidated in your results. - Crawl limits on your plan: Some Search Atlas plans include a maximum number of pages per crawl. If your site exceeds this limit, upgrade your plan or prioritise the most important sections of your sitemap. - Sitemap URL not reachable: Confirm your sitemap returns a 200 HTTP status and is not behind a login, password protection, or firewall that blocks crawlers. 🔑 Quick Checklist - Sitemap URL is accessible at a public address (no login required). - Sitemap contains all pages you want audited — count the <url> entries. - No unintended noindex tags or robots.txt blocks are in place. - Correct sitemap URL is entered in your Search Atlas project settings. - A fresh crawl has been started after any sitemap changes. 💬 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 Non-Indexable Pages Caused by Canonical Mismatches

🧭 Overview If your homepage or any other page shows as non-indexable in Site Audit despite having no noindex tag, being listed in your XML sitemap, and appearing unblocked in your robots.txt file, the root cause is often a canonical URL mismatch. This is one of the most frequently missed causes of false non-indexable flags, and it can be resolved quickly once identified. 🤔 What Is a Canonical URL Mismatch? A canonical tag tells search engines which version of a URL is the authoritative, preferred version of a page. When the canonical URL declared on a page does not exactly match the URL that Site Audit is crawling, the tool correctly flags the crawled version as non-indexable — because it is effectively deferring indexing authority to a different URL. Common mismatches include: - Trailing slash differences: The page is crawled as example.com/ but the canonical tag points to example.com (or vice versa). - HTTP vs. HTTPS: The canonical specifies http:// while the live page serves over https://. - WWW vs. non-WWW: The canonical uses www.example.com but the crawled URL is example.com. - URL parameter inconsistencies: The canonical omits or includes query parameters that appear in the crawled URL. - Uppercase vs. lowercase characters: A mismatch in letter casing between the canonical and the crawled URL. Even a single character difference between the crawled URL and the declared canonical is enough to trigger a non-indexable flag in Site Audit. 🔎 How to Identify a Canonical Mismatch in Site Audit 1. Go to OTTO SEO → Site Audit in the left sidebar of your Search Atlas dashboard. 2. Open your most recent crawl report and navigate to the Indexability section. 3. Click on the affected page (for example, your homepage) to open its detail panel. 4. Look for the Canonical URL field in the page details. Compare the value shown there against the exact URL that was crawled (displayed at the top of the detail panel). 5. Check whether the two URLs are identical, character for character, including protocol, subdomain, trailing slash, and casing. If the canonical URL and the crawled URL do not match exactly, you have found your issue. 🛠️ How to Fix a Canonical URL Mismatch Once you have identified the mismatch, choose the fix that applies to your situation: - Trailing slash: Decide on one consistent format (with or without trailing slash) and update either your canonical tag or your server redirect so both URLs resolve to and declare the same preferred version. - HTTP vs. HTTPS: Update your canonical tags to use https:// on all pages and ensure your server redirects all HTTP traffic to HTTPS. - WWW vs. non-WWW: Pick one version as your canonical domain, set up a 301 redirect from the other, and make sure all canonical tags reflect your chosen version. - URL parameters: If parameters are irrelevant to page content, strip them from your canonical tags or configure parameter handling in Google Search Console. - Casing issues: Update your canonical tags or configure server-level redirects so all URLs are consistently lowercase. After making changes, re-crawl your site in Site Audit to confirm the mismatch has been resolved and the page is now flagged as indexable. ✅ How to Re-Crawl and Verify the Fix 1. In the left sidebar, select OTTO SEO → Site Audit. 2. Open your project and click Re-crawl or Start New Crawl. 3. Once the crawl completes, return to the Indexability section. 4. Confirm the previously flagged page no longer appears in the non-indexable list. 5. In the page detail panel, verify the Canonical URL field now matches the crawled URL exactly. ⚠️ Other Common Causes of Non-Indexable Flags If fixing your canonical tag does not resolve the issue, also check for these additional causes: - A noindex directive in the page's <meta robots> tag or HTTP response header. - The page being blocked in your robots.txt file. - JavaScript-rendered content that prevents the crawler from reading the page's canonical tag correctly. - The page returning a non-200 HTTP status code such as a redirect chain or server error. 💬 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 the 'No Website Found' Error

🧭 Overview When you try to add a website to Search Atlas and see a no website found error, it usually means Search Atlas cannot discover or verify the domain. This can happen for several reasons, from how the URL is entered to deeper issues with the domain's DNS, indexing status, or account configuration. This article walks you through a structured diagnostic process so you can identify and fix the root cause quickly. ⚠️ Common Causes of This Error - The URL is entered in an unsupported or incorrect format - The domain is not indexed by search engines - The domain has DNS configuration issues or does not resolve correctly - The website is behind a login wall, firewall, or robots.txt block - The subdomain is not recognised as a standalone trackable property - An account-level restriction is preventing site discovery ✅ Step 1: Check Your URL Format Search Atlas requires a specific URL format when adding a website. Before investigating deeper issues, confirm you are entering the URL correctly. 1. Use only the root domain or subdomain without a trailing slash. For example, enter bloomington.alloypersonaltraining.com rather than https://bloomington.alloypersonaltraining.com/. 2. Try removing the https:// or http:// prefix if you have included it. 3. If the site uses www, try both the www and non-www versions to see which is accepted. 4. If you are adding a subdomain, enter the full subdomain exactly as it appears in the browser address bar. 🌐 Step 2: Verify the Domain Resolves Publicly Search Atlas must be able to reach the domain over the public internet. If the domain does not resolve, no URL format will work. 1. Open a private or incognito browser window and navigate to the full URL of the website. 2. Confirm the site loads without redirects to an error page, login screen, or maintenance notice. 3. Use a free DNS lookup tool such as dnschecker.org and enter the domain. Check that DNS records (A record or CNAME) are present and propagated globally. 4. If the domain does not load publicly or DNS records are missing, the domain must be correctly configured before it can be added to Search Atlas. Contact your domain registrar or hosting provider to resolve DNS issues. 🔎 Step 3: Check Search Engine Indexability Search Atlas relies on search engine data to verify and populate website information. If the domain is not indexed, it cannot be discovered. 1. Open Google and search for site:bloomington.alloypersonaltraining.com (replace with your domain). 2. If no results appear, the domain may not be indexed by Google. This is a common cause of the no website found error. 3. Check the site's robots.txt file by navigating to yourdomain.com/robots.txt. If it contains Disallow: / or blocks all crawlers, search engines and Search Atlas cannot access the site. 4. If the domain is a newly registered or recently launched website, it may simply not have been crawled yet. Allow time for indexing and try adding it again after a few days. 🔒 Step 4: Check for Access Restrictions Some websites restrict access in ways that prevent Search Atlas from discovering them. - Password protection: If the site requires a login to access any pages, Search Atlas cannot verify it. Temporarily remove password protection and retry. - Firewall or IP blocking: Some hosting environments block bot traffic. Confirm that the site is accessible to crawlers by checking your hosting or CDN settings. - Cloudflare or security layers: If the domain is protected by Cloudflare or a similar service, bot challenges may block discovery. Review your security settings to allow legitimate crawlers. 🏷️ Step 5: Confirm Subdomain Handling Subdomains like bloomington.alloypersonaltraining.com are treated as separate properties from the root domain. If you are trying to track a subdomain, keep the following in mind. - Enter the full subdomain exactly as it appears, for example bloomington.alloypersonaltraining.com, not just alloypersonaltraining.com. - The subdomain must independently resolve and be publicly accessible. A subdomain that redirects to the root domain or returns a 404 error cannot be added. - Confirm the subdomain has its own content and is not simply an alias or redirect. 🛠️ Step 6: Try Adding the Website Again After working through the checks above, attempt to add the website to Search Atlas again. 1. Log in to Search Atlas and go to the Home page. 2. Select Create Project to start a new project or attempt to add a website to an existing project. 3. Enter the domain in the correct format based on what you confirmed in Step 1. 4. If the error persists after completing all checks above, take note of the exact domain you entered and the steps you have already tried. 💬 Still Seeing the Error? If you have completed all the steps above and the no website found error continues to appear, the issue may be related to an account-level restriction or a backend configuration that requires investigation by our team. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔧 Fix Site Audit Report Quota Limit Errors

Overview When generating reports in Site Audit, you may see an error indicating you have hit a quota limit. This article explains what this error means and what to do next. What Is a Quota Limit Error in Site Audit? A quota limit error in Site Audit indicates that your account has reached a usage limit associated with your current subscription plan. This may involve your plan's overall report or crawl allowances, or your AI credit balance. Once a limit is reached, new report requests may be blocked until the limit is addressed. What to Do When You See This Error Because quota limit errors can relate to different parts of your account — such as AI credits or plan-level crawl and report allowances — the exact resolution depends on your specific situation. A support agent can review your account directly, identify which limit has been reached, and advise on the correct next steps, such as adjusting your plan or credit balance. What to Have Ready When You Contact Support To help the team resolve your issue as quickly as possible, please have the following information ready before reaching out: - Your account email address associated with the Search Atlas subscription. - The name of the Site Audit project where the error occurred. - The exact error message displayed when the quota limit error appeared. - The date and approximate time when you first encountered the error. - Any recent changes to your plan, usage, or billing that may be relevant. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 GSC Performance View Sites Not Loading Fix

🧭 Overview If your sites are not loading or GSC data is missing in the GSC Performance section of Search Atlas, this is a known issue that our support team can investigate and resolve on your behalf. Because the root cause may involve your specific GSC connection, account configuration, or a backend data sync problem, the most reliable path to resolution is to contact our team directly. What to Have Ready Before Contacting Support To help our team investigate as quickly as possible, please have the following information ready when you reach out: - The project name or workspace where the GSC Performance view is not loading - The exact site or property URL you expect to see data for - A description of what you see — for example, whether the section is blank, shows an error message, or shows some sites but not others - The exact error message (if any) displayed on screen - The timestamp (date and approximate time) when you first noticed the issue - The Google account used to connect your GSC integration What Our Team Will Do Once you contact support, a member of our team will review your GSC connection status and data sync on the backend and work to restore your site data in the GSC Performance view. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔧 Fix Cloudflare Blocking Your Shopify Site Audit

🧭 Overview If your Site Audit crawl has been running for an extended period with little or no progress, your site is likely stalled, not just slow. On Shopify stores, a common cause is Cloudflare blocking Search Atlas crawl requests before they reach your site. This article helps you confirm the root cause and take the right next steps. ⚠️ Slow Crawl vs. Stalled Crawl: Know the Difference - Slow crawl (normal): Pages are being discovered and audited gradually. Progress increments over time. Large sites with many pages can take several days. - Stalled crawl (problem): The crawl shows little or no progress over an extended period. The page count stays frozen or advances by only a handful of pages per day. This is a blocking issue, not a size issue. If your crawl has been running for a prolonged period with minimal progress, proceed through the steps below in order. Do not skip to sitemap fixes — if Cloudflare is blocking the crawler, sitemap changes will have no effect. 🔍 Step 1: Confirm Cloudflare Is Active on Your Shopify Store 1. Visit your Shopify store URL and open your browser's developer tools (F12 → Network tab). 2. Look for response headers containing cf-ray or server: cloudflare. If present, Cloudflare is active on your domain. 3. Alternatively, check your DNS or hosting settings to confirm whether your domain is proxied through Cloudflare. If Cloudflare is confirmed active, continue to Step 2 before doing anything else. 🛡️ Step 2: Configure Cloudflare to Allow Search Atlas Crawler Requests Cloudflare's bot protection and firewall rules can silently block automated crawlers, returning errors or empty responses that stall your audit. You will need to configure Cloudflare to allow the Search Atlas crawler through. 1. Log in to your Cloudflare account and select your domain. 2. Review your active security and bot-protection rules to identify any that may be blocking or challenging automated crawl requests. 3. Contact our support team to obtain the current list of Search Atlas crawler IPs and guidance on how to create the appropriate allow rules for your specific Cloudflare configuration. 4. Once the rules are in place, return to Search Atlas and restart your Site Audit crawl to verify that progress resumes. 📋 What to Have Ready When Contacting Support If you are unsure which settings to change, or if the crawl remains stalled after reviewing your Cloudflare configuration, please have the following information ready so our team can assist you efficiently: - Your project name in Search Atlas - Your Shopify store URL - Confirmation that Cloudflare is active on the domain (e.g., cf-ray header present) - A description of how long the crawl has been stalled and approximately how many pages have been audited - Any error messages or unusual response codes you have observed If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

✅ Site Audit Issues Page Blank Screen in Firefox (Resolved)

If the Site Audit Issues page shows a blank screen in Firefox, switch to Chrome, Edge, or Safari to access it immediately. This was a Firefox-specific rendering bug (engineering ticket SPE-770) that has been fixed and deployed to production. ⚠️ What the Issue Looks Like When using Firefox, the Site Audit Issues page renders as a completely blank screen with no error message or error code displayed. No audit data loads and no feedback appears on screen. All other supported browsers load the page correctly. 💡 Immediate Workaround Open the Site Audit Issues page in any of the following browsers instead of Firefox: - Google Chrome - Microsoft Edge - Safari (macOS only) The page loads fully in all three browsers with no loss of functionality or data. 📋 Fix Status Search Atlas engineering replicated and confirmed this as a Firefox-specific rendering defect, logged it as ticket SPE-770, and deployed a fix to production. If you were previously affected, the issue should now be resolved when using Firefox. As part of the same engineering effort, the Issues page was also upgraded with a new data layer (React Query migration, ticket OTTO-2115), which improved overall reliability and loading behaviour. Affected-pages search and filter behaviour on the Issues page was also corrected as part of this work — if you notice any differences in how the page loads or how search and filters behave, this is expected and reflects these improvements. 🛠️ If the Blank Screen Still Appears in Firefox If the Site Audit Issues page still shows a blank screen in Firefox after the fix, follow these steps: 1. Open the Firefox menu and go to Settings → Privacy & Security → Cookies and Site Data → Clear Data. 2. Reload the Site Audit Issues page. 3. If the blank screen persists, contact Search Atlas support and include your Firefox version number and a screenshot of the blank page. 🌀 You can now access the Site Audit Issues page without interruption in Firefox after the deployed fix. If the issue reappears, contact Search Atlas support with your Firefox version and a screenshot so the team can investigate.

🔍 Fix Instant Indexing Queue Stuck Issues

🗺️ Overview Search Atlas offers two distinct indexing features, and it is important to know which one you are using before troubleshooting a stuck queue. This article explains the difference between Instant Indexing and Dynamic Indexing, and walks you through what to check when URLs remain stuck in Indexing request pending status with no quota consumption. ⚡ Instant Indexing vs. Dynamic Indexing: Key Differences These are two separate features. Confusing them is one of the most common reasons customers troubleshoot the wrong tool. - Instant Indexing — Submits URLs directly to Google via the Google Indexing API. It is designed for JobPosting and BroadcastEvent structured data pages, but many users apply it broadly to accelerate Google crawling. Quota is consumed per successful API call. - Dynamic Indexing — A Search Atlas automation layer that monitors your sitemap for new or updated URLs and triggers indexing requests on a schedule. It works alongside Instant Indexing but is a separate workflow. Important correction: Instant Indexing is a Google feature. It has no connection to Bing. If you have seen guidance suggesting otherwise, please disregard it. 🚩 What a Stuck Queue Actually Looks Like A queue is considered stuck when all of the following are true for more than 24 hours: - One or more URLs show the status Indexing request pending. - Your quota counter has not decreased since the requests were submitted. - No error messages or rejection notices appear in the Instant Indexing log. If only some URLs are pending but quota is being consumed normally, that is expected queuing behaviour and not a backend issue. The situation described above — zero quota movement over 24 hours or more — indicates a backend dispatch problem that cannot be resolved by switching to a different feature or running a manual reprocess. 🔎 Common Root Causes - Dispatch job not running — The internal job that sends queued requests to the Google Indexing API may have stalled. This is a backend issue only the Search Atlas engineering team can resolve. - Service account permission error — The Google service account connected to your property may have lost Owner-level access in Google Search Console, causing every API call to fail silently before it is dispatched. - Google API quota exhausted at account level — If you share a service account across multiple properties, the daily 200-URL Google API limit may be consumed before your requests are processed. - Service account JSON credentials expired or revoked — Credentials uploaded during initial setup can become invalid if the Google Cloud project settings have changed or the service account was modified. 📋 What to Have Ready When Escalating Because a stuck dispatch queue requires backend investigation, please have the following information ready before contacting support: - Your project name and the property URL affected. - The exact URLs that are stuck in Indexing request pending status. - The date and time when the requests were first submitted. - A confirmation of whether your quota counter has moved at all since submission. - Any error messages visible in your Instant Indexing log, copied exactly as they appear. If you need further assistance, open 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 Domain Migration and Project Creation Errors

🗺️ Overview When migrating a website from one domain version to another — for example, from www.ideation-digital.com to ideation-digital.com — you may run into two common issues in Search Atlas: DNS or redirect conflicts between domain variants, and a 'website exists' error when trying to create a new project. This article walks you through both problems and how to resolve them. 🔍 Understanding Domain Variants Search Atlas treats different versions of a domain as distinct entries. The following are all considered separate domains: - www.ideation-digital.com (www version) - ideation-digital.com (non-www version) - http://ideation-digital.com (non-secure) - https://ideation-digital.com (secure) If your website redirects from one version to another (for example, www redirects to non-www), Search Atlas needs to track the canonical version — the final destination URL that your server resolves to. Using the wrong variant as your project domain is the most common cause of data discrepancies and project creation errors. ✅ Step 1 — Identify Your Canonical Domain Before making any changes in Search Atlas, confirm which domain version your site actually uses: 1. Open a browser and type your domain with the www prefix (e.g., www.ideation-digital.com). 2. Watch the address bar after the page loads. If the URL changes to ideation-digital.com (without www), that is your canonical domain. 3. You can also use a redirect-checking tool such as httpstatus.io to trace the full redirect chain and confirm the final URL. Make a note of the exact canonical domain — including whether it uses http or https — before proceeding. ⚙️ Step 2 — Update Your Existing Project Domain If you already have a project set up with the wrong domain variant, update it rather than deleting and recreating it. This preserves your historical data. 1. In the left sidebar, click Site Metrics. 2. Locate your existing project in the list. 3. Click the settings or edit icon next to the project. 4. Update the domain field to your canonical domain (e.g., change www.ideation-digital.com to ideation-digital.com). 5. Save the changes. Search Atlas will begin pulling data for the updated domain. Allow up to 24 hours for metrics to refresh fully. 🚫 Step 3 — Resolve the 'Website Exists' Error If you try to create a new project and see a 'website exists' error, it means a project using that domain (or a variant of it) is already registered in your account — or in another account on the platform. Here is how to resolve it: 1. Go to Left sidebar → Site Metrics and review your full project list. 2. Look for any project using the same domain, including www and non-www versions, or http and https versions. 3. If you find a duplicate project you no longer need, delete it first, then try creating the new project again. 4. If you do not see a duplicate but the error persists, the domain may be registered under a different workspace or account. Check any other Search Atlas accounts you have access to. 5. Once the conflicting project is removed, create your new project using the confirmed canonical domain from Step 1. 💡 Best Practices for Domain Setup - Always use the final redirect destination as your project domain — not the version that redirects away. - Use https if your site has an SSL certificate (most modern sites do). - Avoid creating multiple projects for the same domain. Update the existing project instead. - If you are migrating to a completely new domain (e.g., from old-brand.com to new-brand.com), create a fresh project for the new domain and archive or delete the old one. 🛠️ Still Seeing Issues? If you have followed all the steps above and are still unable to update your domain or create a project, there may be a platform-level conflict that requires manual review. If you need further assistance, open 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 Integration Errors and Site Metrics Crawling

🔍 Overview If OTTO is showing an integration error on your website, or if Site Explorer is not crawling your domain correctly, this guide walks you through the most common causes and how to fix them quickly. Most issues can be resolved in just a few steps without needing to contact support. ⚠️ Common Causes of OTTO Integration Errors Before troubleshooting, it helps to understand why the error may be occurring. The most frequent causes include: - Incorrect website URL: The domain added to OTTO does not exactly match the live site URL (e.g., missing www or using http instead of https). - OTTO code not installed: The OTTO snippet has not been placed correctly on your website. - Crawl not yet completed: Site Explorer needs time to finish its initial crawl before data appears. - Domain verification failure: Search Atlas cannot confirm ownership or access to the domain. - Site access restrictions: Password protection, firewall rules, or bot-blocking settings may be preventing the crawler from reaching your site. 🛠️ Step 1 — Check Your OTTO Integration Setup 1. In the left sidebar, click OTTO SEO, then open SEO Automation (URL: /seo-automation-v3). 2. Locate the website showing the integration error and click into its OTTO dashboard. 3. Verify that the domain listed matches your live website URL exactly, including the correct protocol (https://) and subdomain (www or non-www). 4. If the URL is incorrect, remove the site and re-add it using the exact URL format your website uses. 💡 Step 2 — Confirm the OTTO Snippet Is Installed 1. Inside the OTTO dashboard for your site, locate the integration code snippet provided by Search Atlas. 2. Confirm that this snippet has been added to every page of your website, ideally in the <head> section of your site template. 3. If you are using a CMS such as WordPress, verify the snippet was not removed during a recent theme update or plugin change. 4. After confirming the snippet is in place, click Verify Integration (if available) or allow up to 24 hours for the system to re-detect it automatically. 📊 Step 3 — Check Site Explorer Crawl Status 1. In the left sidebar, click Site Metrics → Site Explorer (URL: /site-explorer/list). 2. Find your domain in the list and check its crawl status. 3. If the crawl is shown as In Progress, wait for it to complete — initial crawls can take up to 24 hours depending on site size. 4. If the crawl shows an error or has been stuck for more than 24 hours, remove the domain from Site Explorer and re-add it to trigger a fresh crawl. 🔒 Step 4 — Remove Site Access Restrictions If your website has any of the following in place, the OTTO crawler and Site Explorer crawler may be blocked: - Password-protected pages or staging environments - Cloudflare or similar CDN bot-protection rules blocking crawlers - robots.txt rules that disallow all bots - Firewall or security plugin settings that block unrecognised user agents Temporarily disable these restrictions, trigger a new crawl, then re-enable them once the integration is confirmed. If you need to whitelist the Search Atlas crawler specifically, contact our team via the chat widget for the current crawler IP addresses and user agent details. 🔄 Step 5 — Re-Trigger the Integration Check 1. After completing the steps above, return to OTTO SEO in the left sidebar and open SEO Automation. 2. Open the affected site's OTTO dashboard. 3. Look for a Retry or Re-check Integration option and click it. 4. Allow up to 30 minutes for the system to confirm the integration. Refresh the page after this period to see the updated status. ✅ When Everything Is Working Once the integration is active and the crawl has completed, you will see: - A green connected status on the OTTO dashboard under OTTO SEO. - Populated site data and recommendations inside OTTO. - Crawl results visible under Site Explorer, with sub-sections such as Keyword Magic, Rank Tracker, and Keyword Gap showing data for your domain. 💬 Still Seeing an Error? If you have followed all the steps above and the integration error or crawling issue persists, our support team is ready to investigate further. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🤖 OTTO Crawler Robot Challenges and 202 Status Codes

🔍 Overview If you have deployed title tags or meta descriptions through OTTO and they appear to revert without any action on your part, the most likely cause is that the affected pages are returning a 202 status code instead of a standard 200 OK response. A 202 status means the server has accepted the request but has not yet finished processing the page. OTTO cannot fully crawl or confirm fixes on pages in this state. ⚙️ What Is a 202 Status Code? HTTP status codes tell crawlers how a server responded to a request: - 200 OK — The page loaded successfully and is fully crawlable. - 202 Accepted — The server received the request but the page is still being processed. The content is not yet in its final state. When OTTO encounters a 202 response, the page is not considered crawlable or indexable. As a result, OTTO cannot verify that your deployed fixes are live, and the dashboard may show those pages as unresolved or appear to show the original, unfixed metadata. 🤖 What Is a Robot Challenge Screen? A robot challenge screen is a security layer — commonly served by tools like Cloudflare — that presents an automated browser check before allowing access to a page. When OTTO's crawler encounters this challenge, it cannot read the page content and receives a non-200 response (such as a 202) instead of the finished HTML. This prevents OTTO from confirming or reading your deployed SEO changes. 🛠️ How to Diagnose the Problem 1. Identify which pages appear to have reverted titles or meta descriptions after deployment. 2. For each affected page, manually check the HTTP status code. You can do this by opening your browser's developer tools, going to the Network tab, and reloading the page — look for the status code shown next to the page URL. Alternatively, use a free online HTTP status checker by pasting in the page URL. 3. If a page returns 202, the page is still processing or is behind a bot-challenge screen. OTTO will not be able to confirm fixes on that page until it returns a 200 OK. 4. If a page returns 200 OK, OTTO should be correctly reading and displaying your deployed changes. If fixes still appear missing on 200-status pages, proceed to request a recrawl (see below). ✅ What You Can Do - Wait for processing to complete. If your pages are genuinely still loading or being built server-side, wait and check the status code again after some time. Once the page returns 200 OK, OTTO will be able to crawl and confirm your fixes. - Check your site's bot-protection settings. If your hosting provider or CDN (such as Cloudflare) has bot-fight or challenge modes enabled, these can block legitimate crawlers including OTTO. Review your security settings and, if safe to do so, configure exceptions to allow automated crawlers access to your pages. - Trigger a recrawl in OTTO. Once affected pages are returning 200 OK responses, initiate a recrawl from within the OTTO section of the platform so that OTTO can re-read and confirm your deployed fixes. - Do not redeploy unnecessarily. Redeploying fixes to pages still returning 202 responses will not resolve the underlying issue and may cause confusion. Wait until the pages are fully accessible before redeploying. 📊 Pages With 200 OK Status For any pages that are already returning a 200 OK status code, OTTO should be correctly displaying your original deployed titles and meta descriptions. If you notice discrepancies on those pages specifically, this may be a separate caching or deployment issue rather than a crawl-access problem. 💡 Additional Context This issue is most common on sites hosted on platforms with aggressive bot-protection enabled, or on pages that use server-side rendering with delayed processing. The root cause is always that OTTO cannot access the final, rendered version of the page — not that your SEO changes have been lost. Your deployed changes remain intact; OTTO simply cannot confirm them until the page is crawlable. 🆘 Still Need Help? If you have verified that your pages are returning 200 OK responses and your fixes are still not being reflected, or if you are unsure how to adjust your bot-protection settings, If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Fix Site Audit Projects Locked by OTTO

🔍 Overview If you are trying to delete a Site Audit project — such as canary or armbarmarketing — and the option is greyed out or unavailable, the most common cause is an active OTTO pixel linkage. Even if you are not actively using OTTO on that site, the pixel connection still ties the project to OTTO SEO and prevents deletion. This article explains why this happens and walks you through the steps to resolve it. ⚙️ Why OTTO Pixel Linkage Blocks Deletion Search Atlas links each Site Audit project to OTTO SEO when the OTTO pixel is deployed on that domain. This connection allows OTTO to continuously read site data and push optimisations. Because the two tools share a live data relationship, the platform protects the Site Audit project from accidental deletion while that link is in place — even if OTTO is not actively running tasks on the site. This means you cannot delete the Site Audit project directly. You must disconnect the OTTO pixel first, which breaks the linkage and makes the project deletable. 🚀 How to Disconnect the OTTO Pixel 1. In the left sidebar, click OTTO SEO, then open SEO Automation (URL: /seo-automation-v3). 2. Locate the site you want to unlink — for example, canary or armbarmarketing. 3. Open the site's OTTO settings and find the pixel or domain connection option. 4. Select Disconnect or Remove Pixel to sever the link between OTTO and the Site Audit project. 5. Confirm the disconnection when prompted. Once the pixel is disconnected, return to Site Audit and the delete option for that project will become available. 🗑️ How to Delete the Site Audit Project 1. Navigate to Site Metrics → Site Explorer (Site Explorer) in the left sidebar (URL: /site-explorer/list). 2. Locate the project you want to remove from the list. 3. Click the three-dot menu or settings icon next to the project name. 4. Select Delete Project and confirm your choice. The project will be permanently removed and that slot will immediately count toward your available capacity. 📊 Understanding the 5-Project Cap Search Atlas allows a maximum of 5 active Site Audit projects per account on standard plans. Each project — whether actively crawling or idle — occupies one slot. Projects with an OTTO pixel linkage cannot be deleted without first disconnecting OTTO, which is why customers sometimes find themselves stuck at the cap with projects they no longer need. To free up slots quickly, follow this order: - Step 1: Identify all projects you no longer need by reviewing your project list in Site Explorer. - Step 2: For each unwanted project, check whether it has an OTTO pixel connected via the OTTO SEO V3 section. - Step 3: Disconnect any active OTTO pixel links before attempting deletion. - Step 4: Delete the project from Site Explorer once the link is cleared. 💡 Tips to Avoid This Issue in Future - When you stop using OTTO on a domain, disconnect the pixel immediately rather than leaving the linkage in place. - Before adding a new Site Audit project, audit your existing projects to confirm all slots are in active use. - If you manage client sites that have ended, remove their OTTO connections as part of your offboarding process. 🆘 Still Need Help? If you have followed the steps above and are still unable to delete a project, or if the disconnect option is not appearing as expected, our team is ready to assist. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔄 Fix Page Indexability Status Constantly Flipping

🧭 Overview If a page in Search Atlas repeatedly flips between Indexable and Not Indexable status, this usually points to an unstable technical configuration on the page itself — not a bug in the platform. Search Atlas reflects the live state of your page each time it crawls, so if the underlying signals are inconsistent, the reported status will be too. This article walks you through the most common causes and how to fix them. 🔍 Where to Find Indexability Status You can review and monitor your page's indexability status inside the On-Page Audit tool: 1. In the left sidebar, click Content. 2. Select On-Page Audit. 3. Enter or select the URL you want to investigate. 4. Review the Indexability field in the audit results. Run the audit on two separate occasions a few hours apart. If the status changes between runs, one or more of the issues below is likely the cause. ⚠️ Common Causes of Indexability Flipping 1. 🏷️ Inconsistent Robots Meta Tag A page may serve a noindex directive to crawlers under certain conditions — for example, when a user is not logged in, when A/B testing is active, or when a caching layer serves a different version of the page. To investigate: - Fetch the page directly in a browser while logged out and inspect the <meta name="robots"> tag in the page source. - Use Google Search Console's URL Inspection tool to see what Googlebot actually received. - Check whether any CMS plugins (e.g., SEO plugins on WordPress) conditionally add noindex based on page status, category, or user role. Fix: Ensure the robots meta tag outputs a consistent value (index, follow) regardless of user state, cache state, or test variant. 2. 📄 Unstable Canonical Tag A self-referencing canonical tag is required for a page to be considered fully indexable. If your canonical tag points to a different URL intermittently — or is missing on some page loads — Search Atlas may alternate between classifying the page as indexable and not indexable. - Check the <link rel="canonical"> tag in the page source on multiple loads. - Confirm the canonical URL exactly matches the page's primary URL (including or excluding trailing slash, www, and HTTPS — whichever is your canonical format). Fix: Hardcode a consistent, absolute canonical URL in your page template so it never varies between requests. 3. 🤖 Robots.txt Blocking the Crawl Intermittently If your robots.txt file is served from an origin that experiences downtime or slow responses, crawlers may be blocked on some requests and allowed on others. Search Atlas interprets a blocked crawl as Not Indexable. - Verify your robots.txt is accessible at yourdomain.com/robots.txt and loads consistently. - Check that the Disallow rules do not include the URL path you are auditing. Fix: Ensure your robots.txt is cached and served reliably. Remove any Disallow rules that inadvertently match the page you want indexed. 4. 🔀 Redirect Chains or Temporary Redirects A page that returns a 200 OK on some requests but a 301, 302, or 307 redirect on others will flip indexability status. Temporary redirects (302, 307) in particular signal to crawlers that the destination is not the canonical page. - Test the URL with a server header checker tool to confirm it consistently returns a 200 status code. - Look for redirect logic tied to geolocation, device type, or login state that may be routing crawlers differently. Fix: Consolidate redirects and ensure the target URL always returns 200 OK without intermediate hops. 5. 🧩 JavaScript-Rendered Content and Render Timing If critical indexability signals — such as the robots meta tag or canonical tag — are injected by JavaScript after the initial page load, crawlers may or may not process them depending on render timing. This creates non-deterministic indexability outcomes. - View the page source (not the rendered DOM) to confirm these tags are present in the raw HTML. - If you are using a JavaScript framework, ensure your SEO tags are rendered server-side or pre-rendered. Fix: Move robots meta and canonical tags into the static server-rendered HTML so they are always present on the first byte of the response. ✅ Recommended Resolution Steps 1. Run the On-Page Audit for the affected URL and note every flagged issue. 2. Check the robots meta tag, canonical tag, robots.txt, HTTP status code, and page source for inconsistencies. 3. Fix the root cause in your CMS, hosting configuration, or codebase. 4. Re-run the On-Page Audit after your changes are live to confirm the status has stabilised as Indexable. 5. If the page is already in Google's index but flagged incorrectly, use Google Search Console → URL Inspection → Request Indexing after resolving the issue. 💬 Need More Help? If you have followed all the steps above and the indexability status is still flipping, If you need further assistance, open 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 Sitemap Crawling and Page Indexing

🗺️ How Search Atlas Crawls Your Website Search Atlas uses your sitemap to discover and crawl pages on your website. Unlike some third-party tools that actively spider every link they find, Search Atlas relies primarily on a valid, well-structured XML sitemap to identify which pages to audit and index. If your sitemap is incomplete, misconfigured, or missing, Search Atlas may not crawl all of your pages — even if another tool successfully did so using a different discovery method. ⚠️ Common Reasons Not All Pages Are Crawled - Incomplete sitemap: Your sitemap does not list all 500+ pages. Pages left out of the sitemap will not be discovered by Search Atlas. - Sitemap not submitted or linked: Your sitemap URL has not been provided to Search Atlas, or it is not referenced in your robots.txt file. - Multiple sitemaps not included: Large sites often use a sitemap index file that references multiple child sitemaps. If only one child sitemap is submitted, other pages will be missed. - Sitemap contains errors: Malformed XML, incorrect URLs, or pages marked with a noindex directive may cause Search Atlas to skip those entries. - Crawl limit not yet reached: Depending on your plan, there may be a page crawl limit. If your site exceeds this limit, not all pages will be processed in a single crawl. - Robots.txt is blocking crawlers: Directives in your robots.txt file may be preventing Search Atlas from accessing certain sections of your site. ✅ How to Resolve Incomplete Crawls 1. Verify your sitemap is complete. Open your sitemap (typically found at yourdomain.com/sitemap.xml) and confirm every page you want crawled is listed. Use a sitemap validation tool to check for formatting errors. 2. Check for a sitemap index file. If your site has more than a few hundred pages, it likely uses a sitemap index. Make sure the index file references all child sitemaps and that you submit the index URL — not just one child sitemap — to Search Atlas. 3. Submit the correct sitemap URL to Search Atlas. Navigate to your project settings inside the platform and confirm the sitemap URL entered matches the exact location of your sitemap or sitemap index file. 4. Review your robots.txt file. Visit yourdomain.com/robots.txt and check that no Disallow rules are blocking the pages you want crawled. Also confirm your sitemap URL is referenced with a Sitemap: directive. 5. Remove noindex tags from pages you want indexed. If a page has a noindex meta tag or X-Robots-Tag header, Search Atlas will respect that directive and exclude the page. Remove the tag if you want the page to be crawled and indexed. 6. Re-trigger a crawl. After correcting your sitemap or settings, initiate a new crawl from within your Search Atlas project to pick up the updated page list. 📊 Understanding Plan-Based Crawl Limits Search Atlas crawl limits vary by subscription plan. If your website has more pages than your current plan allows in a single crawl, only a portion of your site will be processed. To crawl larger sites in full, consider upgrading your plan or prioritising the most important pages in your sitemap by placing them at the top of the file. Contact our team via the chat widget for guidance on which plan suits your site size. 🛠️ Using On-Page Audit to Review Crawled Pages Once a crawl is complete, you can review which pages were successfully indexed and identify any issues by navigating to Left sidebar → Content → On-Page Audit. This view shows all crawled URLs along with any errors, warnings, or notices that may be affecting coverage. Use this report to cross-reference against your sitemap and identify gaps in crawl coverage. 💡 Best Practices for Full Site Crawling - Keep your sitemap up to date whenever new pages are published or old pages are removed. - Use a sitemap index file for sites with more than 1,000 pages. - Set the lastmod date on each sitemap entry so Search Atlas can prioritise recently updated pages. - Avoid including pages in your sitemap that return a 301 redirect, 404 error, or noindex directive — these waste crawl budget. - Validate your sitemap regularly at yourdomain.com/sitemap.xml to catch formatting issues early. 🙋 Still Seeing Missing Pages? If you have followed the steps above and Search Atlas is still not crawling all of your pages, there may be a configuration issue specific to your site or 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.

🔧 OTTO & Site Audit Sidebar Highlight Fix

A sidebar highlighting bug in OTTO & Site Audit has been identified and resolved as part of the 2026-07-21 release (ticket OTTO-2890). This was a visual-only fix and does not affect any underlying functionality. What Was Fixed A visual bug in the OTTO & Site Audit sidebar was reported and has been shipped as a bugfix in this release. The specific behavior affected how a sidebar item appeared in certain states. This correction is applied automatically — no action is required on your end. What to Expect Because this is a visual correction only, you do not need to change any settings or take any steps inside the platform. The fix is already live. If you were previously seeing unexpected highlighting or incorrect visual states in the OTTO & Site Audit sidebar, this release should have resolved that behavior. If You Are Still Seeing the Issue If the sidebar still appears to behave unexpectedly after this fix, please be ready to share the following when reaching out to our team: - Your project name or the account affected - A description or screenshot of the visual behavior you are seeing - The approximate time you first noticed the issue If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

No Business Showing in Tool Selector

If no business appears in a tool's selector dropdown within Search Atlas, it means a business has not yet been created inside that specific tool. Each Search Atlas module maintains its own independent business list — businesses must be added per tool before they appear for selection. 📋 Why This Happens This is expected behavior, not a bug. Search Atlas tools — including GBP Manager (Local → GBP Projects), Local SEO Heatmaps, PPC, and Brand Vault — each manage their own list of businesses or locations independently. A business configured in one tool does not automatically carry over to another. Every tool requires its own setup before the selector will populate. ✅ How to Add a Business to a Tool Follow these steps to make a business appear in the selector: 1. Open the tool where the selector is empty — for example, Local SEO Heatmaps, PPC, or Brand Vault. 2. Look for the Connect GBP Account button (Local → GBP Projects). This is typically displayed in the tool's main view or within its settings area. 3. Complete all required fields for your business or location and save the entry. 4. Return to the selector dropdown — your newly added business will now be available for selection. ⚠️ Common Scenarios - Using multiple tools: A business added in one tool (for example, GBP Manager at Local → GBP Projects (GBP Projects)) does not appear in other tools (for example, Local SEO Heatmaps or PPC). You must add the business separately in each tool you want to use it with. - Recently added to a workspace: If you were just invited to a workspace, you may not see businesses created by other team members. This depends on your permission level — contact your workspace admin to verify your access rights. - Incomplete business setup: If you began creating a business but did not complete all required fields, it may not appear in the selector. Return to the tool's business or location settings and confirm the entry is fully saved. - Brand Vault — business has no products configured: Brand Vault intentionally excludes businesses that have no products added to them. If a business does not appear in the Brand Vault selector, verify that at least one product has been configured for that business first. - PPC tool — business not visible in a long list: The PPC Business Selection Dropdown includes a search input to help you locate a specific business quickly when managing many accounts. If the business is not immediately visible in the dropdown, try typing its name into the search field. 💬 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 Site Audit Failures Blocking Brand Vault

🔍 Why Your Brand Vault Needs a Successful Crawl When you create a Brand Vault, Search Atlas first runs a site audit to understand your website's structure, content, and SEO health. If that initial crawl fails or gets stuck, the Brand Vault setup process cannot move forward. Resetting the audit is the fastest way to clear the block. ⚙️ Common Causes of Crawl Failures Most crawl failures fall into a few recognizable categories. Review the list below to identify what may be affecting your site: - Server or hosting blocks – Your server or CDN (such as Cloudflare) may be blocking our crawler's IP range or user agent. - Robots.txt restrictions – A restrictive robots.txt file can prevent our crawler from accessing key pages. - Sitemap errors – Missing, broken, or inaccessible XML sitemaps can cause the crawl to stall or return errors. - Redirect loops – Circular redirects between HTTP/HTTPS or www/non-www versions can halt the crawl. - Timeouts on large sites – Very large sites with thousands of pages may exceed the crawl window, causing an incomplete audit. 🚀 How to Reset Your Site Audit If your audit is stuck or has failed, follow these steps to reset it: 1. Navigate to OTTO SEO → Site Audit in the left sidebar of Search Atlas. 2. Locate the site with the failed audit in your list of active projects. 3. Open the site's dashboard and go to the site audit section. 4. Reset the audit so that a new crawl is triggered for the site. 5. Confirm the reset when prompted. 6. Wait for the new crawl to begin — it should start within a few minutes. ✅ Verifying the Fix After resetting the audit, check the following to confirm everything is working: - The audit shows it is running again within 5–10 minutes. - The crawl progress advances without stalling. - Once the crawl completes successfully, return to your Brand Vault setup — the option to proceed should now be available. 💡 Tips to Prevent Future Failures To minimize the chance of crawl failures on future audits, consider these proactive steps: - Whitelist Search Atlas crawler IPs in your firewall, CDN, or security plugin. - Ensure your robots.txt file allows access to important content sections. - Keep your XML sitemap valid and submitted in the audit configuration. - Resolve any redirect chain issues on your primary domain. 📞 Still Having Trouble? If resetting the audit does not resolve the issue, our team can investigate the crawl logs and server response on your behalf. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🗑️ Remove OTTO-Injected Metadata for Deleted Images

🧠 Why OTTO Retains Metadata for Deleted Images OTTO builds and injects structured data — including ImageObject schema — based on images it detects on your website. When you remove an image (for example, Group_20.png), OTTO does not automatically know the image is gone. Its internal metadata cache still holds a reference to that image and continues injecting the associated ImageObject schema into your pages. This is different from a standard WordPress, CDN, or server-level cache. Clearing those caches will not remove OTTO's stored image references. The stale metadata reference must be cleared directly within OTTO's backend. ⚠️ What This Looks Like - Schema Validator or Google Rich Results Test flags warnings for images that no longer exist on your site. - ImageObject entries reference filenames like Group_20.png or other deleted assets. - The warnings persist even after clearing your WordPress cache, CDN cache, or server cache. 🔍 How This Is Resolved Clearing stale image metadata from OTTO's cache is a backend operation performed by the Search Atlas support team — there is currently no self-serve option in the platform to trigger this directly. When the cache is cleared on the backend, OTTO drops references to images that no longer exist and stops injecting the outdated ImageObject schema into your pages. To get this resolved as quickly as possible, please reach out to support and have the following information ready: - Your project or site name in Search Atlas - The exact URLs of the affected pages - The filenames of the deleted images referenced in the warnings (e.g. Group_20.png) - A screenshot or copy of the Schema Validator warning you are seeing ✅ After the Cache Is Cleared 1. Wait a few minutes for the updated schema to propagate after the support team confirms the cache has been cleared. 2. Re-test the affected URLs using Google's Rich Results Test or your Schema Validator tool. 3. Confirm that ImageObject entries for deleted images no longer appear in the output. 💡 Tips to Prevent This in the Future - Contact support promptly after removing images from your site so the metadata cache can be cleared before Schema Validator warnings accumulate. - Before deleting images, note which pages use them so you know exactly which pages and filenames to include in your support request. - Keep a record of any deleted image filenames — this speeds up the backend cache-clearing process significantly. If you need further assistance, open 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 Site Auditor and OTTO Quota Conflicts

🔍 What Is This Error? When you try to activate a new site in OTTO, you may see a quota limit error related to Site Auditor — even if you still have available OTTO slots. This happens because OTTO must attach to an existing Site Auditor project for the same domain. If the domain doesn't already have a Site Auditor project and your Site Auditor project quota is full, the OTTO activation will be blocked, regardless of how many OTTO slots remain. In short: OTTO slots and Site Auditor project slots are two separate quotas, and both must have availability for a new OTTO site activation to succeed. ⚠️ Common Causes - Orphaned Site Auditor projects: You may have old Site Auditor projects from sites that are no longer active in OTTO. These still count against your quota. - Quota display lag: In some cases, the Site Auditor quota counter may show an incorrect number on first load (for example, 0/4) before updating to the correct value after a page refresh. - Sites removed from OTTO but not from Site Auditor: Deleting or freezing an OTTO site does not automatically remove its associated Site Auditor project. ✅ How to Fix the Conflict 1. Check your Site Auditor quota. Go to Left sidebar → OTTO SEO → All Sites (SEO Automation) (URL: /seo-automation-v3) and review your active and frozen sites. Note the total number of sites currently using OTTO. 2. Identify unused Site Auditor projects. Navigate to the Site Auditor section of your platform and look for projects tied to domains that are no longer active or relevant. These are the most common cause of quota conflicts. 3. Delete unnecessary Site Auditor projects. Remove any Site Auditor projects you no longer need. Each deletion frees up one slot in your Site Auditor quota. 4. Refresh the page. After deleting projects, refresh your browser. The quota counter can lag on first load — a refresh ensures the display reflects the correct available slots. 5. Retry the OTTO site activation. Return to OTTO SEO and attempt to add your site again. If your Site Auditor quota now has an open slot, the activation should complete successfully. 💡 Tips to Avoid This Issue in the Future - Audit your Site Auditor projects regularly. Keep only the projects you actively use so you always have headroom to add new OTTO sites. - Freeze instead of delete when possible. If you want to pause an OTTO site temporarily, use the Freeze option. This suspends OTTO activity but keeps the site in your account without consuming an active slot unnecessarily. - Understand your plan limits. Check your current plan to know exactly how many Site Auditor projects and OTTO sites are included. Upgrading your plan is the fastest way to increase both quotas if you manage a large number of sites. ❓ Frequently Asked Questions I deleted an OTTO site — why is my Site Auditor quota still full? Removing a site from OTTO does not automatically delete its Site Auditor project. You need to manually delete the associated Site Auditor project to free up that quota slot. My quota shows 0 available slots but I just deleted a project. What should I do? This is a known display lag. Refresh the page and the counter should update to reflect the correct number of available slots. Can I have more Site Auditor projects than OTTO sites? Yes. Site Auditor projects and OTTO site activations are managed independently. You can run Site Auditor projects on domains that are not connected to OTTO. 🆘 Still Need Help? If you have followed the steps above and are still seeing the quota error, or if your quota counts appear incorrect after a page refresh, our team is ready to investigate. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔧 Troubleshooting Subscription Features Breaking Your Site

🧭 Overview If your site started experiencing issues after activating a Search Atlas subscription feature — such as tracking snippets, automation scripts, or plugin integrations — this guide will help you isolate and resolve the cause. In most cases, the issue is a configuration conflict, not the subscription itself, and can be fixed in minutes without cancelling your account. ⚠️ Before You Begin Identify what changed on your site around the time the issue started. Ask yourself: - Did the issue begin immediately after installing a Search Atlas snippet or plugin? - Did it start after a WordPress, CMS, or theme update? - Is the problem visible on every page, or only specific ones? - Are you seeing a blank screen, broken layout, redirect loop, or console errors? Your answers will point you to the most relevant section below. 🧩 Step 1 — Check for Script or Snippet Conflicts Search Atlas tracking or automation snippets can occasionally conflict with other scripts on your page. 1. Open your browser's developer tools (press F12 or right-click → Inspect) and go to the Console tab. 2. Reload the affected page and look for red error messages. Note any file names or script URLs mentioned. 3. If errors reference a Search Atlas script, temporarily remove the snippet from your site's <head> or tag manager. 4. Reload the page. If the issue disappears, the snippet placement or a conflicting third-party script is the cause. 5. Re-add the Search Atlas snippet as the last script in your <head> section to reduce load-order conflicts. 🌐 Step 2 — Rule Out DNS or Domain Configuration Issues Some subscription features require verified domain connections. Misconfigured DNS records can cause redirects or broken page loads. 1. Go to OTTO SEO → SEO Automation in the left sidebar (URL: /seo-automation-v3) and open your project settings. 2. Confirm your domain is verified and that no DNS warnings are shown on the dashboard. 3. If you recently changed hosting providers or updated nameservers, allow up to 48 hours for full propagation before troubleshooting further. 4. Use a free tool such as dnschecker.org to confirm your A records and CNAME records match what Search Atlas expects. 5. If DNS records appear incorrect, update them through your domain registrar and re-verify the domain inside the platform. 🔌 Step 3 — Test for Plugin or Theme Compatibility If your site runs on WordPress or another CMS, a plugin or theme update may have created a conflict. 1. Temporarily switch to a default theme (such as Twenty Twenty-Four in WordPress). If the site recovers, your active theme is conflicting with the Search Atlas integration. 2. Deactivate all plugins except the Search Atlas plugin. Reload the affected page. 3. If the site recovers, reactivate plugins one by one, reloading after each, until the conflict reappears. That plugin is the source. 4. Check that the Search Atlas plugin is on its latest version. Go to your CMS plugin manager and update if a newer version is available. 5. If a specific plugin conflict is confirmed, contact its developer or reach out to Search Atlas support (see below) for a compatibility fix. ⚡ Step 4 — Check Automation Script Placement Incorrectly placed automation scripts are a common cause of layout breaks or JavaScript errors. 1. Search Atlas snippets should be placed inside the <head> tag, not inside <body> or injected via footer scripts unless explicitly instructed otherwise. 2. If you are using Google Tag Manager, confirm the tag is firing on All Pages and that no blocking triggers are preventing it from loading. 3. Avoid placing multiple copies of the same snippet on a single page. Duplicate snippet injections can cause infinite loops or duplicate tracking events that stress page rendering. 4. After correcting placement, clear your site cache and CDN cache entirely before testing again. 🗂️ Step 5 — Isolate with a Staging Environment If you cannot identify the conflict on a live site, use a staging or test environment to diagnose safely. 1. Clone your live site to a staging URL using your hosting panel or a migration plugin. 2. Remove the Search Atlas snippet or plugin from staging and confirm the site loads normally. 3. Re-add each Search Atlas component one at a time, testing after each addition, until the issue reappears. 4. Document exactly which component triggers the issue. This information will help our technical team resolve it faster. ✅ Quick Checklist Before Escalating - Browser console checked for script errors - Search Atlas snippet temporarily removed and site tested - Snippet placement confirmed inside <head> - DNS records verified and domain confirmed in the platform - Plugins and theme tested for conflicts - Site and CDN cache fully cleared after each change - No duplicate snippets present on the page 🙋 Still Experiencing Issues? If you have worked through all the steps above and your site is still affected, our Tier 2 technical support team can perform a deeper investigation, including reviewing your snippet configuration, domain verification status, and integration 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. When you reach out, please share the following to speed up resolution: your site URL, a description of the exact issue you see, any browser console errors you noted, and which troubleshooting steps you have already completed. This allows our team to skip straight to advanced diagnostics and resolve your issue as quickly as possible.

🕷️ Fix OTTO Crawler Failures on Homepage Redirects

🔍 Overview When you create an OTTO SEO project, OTTO crawls your homepage to verify the pixel installation and index your site. If your domain automatically redirects to a subdirectory — for example, example.com redirecting to example.com/news — OTTO may follow that redirect and land on a page that breaks the crawl. This can cause project creation to stall, return zero pages crawled, or prevent pixel detection from completing successfully. ⚠️ Why This Happens OTTO's crawler starts at your root domain and follows any redirects it encounters. Redirects to subdirectories can cause two specific problems: - Pixel not detected: If the subdirectory page does not carry the OTTO pixel in its HTML, the crawler cannot confirm a successful installation, and project creation fails. - Crawl returns zero pages: In some configurations, the redirect strips internal parameters OTTO needs to complete the crawl, resulting in no pages being indexed even though the site is reachable. ✅ Step-by-Step: Resolve the Redirect Issue 1. Confirm where your domain redirects. Open a browser and type your bare domain (e.g., example.com). Note the final URL in the address bar. If it ends in a subdirectory such as /news or /en, a redirect is in place. 2. Place the OTTO pixel on the redirect destination. Make sure the OTTO tracking pixel is installed on the page your domain actually lands on after the redirect — not just on the root-level template. If you are using a CMS, add the pixel to the header template of that specific section. 3. Use the exact landing URL when creating your project. In Search Atlas, go to Left sidebar → OTTO SEO → All Sites (SEO Automation) (URL: /seo-automation-v3). When prompted to enter your domain during project creation, enter the full subdirectory URL that is the true homepage — for example, example.com/news — rather than the bare domain. This gives OTTO a stable starting point that does not redirect. 4. Verify the pixel using your browser. Before retrying project creation, open the landing page, right-click, and select View Page Source. Search for your OTTO pixel code to confirm it is present. If it is missing, reinstall it and save your changes before proceeding. 5. Create or re-create the OTTO project. Return to Left sidebar → OTTO SEO → All Sites (SEO Automation) and select Create. Enter the subdirectory URL from step 3 and complete the setup wizard. OTTO will now crawl from that stable endpoint instead of chasing a redirect. 6. Monitor the crawl. After creation, check that the project status moves past the initial setup phase and that pages are being indexed. If the project shows 0 pages crawled after several minutes, proceed to the troubleshooting section below. 🛠️ Additional Troubleshooting If the steps above do not resolve the issue, consider the following: - Check for redirect chains. A single domain can have multiple hops — for example, example.com → www.example.com → example.com/news. Each hop increases the chance of parameter loss. Use a redirect-checker tool to map every hop and ensure the final destination carries the pixel. - Confirm there is no redirect loop. Misconfigured redirects can cause a page to redirect back to itself. If your site went offline or slowed down after adding OTTO, this may be the cause. Contact your hosting provider or developer to audit your redirect rules. - Check that the subdirectory is publicly reachable. Some subdirectories are gated behind a login or return a non-200 HTTP status for bots. OTTO requires a publicly accessible 200 OK response to crawl successfully. - Allow up to 15 minutes after pixel installation before triggering project creation. Caching layers on your server or CDN may serve an older version of the page without the pixel for a short period after you save changes. ❓ Frequently Asked Questions Can OTTO crawl a subdirectory like /news instead of the root domain? Yes. When creating your OTTO project, enter the subdirectory URL as your project domain. OTTO will treat that URL as the starting point for the crawl and will not require the bare root domain. Why did my project domain change automatically after creation? If you entered a root domain that immediately redirects, OTTO may have auto-resolved it to the redirect destination. This is expected behavior. Verify the project now points to the correct subdirectory and that the pixel is installed there. Will using a subdirectory as my project URL affect SEO recommendations? OTTO will scope its recommendations to the pages it can reach from your starting URL. If your entire site lives under /news, entering that subdirectory will give OTTO full access. If your site spans multiple subdirectories, contact support to discuss the best configuration for your setup. 💬 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 Onpage Audit URL Failure Status 200

🔍 Understanding the Error When the Onpage Audit tool returns the message "Auditing URL failed - Status Code: 200", it can feel confusing — HTTP 200 normally means a page loaded successfully. However, this error does not mean the page is broken. It means our audit crawler received a 200 response but was blocked from reading the page content it needs to complete the audit. Common reasons this happens include: - The website blocks automated crawlers or bots via server-side rules - A firewall, WAF (Web Application Firewall), or CDN (e.g. Cloudflare) is intercepting the request - The page requires JavaScript to render content before it becomes accessible - Bot-detection scripts are serving a blank or restricted page to non-browser requests - The server returns a 200 status but redirects internally to a login wall or CAPTCHA ✅ Steps to Resolve the Issue 1. Confirm the URL is publicly accessible. Open the URL in an incognito or private browser window. If you are prompted to log in or see a CAPTCHA, the page is not publicly crawlable and the audit tool will not be able to access it. 2. Check your firewall or CDN settings. If your site uses Cloudflare, Sucuri, or a similar service, check whether bot protection or "Under Attack Mode" is enabled. These settings frequently block automated audit requests even when returning a 200 status code. 3. Whitelist Search Atlas crawlers. Ask your developer or hosting provider to allow requests from the Search Atlas crawler user-agent. Whitelisting our crawler ensures the audit tool can read page content without being intercepted. 4. Check your robots.txt file. Visit yourdomain.com/robots.txt and confirm the page or directory is not disallowed for all bots. A disallow rule can cause the crawler to receive a restricted response even with a 200 status. 5. Test with a different URL on the same domain. Try auditing another page on the same website. If other pages audit successfully, the issue is specific to that page's configuration rather than a platform-wide problem. 6. Re-run the audit after making changes. Once you have adjusted firewall rules or bot-detection settings, return to the Onpage Audit tool, enter the URL again, and run a fresh audit. ⚙️ How to Re-Run an Onpage Audit 1. Navigate to the Onpage Audit tool within the platform. 2. Locate the project or enter the URL you want to audit. 3. Start a new audit for that URL. 4. Wait for the audit to complete and review the results. 💡 Tips to Prevent This Error - Always audit publicly accessible pages. Password-protected, staging, or members-only pages cannot be audited. - If your site uses heavy JavaScript rendering, ensure the page content is accessible to non-browser crawlers. If you need further assistance, open 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 Showing Connected After Install

🔍 Overview After adding the OTTO script to your website, you may notice the dashboard still shows the pixel as not connected. In most cases, this is completely normal. Search Atlas checks for the pixel on a schedule based on your project's age: every 15 minutes for projects under 2 hours old, every hour from 2 to 24 hours old, every 6 hours from 1 to 7 days old, and automatic checks stop after 7 days. A correctly installed pixel on a new project is normally detected within about 15 minutes. No reinstallation is needed — you simply need to wait for the next check and for the initial audit to finish. 📋 Understanding Connection Statuses Once the OTTO script is installed, your dashboard will display one of two statuses: - Audit in Progress — The OTTO pixel has been detected and the initial site audit is actively running. Search Atlas is crawling your site and collecting data. This is the expected status immediately after installation. - Connected — The initial site audit has completed successfully. OTTO is fully active and ready to manage SEO automation on your site. The transition from Audit in Progress to Connected happens automatically once the audit finishes. You do not need to take any action during this time. ⏱️ Why Does the Audit Take Time to Complete? When the OTTO script is first installed, Search Atlas performs a comprehensive crawl of your entire website. This initial audit scans your pages, content, metadata, and technical SEO signals so OTTO can build an accurate baseline before making any recommendations or changes. The time required depends on the size of your site — larger sites with many pages naturally take longer to crawl. 📊 How to Monitor Your Audit Progress You can track the status of your site audit at any time from inside the platform by navigating to the OTTO dashboard and locating your connected site. If the status shows Audit in Progress, the crawl is still running — check back periodically. Once the status updates to Connected, your OTTO setup is complete and fully active. ✅ How to Confirm Your Script Was Installed Correctly While waiting for the audit to complete, you can verify that your script is installed properly so you can rule out any installation issues by checking that the OTTO script tag is present in your site's code and loading without errors. If the script is present and loading correctly, the Audit in Progress status simply means the crawl is still running — no further action is needed on your end. If you need further assistance, open 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.

⚡ Fix Instant Indexing HTTP 400 Activation Error

🔍 Overview If Instant Indexing won't activate for your project and the platform returns an HTTP 400 'Unable to activate indexing' error, this almost always means your current subscription plan does not include Instant Indexing. This article explains the plan requirements, what the error signals, and the steps to get Instant Indexing running. 📋 Who Can Use Instant Indexing Instant Indexing is a premium feature available exclusively on the following plans: - Pro plan - Agency plan Starter and free-tier accounts cannot activate Instant Indexing, regardless of whether the tracking pixel is installed, Google Search Console (GSC) is connected, or a sitemap has been submitted. Those steps are necessary but not sufficient — the correct plan is also required. 🚨 Understanding the HTTP 400 Error When Instant Indexing activation fails due to a plan restriction, the API returns: - HTTP status: 400 - Message: Unable to activate indexing - is_transient: false The is_transient: false flag is important. It means the error is permanent under current conditions — it will not resolve on its own, and retrying will not help. This is not a temporary glitch, a connectivity issue, or a configuration problem with your pixel or GSC integration. It is a hard block that requires a plan change to resolve. If you see is_transient: true, that indicates a temporary issue such as a server timeout or a momentary API hiccup, which may resolve itself or after a short wait. ✅ Prerequisites Already Checked The following setup steps are required for Instant Indexing but do not guarantee activation on their own: - Tracking pixel installed on the target domain - Google Search Console account connected to Search Atlas - Sitemap submitted and registered in GSC If all of the above are in place and you still see the HTTP 400 error with is_transient: false, proceed to the plan verification steps below. 🛠️ Steps to Resolve the Error 1. Check your current plan. Log in to your Search Atlas account and locate your subscription or billing information. Confirm whether your active subscription is Pro or Agency. If it shows Starter or any lower tier, that is the cause of the error. 2. Upgrade your plan if needed. From your account's billing or subscription area, select the option to upgrade and choose either the Pro or Agency plan. Complete the checkout process. 3. Return to your project and retry activation. After the plan upgrade is confirmed, go back to your project (for example, montreallighting.com) and attempt to activate Instant Indexing again. 4. Contact support if the error persists. If you have already upgraded to a qualifying plan and the HTTP 400 error continues to appear, reach out to the Search Atlas support team via the chat widget so an agent can investigate further.

🛠️ GSC Instant Indexing Errors, Unique Address Generation & Schema Markup in Search Atlas

GSC Instant Indexing errors in Search Atlas are almost always caused by Google API capacity limits or cached browser data — not your account. Use this article to resolve activation failures, generate your unique service account address, and navigate Schema Markup items. 🔐 GSC Instant Indexing — Why Activation Fails When you see an error activating GSC Instant Indexing, Google's Indexing API capacity is temporarily exhausted. This is a Google-side limitation, not an account issue — activation limits are controlled entirely by Google. When capacity is full, new activations are blocked automatically. While GSC Instant Indexing is unavailable, you can: - Use Google Search Console → URL Inspection to request indexing manually. - Periodically refresh the page and retry activation. - Use the URL Indexer feature inside Search Atlas as an alternative. Google controls when capacity returns; once it does, activation works without any changes on your end. 🧪 Unique Address Generation Failure — Cache Fix & Support Escalation If clicking Generate produces an error or fails to return a unique service account address (e.g., indexing-customer@indexed-xxxxxxxx.iam.gserviceaccount.com) across one or multiple projects, cached browser data is the most common cause. Steps to fix the Generate button: 1. Clear your browser cookies and cache. 2. Relaunch Chrome in Incognito mode. 3. Log back into Search Atlas and click Generate again. After clearing cache and relaunching Chrome, the Generate button returns the unique service account address. This has resolved generation failures in all confirmed support cases. If the Generate button still fails after clearing cache: Contact Search Atlas support. A support agent can retrieve your unique indexing address directly from the backend and provide it to you so you can continue setup without delay. 🔑 Required GSC Permission Level for the Indexing Service Account When adding the generated service account email to Google Search Console (Step 2 of the in-product setup guide), set the permission level to Owner. - Lower permission levels — Full User or Restricted User — will prevent the integration from functioning correctly. - Only Owner grants the access that GSC Instant Indexing requires. Once you assign Owner access and save, the integration connects and indexing requests can be submitted immediately. 🧩 Schema Markup — Understanding the "1 of X" Indicator The "1 of 14" label means Search Atlas detected 14 schema markup items and you are currently viewing the first one. The remaining items are not missing — they are paginated. To view all Schema Markup items: 1. Click the blue Schema Markup button. 2. Look for navigation arrows (← →), pagination controls, or a dropdown selector. 3. Use the controls to cycle through items 2, 3, 4, and so on. If no navigation controls are visible at first, clicking the Schema Markup button itself opens the detailed view where the controls appear. ❓ Frequently Asked Questions Is GSC Instant Indexing broken on my account? No. Activation limits are a Google-side limitation that affects all users when API capacity is exhausted. Can I avoid the activation capacity error? No. Capacity is controlled entirely by Google's API. Use the URL Indexer or Google Search Console's URL Inspection tool in the meantime. I can't generate a unique indexing address — what should I do? Clear your browser cookies and cache, then try again in a Chrome Incognito window. This resolves most generation failures. If the issue persists after clearing cache, contact Search Atlas support — an agent can retrieve your unique indexing address directly from the backend. What GSC permission level do I need for the indexing service account? Owner. Other permission levels will not work. Are my schema markup items missing if I see "1 of X"? No. All detected schema items are present. Use the navigation controls inside the Schema Markup panel to cycle through each one. 🌀 You now know how to resolve GSC Instant Indexing activation errors, generate your unique service account address (or escalate to support for backend retrieval if needed), assign the correct Owner permission in Google Search Console, and navigate all Schema Markup items in Search Atlas. If you need further assistance with your indexing setup, contact the Search Atlas support team.

🔑 Fix Instant Indexing Token Generation Errors Fast

🧭 Overview If the instant indexing token fails to generate, or platform features such as OTTO SEO behave unexpectedly, the most common cause is a stale browser cache stored specifically for the Search Atlas site. This is a browser-side issue and is not related to your OTTO SEO configuration or auto-generation settings. Following the steps below clears only the Search Atlas cache without affecting your other browsing data. ⚠️ Symptoms to Watch For - Instant indexing token fails to generate or shows an error message - Platform features load incorrectly or do not respond as expected - You find yourself repeatedly clearing your entire browser cache to restore normal behaviour - OTTO SEO (/seo-automation-v3) or Site Explorer pages appear broken or incomplete 🔍 Why This Happens Your browser stores cached data for every website you visit to help pages load faster. Over time, the cached data for Search Atlas can become outdated or corrupted, particularly after platform updates. When this happens, authentication tokens — including the instant indexing token — may fail to generate correctly, and certain features may stop working until the old cache is removed. Clearing only the Search Atlas site data is the fastest and safest fix. 🛠️ Step-by-Step: Clear the Search Atlas Site Cache in Chrome 1. Open a new tab in Google Chrome and type chrome://settings/content/all in the address bar, then press Enter. 2. In the search field at the top of the page, type searchatlas.com to filter results to only the Search Atlas site data. 3. Click the Delete (trash) icon next to the Search Atlas entry to remove all stored site data. 4. If you see more than one entry related to Search Atlas, delete each one. 5. Close the settings tab, then navigate back to searchatlas.com and log in again. 6. Go to the platform feature where the token error occurred and attempt to generate the instant indexing token again. This process removes only the data stored for Search Atlas and does not clear cookies, cache, or saved data for any other website. 🌐 Clearing Site Data in Other Browsers If you are not using Chrome, the steps below cover the most common alternatives. - Firefox: Open Settings → Privacy & Security → Cookies and Site Data → Manage Data, search for searchatlas.com, select it, and click Remove Selected. - Microsoft Edge: Open Settings → Cookies and site permissions → Manage and delete cookies and site data → See all cookies and site data, search for searchatlas.com, and delete the entry. - Safari: Open Settings → Privacy → Manage Website Data, search for searchatlas.com, select it, and click Remove. ✅ Confirming the Fix After clearing the site cache and logging back in, verify the following: - The instant indexing token generates successfully without an error message - OTTO SEO loads correctly at Left sidebar → OTTO SEO → All Sites (SEO Automation) - Site Explorer and its sub-pages — Keyword Magic, Rank Tracker, and Keyword Gap — display data as expected If the token generation still fails after completing these steps, try using an incognito or private browsing window to rule out a browser extension conflict. Extensions can interfere with authentication flows even after the cache is cleared. 🔄 Preventing the Issue in the Future - If you notice platform features behaving strangely after a Search Atlas update, clearing the site-specific cache is always a good first step before trying anything else. - Avoid using browser extensions that block scripts or modify cookies on the Search Atlas domain, as these can cause token generation to fail intermittently. - Using a dedicated browser profile for Search Atlas can help isolate and prevent cache-related 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.

🔍 OTTO Pixel Not Detected on Shopify Store

🧭 Overview If you have added the OTTO pixel to your Shopify store and can confirm it appears in your site's source code, but the platform still shows a "not installed" status after several days, you are not alone. This is a common point of confusion during the trial period and is almost always caused by the Site Auditor's initial crawl initialization phase — not a problem with your pixel installation. This article explains the difference between initialization and active crawling, what to expect at each stage, and how to monitor your progress. 🔎 Two Distinct Phases Before Detection Works Many customers assume that once the Site Auditor is enabled, it immediately begins scanning pages. In reality, there are two separate phases before pixel detection can be confirmed: - Phase 1 — Initialization (0 to 24 hours): The Site Auditor sets up your site's crawl environment. During this window, no pages are actively scanned and no pixel detection occurs. This phase runs silently in the background and cannot be skipped or accelerated. - Phase 2 — Active Crawling: Once initialization completes, the auditor begins crawling your pages. Pixel detection status updates as pages are processed. Larger Shopify stores with many URLs can take additional time to reach full coverage. The "not installed" message during Phase 1 does not mean your pixel is broken or missing. It simply means the system has not yet begun scanning your pages. ⏱️ Expected Timeline at a Glance - 0–24 hours after setup: Initialization phase. Status will show "not installed" regardless of pixel presence. No action needed. - 24–48 hours after setup: Active crawling begins. Detection status should update as pages are crawled. - 48–72 hours after setup: Most Shopify stores will have a confirmed detection result by this point. Very large stores or stores with crawl restrictions may take longer. If you added your pixel within the last 24 hours, the correct action is to wait — not to reinstall the pixel or trigger a new crawl. Initiating a new crawl during the initialization phase does not speed up the process and may cause confusion about where the system actually is in its setup. ✅ How to Confirm Your Pixel Is Correctly Installed While you wait for initialization to complete, you can manually verify your pixel is present: 1. Open your Shopify storefront in any browser. 2. Right-click anywhere on the page and select View Page Source. 3. Press Ctrl+F (or Cmd+F on Mac) and search for otto or your specific pixel script identifier. 4. If the script appears in the source, your pixel is installed correctly. No reinstallation is needed. If the pixel does not appear in the page source, navigate to your Shopify admin and confirm the script was saved under Online Store → Themes → Edit Code or via the Shopify Script Tags API, depending on how you added it. 📊 How to Monitor Detection Status in the Platform 1. Log in to Search Atlas and go to OTTO SEO → All Sites (SEO Automation) using the left sidebar (or navigate to /seo-automation-v3). 2. Select your connected Shopify site from the site selector at the top of the page. 3. Locate the OTTO panel and review the pixel status indicator. 4. If initialization is still in progress, the status will remain as "not installed" or "pending." This is expected behavior. 5. Return to this panel after 24 hours to check for an updated status. You do not need to refresh or restart anything manually. 🚫 What Not to Do During Initialization - Do not reinstall the pixel. Multiple copies of the script in your theme can cause conflicts and duplicate tracking. - Do not trigger a manual crawl during the first 24 hours. The system is in a pre-crawl setup state and a manual crawl request will not override initialization. - Do not disconnect and reconnect your site. This resets the initialization timer and extends your wait time. 🛠️ If the Status Still Shows 'Not Installed' After 72 Hours If more than 72 hours have passed since you added the pixel, initialization is complete, and the status has not updated despite the pixel being visible in your source code, there may be a crawl configuration issue. At this point, try the following: 1. Go to OTTO SEO → All Sites (SEO Automation) in the left sidebar. 2. Open your site's auditor settings and check whether any URL rules or crawl restrictions are blocking your homepage or key pages. 3. Ensure your robots.txt file is not blocking the Search Atlas crawler. 4. If everything looks correct, initiate a new crawl from the Site Auditor dashboard and allow 24 hours for results to refresh. If you need further assistance, open 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.

🔧 Fix Site Audit Quota Errors With Available Credits

🧭 Overview You may encounter quota limit errors when running a Site Audit even though your quota display shows available credits. This is a known issue caused by reserved quota tied to existing audits. Old or completed audits can hold quota allocations in the background, preventing new operations from running — even when your dashboard shows credits remaining. This article explains why this happens and walks you through the steps to resolve it. ❓ Why This Happens Site Audit reserves a block of quota when an audit is created. These reservations are not always released automatically when an audit finishes or is no longer in active use. As a result: - Your available quota counter may show a positive number of credits. - But the system still treats those credits as committed to existing audits, blocking new operations. - Any attempt to run a new audit, re-crawl a site, or use quota-dependent features triggers an error. The fix is to delete old or unused audits to release the reserved quota back to your account. 🔍 Step 1 — Check Your Existing Site Audits 1. Navigate to the Site Audit section of the platform. 2. Review the list of all audits associated with your account. 3. Identify audits that are completed, outdated, or no longer needed. Pay attention to audits with large crawl limits, as these reserve the most quota. 🗑️ Step 2 — Delete Old or Unused Audits 1. Click on the audit you want to remove. 2. Open the audit's options or settings menu. 3. Select Delete and confirm the action. 4. Repeat this process for each old or unused audit until you have removed all non-essential entries. Important: Deleting an audit is permanent. Make sure you no longer need the historical data before deleting. ✅ Step 3 — Verify Your Quota Has Been Released 1. After deleting the old audits, refresh your browser. 2. Check your quota display to confirm the available credits have updated. 3. Attempt to run your Site Audit or the feature that was previously failing. In most cases, the operation will succeed immediately after the reserved quota is released. If the quota counter does not update within a few minutes, try logging out and back in, then check again. ⚠️ Step 4 — If the Error Persists If you have deleted old audits and the quota error continues, consider the following: - Check other quota-consuming features. Quota may also be reserved by other tools connected to your account. Review usage across all active features. - Wait a few minutes. Quota releases may take a short time to propagate across the system. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔧 Fix OTTO Pixel Plugin WordPress Installation Errors

Overview If you keep seeing an OTTO Pixel Not Installed Correctly error after installing or reinstalling the plugin on WordPress, the problem is rarely the plugin itself. Two root causes account for almost every case: the Site Audit crawl has not completed, or a security or cache service is blocking the OTTO bot before it can verify the connection. Follow the steps below in order to resolve the error. Step 1: Confirm the OTTO Pixel Plugin Is Installed 1. Log in to your WordPress admin panel. 2. Go to Plugins → Installed Plugins and confirm the OTTO Pixel plugin is listed and active. 3. If it is deactivated, activate it and wait 30 seconds before proceeding. 4. Avoid reinstalling the plugin repeatedly — multiple reinstalls do not fix connection issues caused by crawl or bot-blocking problems. Step 2: Run and Complete a Site Audit Crawl OTTO cannot verify the pixel connection until a Site Audit crawl has finished successfully for the connected domain. This is the most common cause of the error and is often overlooked. 1. Log in to Search Atlas and navigate to OTTO SEO → Site Audit for your connected website. 2. Check the crawl status. If no crawl has run, or the last crawl did not complete, start a new crawl and wait for it to finish. Crawl time varies by site size — do not close the tab. 3. Once the crawl shows a completed status, return to the OTTO dashboard and check whether the pixel connection error has cleared. Important: A crawl that was interrupted or that returned errors may not satisfy the connection requirement. Confirm the crawl has fully completed before moving on. Step 3: Whitelist the OTTO Bot in Security and Cache Services Firewalls, CDNs, and caching plugins frequently block automated bots — including the OTTO crawler — which prevents OTTO from reaching your site to confirm pixel installation. You must whitelist the OTTO bot in every active security or cache layer. Cloudflare (most common) 1. Log in to your Cloudflare dashboard and select your domain. 2. Locate your firewall or WAF settings and add an allow rule for the OTTO bot. Contact our support team (see below) to obtain the exact IP range or user agent string to allowlist. 3. Alternatively, temporarily lower your security level, trigger a new Site Audit crawl to confirm the pixel connection clears, then restore your original security settings. 4. Once verified, add a permanent allow rule so the OTTO bot can reach your site going forward. Sucuri, Wordfence, or other security plugins 1. Open the settings for your active security plugin inside WordPress. 2. Find the IP allowlist or bot whitelist option and add the OTTO bot. Contact our support team (see below) to obtain the exact IP range or user agent string to allowlist. If you need further assistance, open 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 Meta Description Discrepancies Between Audit Tools

🧩 Why the Two Tools Can Show Different Results If Page Issues flags a page as missing a meta description but On-Page Audit shows one is present, this is almost always caused by an SEO plugin—such as Yoast SEO, Rank Math, or All in One SEO—injecting the meta description dynamically at render time rather than writing it directly into the page's static HTML. Here is what happens under the hood: - Page Issues crawls the raw HTML source of your page. If the meta description is added by a plugin after the page loads (via JavaScript or server-side logic tied to the plugin), the crawler may not detect it in the source. - On-Page Audit analyzes the rendered version of the page, which includes content added by plugins and scripts. This is why it correctly picks up the meta description. Neither tool is wrong—they are measuring different things. The discrepancy is a signal that your meta description delivery method may need attention. ⚠️ Common Plugins That Cause This Conflict The following plugins are known to inject meta descriptions in ways that can create detection gaps: - Yoast SEO — The most frequently reported cause. Yoast writes the meta description through its own output process, which can be missed by raw HTML crawlers depending on your server configuration and caching setup. - Rank Math — Similar behavior to Yoast; meta tags are managed through the plugin's rendering layer. - All in One SEO (AIOSEO) — Can produce the same discrepancy, particularly on pages using dynamic templates. - SEOPress — Occasionally causes conflicts on pages with heavy caching or CDN layers. 🛠️ How to Diagnose the Root Cause 1. Open the affected page URL in your browser. 2. Right-click anywhere on the page and select View Page Source (not Inspect Element). 3. Press Ctrl+F (or Cmd+F on Mac) and search for meta name="description". 4. If the tag is absent from the source but present in the Inspect Element panel, your plugin is injecting it dynamically. Continue to the resolution steps below. 5. If the tag appears in the source, the issue may be related to caching. Proceed to the cache-clearing step. ✅ Steps to Resolve the Discrepancy Step 1 — Check your plugin's output settings In your SEO plugin (Yoast, Rank Math, etc.), confirm that the meta description is actually saved for the affected page and that the plugin is set to output meta tags in the document <head>. Some plugins allow you to disable meta tag output globally or per post type. If you need further assistance, open 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 Images That Disappeared After Adding Map Code

🔍 What Happened to My Images? If your website images disappeared shortly after you added a map embed code (such as a Google Maps iframe), the two events are almost certainly connected. Map embed code that contains unclosed HTML tags, extra quotation marks, or misplaced characters can corrupt the surrounding HTML structure, causing images — and sometimes entire sections — to stop rendering. The good news is that your images have not been deleted. They are still stored in your media library. The issue is a broken HTML structure that prevents the browser from displaying them correctly. 🛠️ How to Fix the Problem 1. Open Website Studio. In the left sidebar, navigate to Website Studio (URL: /website-studio) and open the affected page in the editor. 2. Locate the map code block. Scroll to the section where you pasted the map embed code. Click on that block to select it. 3. Switch to the HTML/Code view. Inside the block editor, switch from the visual view to the HTML or code view so you can inspect the raw markup. 4. Remove the map code entirely. Delete all of the map embed code you pasted. Save the page and preview it to confirm whether your images reappear. If they do, the embed code was the cause. 5. Clean the embed code before re-adding it. Copy your map embed code into a plain-text editor (such as Notepad or TextEdit in plain-text mode) to strip any hidden characters. Check that every tag is properly closed — for example, an <iframe> must end with </iframe> — and that there are no stray quotation marks or extra brackets. 6. Re-paste the cleaned code. Return to the HTML view of the map block and paste the cleaned code. Save and preview the page again to verify that both the map and your images display correctly. ⚠️ Common Mistakes That Break Page Layouts - Unclosed tags: An <iframe> or <div> that is never closed will cause everything below it to be interpreted as part of that element, hiding images and other content. - Copied code from a web page instead of the embed tool: Copying map code directly from a rendered web page often picks up extra HTML that conflicts with your site's structure. Always use the official Share → Embed option from Google Maps or your map provider. - Pasting into the visual editor: Pasting raw HTML code into the visual (WYSIWYG) editor rather than the HTML/code view can introduce duplicate or malformed tags. Always paste embed code in the code view. - Extra line breaks or whitespace in the code: Some editors insert <br> or <p> tags inside your embed code when you paste, which can break it. ✅ Best Practices for Adding Map Embeds - Always use the HTML/code view of a block when pasting any embed code. - Validate your embed code at a free HTML validator (such as validator.w3.org) before adding it to your page. - After saving any code change, immediately preview the page on both desktop and mobile to catch layout issues early. - Keep a backup of your page content before making code edits — use the page duplication or version history feature in Website Studio if available. 💬 Still Need Help? If your images are still missing after following these steps, or if you are unsure which part of the code is causing the issue, our team is ready to assist. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 OTTO Pixel Not Detected During Site Audit

🧭 Overview If you have installed the OTTO Pixel on your WordPress site and the status still shows Not Detected, do not worry. In most cases, this is completely expected behavior — not a sign that something went wrong with your installation. This article explains why the Not Detected status can appear while a site audit is active and what you should do while you wait. ⚙️ Why This Happens When you connect your site to OTTO, the OTTO Pixel verification check runs automatically on a schedule based on how old the project is: every 15 minutes for projects under 2 hours old, every hour from 2 to 24 hours old, every 6 hours from 1 to 7 days old, and no automatic checks after 7 days. This means: - The Not Detected status may simply mean the next scheduled check has not yet run. - It does not necessarily mean the Pixel is missing, broken, or installed incorrectly. - A correctly installed Pixel on a new project is normally detected within about 15 minutes. Attempting to reinstall or troubleshoot the Pixel before the next scheduled check is unlikely to speed up detection. ✅ What to Do While You Wait 1. Go to OTTO SEO → All Sites (SEO Automation) using the left sidebar. 2. Locate your connected site and open its OTTO dashboard. 3. Wait for the next scheduled Pixel check to run — for a brand-new project this is normally within about 15 minutes. 4. Refresh the page and check the OTTO Pixel status again. 🔧 If the Status Still Shows Not Detected After the Next Check If the next scheduled check has run and the OTTO Pixel status still shows Not Detected, it is worth verifying your installation. Check that the Pixel code or plugin is active on your site and that nothing is preventing it from loading correctly (for example, a caching layer serving pages without the Pixel code). If you need further assistance, open 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 Site Recrawl Delays in Agent Hub

🔎 Overview After triggering a recrawl on a site, you may notice it does not immediately appear — or reappear — under Active Projects in the Agent Hub. This is a known delay that occurs while Search Atlas processes the new crawl data and syncs it across the platform. This article explains why it happens and what you can do to resolve it. ⚙️ Why the Delay Happens When a recrawl is initiated, Search Atlas goes through several background steps before the site is reflected in the Agent Hub: - Crawl queuing: Depending on site size and platform load, your recrawl may sit in a processing queue before it begins. - Data indexing: Once crawling is complete, the system needs time to index the updated site data before it can be surfaced in Active Projects. - Sync lag: There is a short synchronisation window between when crawl data is processed and when the Agent Hub refreshes its project list. In most cases, the site will appear in Active Projects within a few minutes to a few hours depending on the size of the site and current system load. 🛠️ Steps to Resolve the Issue 1. Wait and refresh: After a recrawl, wait at least 10–15 minutes, then hard-refresh your browser (Ctrl + Shift + R on Windows, Cmd + Shift + R on Mac) and navigate back to the Agent Hub at Left sidebar → Home → Agent Hub (URL: /home). 2. Confirm the recrawl completed: Go to Left sidebar → Site Metrics (Site Explorer) (URL: /site-explorer/list) and locate your site. Check whether the crawl status shows as completed. If it still shows as in progress or queued, the Agent Hub will not update until crawling finishes. 3. Check that the project is active: Inside the Agent Hub, confirm the project has not been paused or deactivated. A project in a paused state will not surface in the Active Projects list even after a successful recrawl. 4. Re-enter the Agent Hub: Navigate away from the Agent Hub page and return to it via Left sidebar → Home → Agent Hub. This forces the page to re-fetch the latest project data. 5. Clear browser cache: Cached data can sometimes prevent updated project status from loading. Clear your browser cache, then log back in and check Active Projects again. 📊 What to Expect After a Successful Recrawl Once the recrawl has fully completed and data has been indexed, your site will appear in Active Projects in the Agent Hub with refreshed metrics. Any previously flagged issues will be updated to reflect the current state of the site. If the project was visible before the recrawl, it should return to the same position in your Active Projects list. 💡 Tips to Avoid Future Delays - Avoid triggering multiple recrawls in quick succession on the same site — this can push your crawl further back in the queue. - Schedule recrawls during off-peak hours if your site is large, as processing times can vary based on platform load. - After initiating a recrawl, monitor the crawl status in Site Explorer before checking the Agent Hub, so you know when to expect the update. 🆘 Still Not Showing Up? If your site has not appeared in Active Projects after several hours and the recrawl shows as completed in Site Explorer, there may be an underlying issue that requires investigation. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔗 Fix GSC 'No Project Associated' Connection Error

🔍 What This Error Means When you connect your Google Search Console (GSC) account to Search Atlas and see the message "Your connected GSC Account doesn't have any project associated", it does not mean your GSC account is disconnected or your credentials are wrong. It means Search Atlas could not find a domain property in your GSC account to link to a project. Search Atlas requires a domain-level GSC property (for example, sc-domain:example.com) to activate a project. URL prefix properties (for example, https://www.example.com/ or https://example.com/) are verified in GSC but are not compatible with project activation in Search Atlas. This is the most common cause of this error. ⚠️ URL Prefix vs. Domain Properties: Key Difference Google Search Console offers two property types: - URL prefix property — covers only URLs that begin with a specific prefix, such as https://www.example.com/. Verification is done via HTML file, meta tag, Google Analytics, or Google Tag Manager. - Domain property — covers all URLs across all subdomains and protocols (http, https, www, non-www) for a root domain. Verification is done via DNS TXT record only. Search Atlas connects to GSC at the domain property level to ensure full site coverage and accurate data aggregation. A verified URL prefix property alone will not satisfy this requirement. ✅ How to Resolve the Error To resolve this error, you need to add a domain property in Google Search Console for your root domain and complete DNS TXT record verification. Once your domain property is verified in GSC, Search Atlas will be able to detect it and activate your project. To add a domain property, go to Google Search Console at search.google.com/search-console, sign in with the same Google account connected to Search Atlas, and add a new property selecting Domain as the property type. Enter your root domain without any prefix (for example, example.com). Google will provide a DNS TXT record — add this record through your domain registrar or DNS provider (such as GoDaddy, Namecheap, or Cloudflare). DNS propagation can take a few minutes up to 72 hours, but verification usually completes within an hour. Once GSC confirms your domain property is verified, return to Search Atlas. The platform should detect the domain property and allow your project to activate. If the error persists after your domain property is verified in GSC, please have the following information ready when you contact us: - The exact error message you see in Search Atlas - Your project name or domain - The Google account email used for the GSC connection If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

Troubleshoot Schema Markup Errors in Search Atlas

Overview Schema markup added through Search Atlas should appear in your page source as valid JSON-LD. If you followed the setup steps but the schema is missing or returning an error, this article explains the most common causes and what to check in your Brand Vault settings. Common Reasons Schema Markup Fails - Incorrect configuration in Brand Vault: The JSON-LD block or entity details may have been entered in the wrong area or left incomplete. - Malformed JSON syntax: A missing comma, bracket, or quotation mark breaks the entire schema block. - Knowledge Graph fields left incomplete: Required entity fields were skipped, preventing the schema from generating correctly. - Page not yet re-crawled: The schema was saved correctly but the page source reflects a cached version. - Conflicting schema on the page: An existing schema block on your site is overriding or duplicating the one set in Search Atlas. What to Check in Brand Vault 1. Open Brand Vault from the header apps-grid icon → More Features → Brand Vault. 2. Verify your schema entry. Confirm that the JSON-LD block has been entered in the correct area of Brand Vault for the service page you are testing, and that the URL associated with it matches the page you are checking. 3. Validate the JSON-LD syntax. Copy your schema text and paste it into a JSON validator such as jsonlint.com or the Google Rich Results Test. Common issues include: missing closing braces }, unmatched quotation marks, trailing commas after the last property, and incorrect nesting of @type values. 4. Correct and re-save the schema. If errors are found, fix the JSON and re-enter the corrected version in Brand Vault, then save your changes. 5. Review Knowledge Graph settings. Within Brand Vault, ensure all required entity fields are filled in for your business type. Incomplete Knowledge Graph data can prevent schema from rendering even if the JSON-LD block itself is valid. Complete as many fields as possible. 6. Test the page source. After saving, open the service page URL in a browser, right-click, and select View Page Source. Use Ctrl+F (or Cmd+F on Mac) and search for application/ld+json to confirm the schema block is present. 7. Check for caching delays. If the schema does not appear immediately, allow time for the page to be re-crawled or clear your site cache and test again. 8. Check for conflicting schema. If a schema block already exists on your site outside of Search Atlas, it may conflict with or override the one you configured. Review any existing structured data on the page. If the Issue Persists If you have verified your Brand Vault configuration, corrected any JSON syntax errors, completed all Knowledge Graph fields, and confirmed the page is not cached — but the schema still does not appear in the page source — please reach out to our support team. To help us investigate quickly, have the following ready: the exact service page URL, the JSON-LD block you entered, and a screenshot or copy of the page source showing the missing schema. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛡️ Troubleshoot Brand Vault Creation Failures: Firewall & CDN Blocking

Overview When you create a Brand Vault in Search Atlas, the platform runs a Site Audit to scan your website and pull brand data automatically. If your site is protected by a firewall, CDN, or security plugin, it may block the Search Atlas crawler — causing the Site Audit to fail and the Brand Vault to not complete setup. What May Be Causing This Brand Vault creation failures are commonly caused by security tools on your website — such as a firewall, CDN, or WordPress security plugin — blocking automated crawler traffic from Search Atlas before it can scan your site. You may be experiencing this if any of the following apply: - Your Site Audit shows a failed or stuck status when creating a Brand Vault. - Your website uses a CDN such as Cloudflare, a server-level firewall, or a WordPress security plugin such as Wordfence or Sucuri. - Your hosting provider has bot-protection or rate-limiting rules enabled. How to Resolve This To fix a Brand Vault creation failure caused by crawler blocking, you will need to whitelist the Search Atlas crawler within whichever security tool is protecting your site. The exact steps will vary depending on your firewall, CDN, or security plugin — consult your provider's documentation for instructions on how to allow specific crawlers or IP addresses. To get the specific Search Atlas crawler IP addresses you need to whitelist, please reach out to the support team. They can provide the current IP ranges so you can add them to your allowlist and complete the Brand Vault setup. Once whitelisting is in place, return to Search Atlas and retry the Brand Vault creation to trigger a new Site Audit. When Contacting Support, Have Ready - The domain you are trying to add to your Brand Vault. - The name of the firewall, CDN, or security plugin protecting your site (e.g., Cloudflare, Wordfence, Sucuri, cPanel firewall). - Any error messages or status indicators shown during Brand Vault creation. - The approximate time the failure occurred. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🗺️ Fix Scheduled Heatmap Scans Running at Wrong Time

🔍 Overview If your scheduled Local SEO Heatmap scans are running at a different time than you intended, this article explains what to check and what information to have ready when contacting support for investigation. 🕐 Why the Scan May Run at the Wrong Time Incorrect scan timing is a known issue that our team investigates on a per-account basis. Possible contributing factors can include how the schedule was configured and how time values are interpreted by the platform, but the exact cause needs to be confirmed by our support team reviewing your specific setup. 🛠️ What to Do If Your Scans Are Running at the Wrong Time 1. Note the heatmap name and the schedule you set. Record exactly what time and frequency you entered when creating or last editing the scan schedule. 2. Record the actual run times. Check your heatmap history and note the timestamps at which the scans are actually executing. 3. Check your account timezone setting. Navigate to your account or profile settings and confirm which timezone is currently configured. Note this value. 4. Contact support. Share the heatmap name, your intended schedule, the actual run times observed, and your account timezone with our team so they can investigate the root cause and correct the behavior on the backend. Because this issue requires backend investigation, do not delete and recreate your heatmap schedule until support has reviewed the problem — doing so may remove the data needed to diagnose the issue. 📋 What to Have Ready When You Escalate - The name of the affected heatmap(s) - The scheduled time you entered (including any timezone you selected during setup) - The actual timestamps the scans ran, copied from the platform - Your account timezone as shown in your profile or account settings ❓ Still Seeing Incorrect Scan Times? If you need further assistance, open 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 Site Audit and OTTO Tasks

🔍 Overview Some customers notice that Site Audit crawls or OTTO AI agent tasks start but never seem to finish. In most cases the job is still running — it is processing in the background and will complete. This article explains the common causes, what to check, and how to keep things moving. ⚙️ Why Tasks Appear Stuck There are several known reasons a Site Audit or OTTO task may look frozen: - JavaScript rendering slows crawls significantly. When JS rendering is enabled, audits can take up to 13–17 hours to complete. This is expected behaviour, not a bug. The crawl progress bar may appear idle for long periods. - Worker interruption during retry. If a background worker pod is restarted while a task is retrying, the job can enter an in_progress state that does not resolve on its own. This requires a manual refresh or re-trigger. - Recrawl frequency set to "never reprocess". If a site's recrawl frequency was not set correctly, the audit will not queue a new crawl. It will appear stuck because no reprocess is scheduled. - Orphaned reprocess tasks. In rare cases, an internal reprocess task becomes detached from the main audit job. The status reads "still processing" indefinitely until the orphaned task is cleared. 🚀 Steps to Resolve a Stuck Task 1. Go to Left sidebar → OTTO SEO → All Sites (SEO Automation) (URL: /seo-automation-v3). 2. Locate the affected site or project. Check the current status label — if it shows in_progress or still processing for more than 18 hours, the task may need a manual reset. 3. Click Refresh data on the project dashboard. This triggers a status sync and can resolve misread processing states. 4. If the audit does not update after refreshing, open the project and use the Create Project option to re-initiate a fresh audit run for the affected domain. 5. If you recently enabled JS rendering and the audit has been running for fewer than 17 hours, wait for the crawl to complete before taking further action. JS-rendered audits are significantly slower by design. 📊 Check Your Recrawl Frequency Setting A missing or incorrect recrawl frequency is a common hidden cause of audits that never restart. To verify your setting: 1. Go to Left sidebar → OTTO SEO → All Sites (SEO Automation). 2. Select the affected site. 3. Review the crawl schedule or recrawl frequency setting. If it is set to never reprocess, update it to your preferred frequency (daily, weekly, or monthly). 4. Save the change and trigger a manual crawl to confirm the audit queues correctly. 💡 A Note on Regulated Industry Instructions (FDA and Similar) If you have added compliance instructions — such as FDA advertising guidelines — to your OTTO or AI agent workflow, it is important to understand how the agent reads and applies those instructions: - OTTO and the AI agent process your custom instructions on a per-task basis. If a task was already queued or cached before you added the instructions, it may complete using the previous configuration. - To ensure compliance rules are applied, add your instructions before starting a new task. Do not rely on mid-run instruction changes affecting tasks already in progress. - After saving compliance instructions, trigger a fresh audit or task run so the agent picks up the updated configuration from the start. - Always review AI-generated suggestions before publishing. The AI agent surfaces recommendations based on SEO best practices. You are responsible for verifying that any content or metadata changes meet your regulatory requirements before they go live. Search Atlas does not validate suggestions against specific regulatory frameworks such as FDA, HIPAA, or FTC guidelines. Compliance review remains the responsibility of your team. 🛠️ When to Contact Support Reach out if: - A task has been stuck for more than 18 hours and a manual refresh or re-trigger has not resolved it. - Your compliance instructions are consistently being ignored across multiple fresh task runs. - You see an audit looping between queued and in_progress repeatedly without completing. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Cloud Stacks Stuck Partially Published Fix

🔍 Overview Some users reported that their Cloud Stacks (Google stacks) stopped publishing partway through deployment — for example, showing 12 of 15 sites completed — and remained stuck in that state for many days despite having active credits. This was caused by a platform-level publishing bug that prevented stacks from completing the final publication stage automatically. Engineering investigated the issue (tracked internally as SPE-1014) and released a fix that is now live in production. If your stacks were affected, they should now resume and complete normally. ✅ What Was Causing This A bug in the Cloud Stacks publishing pipeline caused certain stacks to get stuck before the final publish stage. Affected stacks included those that had been in a partially published or generating state for an extended period — in some cases more than two weeks — without any progress. This was not caused by insufficient credits or an account configuration issue. It was a backend platform defect that has since been resolved. 📋 Steps to Check Your Cloud Stacks Status 1. Navigate to the Cloud Stacks section of the platform. 2. Review the list of your stacks and check the publication progress for each one (for example, how many of the total sites have been published). 3. If any stacks are still showing as incomplete, note how long they have been in that state. 4. Refresh the page and wait a few minutes — now that the fix is live, stacks that were previously stuck should begin completing automatically. 5. If progress resumes and all sites publish successfully, no further action is needed. ⚠️ When to Reach Out for Help The engineering fix is live and should resolve stacks that were stuck at the time of the incident. However, if you check your stacks and notice any of the following, contact our support team directly: - A stack has not made any progress for more than 48 hours after the fix was released. - Your stack count is still not reaching the expected total (for example, remaining at 12 of 15 with no movement). - You see an error message or an unexpected status on a stack you recently created. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Fix a Failing On-Page Audit

🔍 What Does a 'Failed' Audit Mean? When an on-page audit returns a Failed status, it means Search Atlas was unable to crawl or analyse the target URL successfully. This is almost always caused by an issue on the website side rather than a platform bug. The steps below walk you through the most common causes and how to fix each one. ⚙️ Step 1 — Check That the URL Is Correct A simple typo is the most common reason an audit fails. Before investigating further, verify the following: - The URL includes the correct protocol: https:// or http:// - There are no trailing spaces or hidden characters - The page actually exists — paste the URL into a browser and confirm it loads - You are targeting a specific page URL, not just a root domain (e.g. https://oakknollranch.com/about/ rather than oakknollranch.com) 🚧 Step 2 — Confirm the Page Is Publicly Accessible Search Atlas crawls pages the same way a search engine bot would. If the page is restricted, the audit will fail. Check for these blockers: - Password protection: The page or the whole site is behind a login, staging lock, or maintenance mode - Robots.txt blocking: Your robots.txt file may be disallowing crawlers. Visit https://yourdomain.com/robots.txt and look for Disallow: / or rules that block all user agents - Noindex / nofollow headers: Some server configurations block access at the HTTP header level - Geo-restrictions or firewall rules: The server may be blocking requests from IP addresses outside a specific region If any of these apply, temporarily lift the restriction, re-run the audit, and then restore your settings. 📡 Step 3 — Check the Page's HTTP Status Code The page must return a 200 OK response for the audit to complete. Use a free HTTP status checker tool and enter your URL. Common problem codes include: - 301 / 302: The URL redirects to another page — use the final destination URL instead - 403 Forbidden: The server is actively blocking outside access - 404 Not Found: The page no longer exists or the URL has changed - 500 / 503: The server is experiencing errors — wait a few minutes and try again ⏱️ Step 4 — Wait and Retry Occasionally, a page may time out during the crawl due to slow server response times or temporary downtime. If you have checked all of the above and found no issues, wait a few minutes and then navigate to the On-Page Audit section of the platform to locate the failed audit and run it again. If the audit continues to fail after confirming the URL is correct, the page is publicly accessible, and the server is returning a 200 status, please reach out to support for further 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 Cloud Stack Showing Zero Deployed Providers

Overview Your Cloud Stack showing a deployed provider count of zero despite stacks being live requires the Search Atlas support team to investigate and resolve on your account. This article explains how to contact support effectively so your case can be resolved as quickly as possible. If you are unable to resolve an issue after following these steps, contact the Search Atlas support team via live chat in the dashboard. Issue 1: Cloud Stack Shows Zero Deployed Providers If your Cloud Stack report shows a deployed provider count of 0, this is a known display issue that the Search Atlas support team can correct on your account. There are no self-serve steps that reliably fix this — an agent must investigate your specific account configuration. To get this resolved as quickly as possible, contact the Search Atlas support team via live chat in the dashboard and provide the following information: - Your project name - Your Cloud Stack order number - A brief description that your deployed provider count is showing as zero The support team will review your account, correct the display count, and confirm when your Cloud Stack data is accurately reflected. Key Things to Remember - A zero provider count in Cloud Stack is a known display issue — it does not necessarily mean your stacks failed to deploy. - For both issues, contacting the Search Atlas support team via live chat in the dashboard with your order number is the fastest path to resolution.

🛠️ Fix Knowledge Base Trust FAQ Deployment Errors

🔍 Overview When deploying your Knowledge Base Trust FAQ schema, you may encounter a deployment error that reads something like "questions should have answers" — even when all your visible Q&A pairs appear to be fully filled in. This article explains why this error occurs and how to resolve it quickly. ⚠️ Why This Error Happens The "questions should have answers" error is a schema validation failure. It does not mean that your completed Q&A entries are incorrect. It means that one or more empty Q&A slots exist in your deployment set alongside your filled entries. This is a common source of confusion: the platform may display 8 completed Q&A pairs, but if additional blank slots are present in the same deployment set — even if they appear empty or unused — the schema validator treats them as incomplete entries and blocks deployment. Common reasons empty slots appear: - Extra rows were added while building out Q&As and left blank. - A Q&A entry was partially started (e.g., a question was typed but no answer was saved) and then abandoned. - Slots were duplicated accidentally during editing. ✅ How to Fix the Error 1. Navigate to OTTO SEO → Knowledge Base in the left sidebar of your Search Atlas dashboard. 2. Open the FAQ deployment set that is producing the error. 3. Scroll through all Q&A slots — including those below your completed entries — and look for any rows where the question, the answer, or both fields are empty. 4. Select each empty slot and click Delete to remove it entirely. Do not leave any blank rows in the set. 5. Once all empty slots have been removed, save your changes. 6. Attempt deployment again. The schema validator should now pass without errors. 💡 Tips to Prevent This Error in Future - Only create a new Q&A slot when you are ready to fill it in completely. Avoid saving partial entries. - Before every deployment, do a quick scroll to confirm no empty rows exist below your last completed Q&A pair. - If you need a placeholder while drafting content, write a temporary answer so the slot is never truly empty. - After deleting a Q&A, check that the slot itself is also removed — not just cleared of its content. 🚫 What This Error Is Not It is important to note that this error is not related to Google Business Profile publishing. The Knowledge Base Trust FAQ schema is a separate feature and workflow. If you have seen guidance suggesting this error is connected to Google Business Profile, that information is incorrect. This error is caused exclusively by empty Q&A slots within the FAQ schema deployment set, and is resolved by deleting those slots as described above. 🙋 Still Seeing the Error? If you have deleted all empty slots and the error persists, it is possible a hidden or cached slot is still being detected by the validator. Try the following: - Refresh the page and reopen the FAQ deployment set before attempting deployment again. - Check whether any Q&A entry has a question filled in but is missing a saved answer (or vice versa) — both fields must be fully completed and saved. - If the error continues after these steps, our team can inspect the deployment set directly on your account. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Site Auditor Error Banner Link Fixed

A bug affecting the Site Auditor error banner has been resolved. The help link displayed when a site audit gets stuck was incorrectly exposing SearchAtlas branding to white-label platform users, which has now been fixed. ✨ What's New The help link inside the Site Auditor error banner — shown when a site audit appears stuck — has been corrected. Previously, this link was routing users to a resource that revealed SearchAtlas branding, breaking the white-label experience for GHL platform users. The link now behaves as expected and maintains a consistent, branded experience. 📋 What to Expect If you encounter an error banner in the Site Auditor indicating that your audit is stuck, the help link will now direct you to the appropriate support resource without exposing any unintended branding. No action is required on your end — the fix has been applied automatically. This change only affects users on the GHL white-label platform who previously saw the error banner. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔧 Fix Search Atlas Plugin PHP Incompatibility Error

What Is This Error? When you activate the Search Atlas WordPress plugin on a server running an outdated version of PHP, WordPress may display a critical error or a blank white screen, making your site temporarily inaccessible. This happens because newer versions of Search Atlas require a minimum PHP version to run correctly. What to Do When You See This Error Because the specific PHP version requirement and the exact steps to resolve this error can vary depending on your hosting environment and your version of the plugin, we recommend taking the following general approach and then reaching out to our team for confirmation: 1. Deactivate the plugin. If your WordPress admin dashboard is still accessible, go to Plugins → Installed Plugins and deactivate Search Atlas. If your dashboard is inaccessible due to the error, contact your hosting provider — they can deactivate the plugin at the server level to restore access to your site. 2. Check your current PHP version. Log in to your hosting control panel and locate the PHP version setting. If you are unsure where to find this, your hosting provider's support team can confirm your current PHP version and how to change it. 3. Upgrade your PHP version. Work with your hosting provider to upgrade PHP to a version compatible with Search Atlas. Your hosting provider can complete this upgrade and advise on any compatibility considerations for your other plugins and themes. 4. Re-activate Search Atlas. Once your PHP version has been updated, go to Plugins → Installed Plugins in your WordPress dashboard and click Activate next to Search Atlas. 5. Verify the site is working. Visit your website and confirm the error is resolved. Then log in to Search Atlas and check that the plugin is connected correctly. Before You Upgrade PHP Upgrading PHP can affect other plugins and themes on your site. It is good practice to take a few precautions: - Back up your site before making any server-level changes. - Check compatibility of your other plugins and themes with the new PHP version before upgrading. - Test on a staging environment first if your site is business-critical. Need Help Confirming the Right PHP Version? If you are unsure which PHP version is required for your specific version of Search Atlas, or if you have followed the steps above and are still seeing errors, please reach out to our support team with the following information ready: your current Search Atlas plugin version, your current PHP version, and the exact error message you are seeing. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Fix Site Audit Quota Limit Errors Fast

🔍 Understanding the Quota Error You may see a quota limit error in Site Audit — or across other Search Atlas features — even when your account dashboard shows available quota remaining. This is a common source of confusion, and the fix is straightforward once you understand why it happens. The error does not mean your overall account quota is exhausted. It means that your active Site Audit projects are collectively holding quota allocation that has not yet been released. Search Atlas reserves quota for each audit you create, whether that audit is actively crawling or sitting idle. 📊 Why Held Quota Causes Errors When you create a Site Audit project, the system pre-allocates a portion of your quota to that project based on its configured crawl size. This reserved quota counts against your available limit even if the audit has already finished or is no longer needed. As a result: - Your account summary may show remaining credits, but those credits are locked to existing audit projects. - Attempting to run a new audit, re-crawl a site, or use quota-dependent features triggers an error because no free quota is available to assign. - The issue compounds if you have multiple completed or unused audits still active in your project list. 🗑️ How to Fix It: Delete Unused Site Audits The fastest way to resolve quota limit errors is to delete Site Audit projects you no longer need. Deleting a project immediately releases its reserved quota back to your account pool, making it available for new audits and other features. 1. Log in to your Search Atlas account. 2. Navigate to the Site Audit section of the platform. 3. Open your list of existing audit projects. 4. Review each project and identify audits that are completed, outdated, or no longer relevant to your workflow. 5. Select the audit project you want to remove and click the Delete option. 6. Confirm the deletion when prompted. 7. Repeat for any additional unused audits. Once deleted, the quota previously held by those projects is freed immediately. You should be able to create new audits or use other quota-dependent features without errors. 💡 Best Practices to Avoid Future Quota Errors Keeping your Site Audit project list tidy prevents this issue from recurring. Follow these habits to stay within your quota limits: - Delete audits after actioning results. Once you have reviewed an audit's findings and made your site improvements, delete the project to free up quota for future crawls. - Avoid creating duplicate audits. If you need to re-crawl a site, consider deleting the existing audit project first rather than creating a new one alongside it. - Periodically review your active audit list. Make it a habit to remove stale or redundant projects before they accumulate and exhaust your available quota. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

Fix a Persistent Indeed Link in Cloud Stacks

🔍 What Is This Issue? Some users have reported that an Indeed URL — often linked to a company they do not own — keeps reappearing in their Cloud Stacks footers and Knowledge Graph even after they delete it. Because the stale value is retained at the database level, deleting it through the platform UI alone will not permanently remove it from previously created stacks. Resolving this issue requires escalation to a support engineer. ✅ Steps to Take Before Contacting Support 1. Check your Knowledge Graph settings: Navigate to your Knowledge Graph settings and look for any Indeed URL stored under your brand profile. If you see it, attempt to delete or clear it and save your changes. This ensures the UI-level value is removed, even though the underlying database-level value will still need to be cleared by an engineer. 2. Identify affected Cloud Stacks: Go to your Cloud Stacks section in the platform and review your existing stacks. Note which stacks are displaying the incorrect Indeed link in their footers. Record the names or IDs of these stacks so you can share them with the support team. 3. Confirm the Indeed URL is not intentional: Make sure the URL does not belong to a legitimate profile associated with your brand. If it is definitely not yours, proceed to contact support with that confirmation. 4. Gather key details to share with support: Before reaching out, have the following ready: the exact Indeed URL that keeps appearing and the names or IDs of the affected Cloud Stacks. 🧹 What the Support Engineer Will Do Once you contact support, a support engineer will review your account, identify the affected Cloud Stack records containing the stale Indeed URL, and manually remove the value at the database level. They will confirm once the removal is complete so you can verify the footers no longer display the incorrect link. To get this resolved, please contact the Search Atlas support team via live chat and share the details you gathered above. The support team will escalate to an engineer who can perform the database-level removal — this is the confirmed path to a permanent fix.

🛠️ Troubleshooting Cloud Stack Generation Failures

If you're seeing the message "Cloud stack generation failed. Please try generating again," this article walks you through the specific causes of this error and the exact steps to resolve it. Cloud stack failures are most commonly linked to image upload issues or asset problems that prevent the generation process from completing. 📍 Where to Find It Cloud Stacks is located at Left sidebar → Authority → Cloud Stacks. This is where you initiate generation and where any error messages will appear. 🛠️ Step-by-Step 1. Check your uploaded images before generating. The most common cause of this error is an incompatible or corrupted image file. Make sure every image you upload meets the following requirements: - File format: JPG, JPEG, or PNG only - File size: keep each image under 5 MB - Avoid images with special characters in the file name (e.g., #, &, %) - Do not upload screenshots taken directly from a browser — export or save the image file properly before uploading 2. Remove and re-upload your images. If you already uploaded images before the error occurred, delete them from the upload area and re-upload fresh copies that meet the requirements above. 3. Clear your browser cache and reload the page. Navigate away from Left sidebar → Authority → Cloud Stacks, clear your browser cache (or open a private/incognito window), then return to the page before attempting generation again. 4. Try a different browser. If the error persists after re-uploading, attempt the generation in a different browser (Chrome or Firefox are recommended) to rule out a browser-specific conflict. 5. Retry the generation. Once your images are confirmed to be in the correct format and size, click the generate button again. Do not click multiple times in quick succession — allow the process to fully run before retrying. 6. Check for platform status issues. If none of the above resolves the error, the issue may be a temporary infrastructure problem. Wait a few minutes and try again before escalating. ✅ How to Confirm It Worked A successful cloud stack generation will show a status change from "Failed" or "Pending" to "Complete" within the Cloud Stacks dashboard at Left sidebar → Authority → Cloud Stacks. You should be able to view and access your generated cloud stack assets directly from that page. If the status does not update within a few minutes of retrying, or if the failure message reappears immediately, the issue likely requires hands-on support. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

How to Fix an Incompatible Google Maps URL in Cloud Stack

This article explains what to do when a Google Maps URL you enter in Cloud Stack is flagged as incompatible or fails to load correctly — and how to resolve the format issue so your report data populates as expected. 🔍 What Causes the Incompatible URL Error Cloud Stack requires a specific Google Maps URL format to correctly pull location data. If you paste a URL directly from your browser's address bar after searching on Google Maps, the format may include parameters (such as search query strings or shortened redirect URLs) that Cloud Stack cannot parse. This mismatch causes the URL to be rejected or the location data to fail to load. 🛠️ Step-by-Step: Use the Correct Google Maps URL Format 1. Go to Google Maps and locate the business you want to add. Search for the business and open its full listing page. 2. Copy the URL from the address bar only after the page has fully loaded and the listing is open. The correct URL should point directly to the place listing, not to a search results page. 3. Avoid using shortened URLs (e.g. maps.app.goo.gl links) or URLs copied from a Google Search results page. These formats are not supported by Cloud Stack and will trigger the incompatibility error. 4. Paste the correctly formatted Google Maps URL into Cloud Stack. If the URL is in the supported format, Cloud Stack will accept it and begin pulling location data. 5. If the URL still shows as incompatible, double-check that you are on the place's dedicated listing page in Google Maps (not a search results view or directions page) before copying the URL. ✅ How to Confirm It Worked After entering the correctly formatted URL, Cloud Stack should accept the entry without an incompatibility error and begin loading the associated Google Maps location data. If you continue to see an error, note the exact URL you used and the exact error message displayed, then escalate to support. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Fix Platform Loading and Account Data Issues

🔍 Overview If pages are failing to load, dropdowns are unresponsive, or your purchased data — such as links, reports, or project history — appears missing, this guide walks you through recommended steps to restore normal platform behaviour. These issues are generally related to platform loading problems or account data integrity and typically require our team to investigate on the backend. ⚡ Step 1: Perform a Hard Refresh and Clear Your Cache A corrupted browser cache is a common cause of loading failures. Follow these steps before anything else: 1. Force a hard refresh using your browser's keyboard shortcut for a full page reload. 2. If the issue persists, open your browser settings and clear cached data and cookies for the Search Atlas domain. 3. Reload the page after clearing the cache. If you use browser extensions such as ad blockers or privacy tools, temporarily disable them — they can interfere with page loading and rendering. 🌐 Step 2: Try a Different Browser or Incognito Window Browser-specific conflicts can prevent elements from loading correctly. To isolate the cause: - Open Search Atlas in a private or incognito window using the same browser. - If that works, try a different browser entirely (e.g. Chrome, Firefox, or Edge). - If the platform loads correctly in a clean environment, the issue is browser-side and clearing your cache in Step 1 should help resolve it. 🔄 Step 3: Log Out and Log Back In An expired or corrupted session can cause dropdowns and page sections to fail silently. To reset your session: 1. Log out of your Search Atlas account. 2. Wait a moment, then log back in with your credentials. 3. Navigate to the affected area and check whether it now loads correctly. 📊 Step 4: Check Whether Your Purchases and Data Are Visible If data such as links, reports, or project history appears missing after a loading problem, it may be a display issue rather than a loss of data. To check: - Navigate directly to the relevant tool or project within the platform. - If specific items still do not appear after following the steps above, note the affected section and contact our team (see below) — our team can investigate account data integrity on the backend. ⚙️ Step 5: Escalate to Our Team If the steps above do not resolve the loading or data issue, our support team will need to investigate on the backend. To help us resolve this as quickly as possible, please have the following ready when you reach out: - Your project name or the specific area of the platform affected. - A description of what you see (e.g. blank page, unresponsive dropdown, missing data). - Any error messages displayed, including exact wording. - The approximate time the issue started. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🗺️ Fix Topical Map and Crawl Settings Errors

🔍 Overview When creating a topical map in Search Atlas, you may run into two common issues: a URL validation error that greys out the input field, or OTTO only returning results for one page even though your site has many more. Both issues are usually caused by incorrect URL formatting or misconfigured crawl settings. This article walks you through how to fix each problem. ⚠️ Issue 1: URL Field Shows a Validation Error and Is Greyed Out This error appears when the URL entered does not match the expected format. The field becomes uneditable until the issue is resolved. Common causes: - Missing or incorrect protocol (e.g., typing www.example.com instead of https://www.example.com) - A trailing space before or after the URL - Special characters or unsupported symbols in the URL - Entering a URL path instead of the root domain (e.g., https://example.com/blog instead of https://example.com) How to fix it: 1. Go to Left sidebar → Content → Topical Maps. 2. Click to create a new topical map. 3. Clear the URL field completely. 4. Re-enter your URL in the correct format: https://www.yourdomain.com — include the protocol and avoid any trailing slashes or spaces. 5. Wait for the validation indicator to confirm the URL is accepted before proceeding. 📄 Issue 2: OTTO Only Shows Results for One Page If OTTO is crawling your site but only returning data for a single page, your Pages to Crawl limit or project URL is likely limiting the number of pages analysed. Common causes: - Pages to Crawl is set to 1 (or a very low number), meaning only the root URL is crawled - The project was set up on the wrong URL (a single page or subdirectory instead of the root domain) - The sitemap has not been submitted or is not accessible - The website blocks crawlers via robots.txt rules (only relevant if Crawl Criteria is set to Respect robots.txt in your crawl settings) How to fix it: 1. Navigate to Left sidebar → OTTO SEO → SEO Automation (URL: /seo-automation-v3). 2. Open your project and click the Autopilot / Smart Crawl card to open the OTTO SEO Settings modal. 3. Increase Pages to Crawl so it covers the number of pages your site contains (adding a small buffer). 4. Ensure the crawl scope is set to your full root domain, not a specific subfolder or page. 5. If you have a sitemap, confirm the URL is entered correctly in the sitemap field (e.g., https://www.yourdomain.com/sitemap.xml). 6. Save your settings and re-run the crawl. Once the crawl completes, return to Left sidebar → Content → Topical Maps and generate or refresh your topical map. You should now see data across all crawled pages. ✅ Best Practices for Topical Map Setup - Always use the full root domain with https:// when entering your URL. - Set Pages to Crawl high enough to cover your full site (with a small buffer). - Submit an XML sitemap to help OTTO discover all pages faster. - Check your robots.txt file if Crawl Criteria is set to Respect robots.txt — otherwise OTTO ignores it. - Re-run the crawl after any major site changes before generating a new topical map. 💬 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 Scan Failures in HubSpot

🧭 Overview After pasting the OTTO Pixel into HubSpot, some users see a scan failure even though the code appears to be installed correctly. In most cases, the root cause is not the installation itself — it is a security layer on the hosting environment that blocks the Search Atlas crawler before it can verify the Pixel. This article walks you through a correct HubSpot installation and, critically, how to whitelist the Search Atlas crawler on servers and security tools that are not Cloudflare. 📋 Step 1: Install the OTTO Pixel in HubSpot 1. In Search Atlas, go to OTTO SEO → All Sites (SEO Automation) using the left sidebar (URL: /seo-automation-v3). 2. Open your OTTO project and copy the full Pixel script snippet. 3. Log in to your HubSpot account and navigate to the Settings area, then look for the section where you can add custom tracking or header code to your site pages (the exact menu label may vary by HubSpot plan and version — consult HubSpot's current documentation if needed). 4. Paste the OTTO Pixel snippet into the header code field for your site, then save your changes. 5. Return to Search Atlas and trigger a new scan to confirm detection. If the scan still fails after completing these steps, proceed to the crawler whitelisting section below. 🛡️ Step 2: Whitelist Search Atlas Crawlers (Non-Cloudflare Environments) If your client's site does not use Cloudflare, the crawler may be blocked by one of the following: a Web Application Firewall (WAF), a WordPress security plugin, a server-level firewall rule, or a CDN provider. Use the relevant section below to allow the Search Atlas crawler through. 🔎 Identify the Search Atlas Crawler Details Before whitelisting, you need the crawler's identifiers. Allow access for the following: - User-Agent string:SearchAtlasBot - IP ranges: To obtain the current crawler IP list, open the chat widget in the bottom-right corner of the platform and type human teammate — a member of our team will provide the up-to-date IP ranges, as they may be updated periodically. ⚙️ Whitelisting by Environment Type WordPress Security Plugins (e.g., Wordfence, Sucuri, or similar WAF/security plugins) 1. Open the plugin's settings dashboard in WordPress. 2. Locate the Whitelisting, Allowlist, or Trusted Bots section (the exact label varies by plugin). 3. Add SearchAtlasBot as a trusted User-Agent. 4. If the plugin allows IP-based rules, also add the Search Atlas crawler IPs obtained from the support team. 5. Save settings and re-run the OTTO scan. Server-Level Firewalls (Nginx, Apache, or similar) 1. Access your server and open the relevant configuration file for your web server or firewall tool. 2. Add a rule to allow requests from the SearchAtlasBot User-Agent and from the Search Atlas crawler IP ranges. 3. Reload or restart the web server to apply the changes. 4. Re-run the OTTO scan in Search Atlas to confirm the crawler can now access the site. If you are unsure which security layer is blocking the crawler, check your server or WAF access logs for blocked requests matching the SearchAtlasBot User-Agent — this will identify which tool needs to be configured. If you need further assistance, open 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 Custom JavaScript Not Appearing After Publishing

🔍 Overview If you have added custom JavaScript code to your Search Atlas site but it is not appearing in your live site's source, follow the steps below to troubleshoot the issue yourself. If the steps do not resolve it, the final section explains what to have ready when escalating to support. 🧰 Troubleshooting Steps to Try First 1. Confirm you saved and published after adding the code. Adding code to the platform does not automatically update your live site. After pasting your JavaScript snippet, save your changes and then click Publish to push the update to your live site. 2. Check that you added the code in the correct location. Search Atlas supports custom code injection at both the site level (applies to all pages) and the individual page level. Verify you placed the snippet in the intended location — a snippet added only to one page will not appear on others. 3. Clear your browser cache and hard-reload the page. Browsers cache page sources aggressively. After publishing, perform a hard refresh (Ctrl+Shift+R on Windows/Linux, Cmd+Shift+R on Mac) or open the page in an Incognito/Private window before checking View Page Source. 4. Verify your plan includes custom code features. Access to custom JavaScript injection may depend on your current Search Atlas subscription plan. Check your plan details in your account settings to confirm this feature is available to you. 5. Check for syntax errors in your snippet. A JavaScript snippet with a syntax error may be stripped or fail silently. Review your code for unclosed brackets, missing semicolons, or other syntax issues before re-saving. 6. Re-save and re-publish. If the above steps do not resolve the issue, remove the snippet, save, publish, then re-add the snippet, save, and publish again to force a fresh injection. 📋 What to Have Ready If You Need to Escalate If the steps above do not resolve the issue, please have the following information ready when you contact support: - The exact location in the platform where you added the JavaScript (e.g., which menu or settings panel you used) - The project or site name where the code was added - The URL of the specific page where the code should appear - Whether you published the site after adding the code, and approximately when - The full JavaScript snippet you are trying to inject (or a description of what it does) - Any error messages or unexpected behavior you observed - A screenshot of your browser's page source (right-click → View Page Source) showing that the code is absent If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Meta Generator Wrong Language Bug: What to Know

🔍 Overview Some users reported that the Meta Tags Generator inside Content Genius was producing metadata in the wrong language — for example, generating Dutch text for articles written in English — while still consuming quota. This was a confirmed bug in the platform, not a configuration error on the user's part. ⚙️ What Caused the Issue The root cause of this issue is a bug in the metadata generation process within Content Genius. The specific internal cause is still under investigation by our engineering team. If you experienced this issue, it was not caused by your account settings or article configuration. In some cases the generator also consumed quota during incorrect generation attempts, leaving users without usable results. ✅ Current Status Our team is aware of this bug and is actively working on a resolution. If you are currently experiencing this issue — metadata appearing in the wrong language or quota being consumed without a valid result — please contact our support team so we can log your case and assist you directly. 🚀 What You Can Do Right Now 1. Stop re-running generation on the affected article to avoid consuming additional quota while the bug is active. 2. Write your meta title and meta description manually as a temporary workaround: copy your article's main keyword and target language, then draft a short meta title (50–60 characters) and meta description (150–160 characters) by hand and paste them directly into your CMS or the article editor. This preserves your SEO metadata without using any quota. 3. Note the affected article name, the language you expected, and the incorrect language that appeared in the output so you have this ready if the issue persists. 4. Once the fix is confirmed resolved, return to the Meta Tags Generator and regenerate metadata for any articles where you received incorrect-language output. 💡 Tips While This Is Being Investigated - Avoid re-running metadata generation on affected articles until the issue is confirmed resolved, as repeated attempts may consume additional quota without producing correct results. - If you believe your quota was consumed without a valid metadata result being saved, contact support with your account details so the team can review your case and restore quota where appropriate. - Keep a record of any articles where you received incorrect-language output so you can regenerate accurate metadata once a fix is confirmed. If you need help, want to report an affected article, or need quota reviewed, please reach out to our support team — we're happy to help. You can start a conversation using the chat widget at the bottom of this page.

🕷️ Search Atlas Crawler Blocked by SiteGround

🔍 Overview SiteGround's built-in security firewall can intercept Search Atlas crawler requests and return a challenge page instead of your actual page content. This means your site may appear to crawl successfully inside the Search Atlas dashboard while the crawler is actually receiving a blocked or challenged response — not real content. This article explains why this happens, how to confirm it, and what steps to take to resolve it. ⚠️ Why the Dashboard May Show a Successful Crawl Search Atlas records a crawl as successful when the server returns a successful HTTP status code. In some cases, SiteGround's firewall may return a response code that the platform interprets as a success — even when the response body is a CAPTCHA or challenge page rather than your actual content. This is a known limitation that our engineering team is aware of and is reviewing. 🛠️ How to Confirm SiteGround Is Blocking the Crawler 1. Log in to your SiteGround Site Tools dashboard. 2. Review your site's security and traffic logs to look for repeated requests from Search Atlas crawler IP addresses that are being blocked or challenged by the firewall. 3. Check your server access logs to see the exact responses being served to the Search Atlas crawler. 4. If you are unsure where to find these logs in your SiteGround account, consult SiteGround's own support documentation or contact their support team for guidance on locating blocked traffic records. ⚙️ About the Search Atlas Crawler User-Agent and IP Addresses Customers have asked us to clarify two specific technical points: - User-agent value: The Search Atlas crawler identifies itself with a user-agent string that includes SearchAtlas. To confirm the precise value being sent for your site, contact our support team and provide your project name so we can look up the exact crawler configuration for your account. - IP addresses: Search Atlas uses crawler IP addresses that may need to be whitelisted in SiteGround's firewall. We do not publish the full IP range publicly, as it is subject to change. Our support team can provide the current IP list relevant to your account so you can whitelist them in SiteGround. ✅ How to Whitelist the Search Atlas Crawler in SiteGround 1. Contact our support team (see below) and provide your project name and the domain being crawled. We will supply you with the current crawler IP addresses to whitelist. 2. Log in to SiteGround Site Tools and navigate to the security or IP management section of your account. If you are unsure of the exact location, SiteGround's support documentation can guide you to the correct panel for your plan. 3. Add each Search Atlas crawler IP address provided by our support team to your whitelist and save your changes. 4. Trigger a new crawl in Search Atlas and verify that real page content is now being returned. 📋 What to Have Ready When You Contact Support Because resolving a SiteGround firewall block requires backend investigation, please have the following information ready when you reach out: - Your project name in Search Atlas - The domain that is being crawled - Any error messages or status codes you have observed in your SiteGround logs or in the Search Atlas dashboard - The date and approximate time when the crawl issue was first noticed If you need further assistance, open 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 Custom JavaScript Not Showing on Live Site

🔍 Overview Custom JavaScript added through your site's custom code settings should appear in your live site's page source after publishing. If your code is not showing up, a few common causes are usually responsible. This article walks you through general troubleshooting steps to try before escalating to the support team. ✅ Step 1: Confirm the Code Was Saved and Published The most frequent cause of missing custom code is an incomplete save or publish action. 1. Navigate to the custom code or custom scripts section of your platform dashboard. 2. Verify your JavaScript code is present in the correct field. 3. Save any unsaved changes. 4. Publish or apply the changes to push them to your live site. 5. Wait 1–2 minutes, then hard-refresh your live site (Ctrl + Shift + R on Windows or Cmd + Shift + R on Mac) and check the page source again. 🗄️ Step 2: Clear Your Cache Caching at multiple levels — browser, server, or CDN — can prevent updated code from appearing immediately in your live site source. - Browser cache: Perform a hard refresh as described above, or open your site in a private/incognito window. - Server or CDN cache: If your site uses a CDN (such as Cloudflare) or a server-level caching plugin, purge the cache from that service's dashboard and check again. - Platform cache: If your Search Atlas-connected site has a caching layer, clear it and re-check the live source. 📋 Step 3: Check That Your Code Is Valid JavaScript Invalid or malformed JavaScript can cause the code block to be stripped or silently ignored during publishing. - Make sure your code does not contain unclosed tags, mismatched brackets, or syntax errors. - If you are embedding a third-party script, ensure you are pasting the full snippet exactly as provided, including any required opening and closing <script> tags. - Test your snippet in a JavaScript validator or your browser's developer console before adding it to the platform. 🔒 Step 4: Check for Security or Content Policy Restrictions Some hosting environments and security configurations block the injection of inline scripts or scripts from external domains. This is enforced by the server or CDN — not by Search Atlas — and can silently prevent custom code from rendering. - Review your site's Content Security Policy (CSP) headers to confirm external script sources are allowed. - If you are using a security plugin or firewall (such as Wordfence or Sucuri), check whether it is filtering custom script injections. - Contact your hosting provider if you suspect server-level policies are blocking the code. 📩 Still Not Showing? Escalate to Support If you have worked through the steps above and your custom JavaScript is still not appearing in your live site source, the issue may require investigation by the Search Atlas team. To help us resolve it quickly, please have the following ready before reaching out: - The exact JavaScript snippet you are trying to add. - The URL of the live page where the code should appear. - A description of which step you completed and what result you observed. - Any error messages shown in your browser's developer console (right-click the page → Inspect → Console tab). - The timestamp of when you last saved and published your changes. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔧 Fix Cloudflare Orange Cloud SSL Verification Failures

What Is Happening If you are receiving repeated warning emails stating that your domain is blocked due to an extra AAAA DNS record — even though your own diagnostics appear normal — the most likely cause is Cloudflare's proxy feature, commonly known as the orange cloud. When the orange cloud is enabled on a DNS record in Cloudflare, Cloudflare can add additional records to your domain that may not be immediately visible through standard diagnostic tools. Our SSL verification system may detect these extra records and flag your domain as misconfigured, triggering repeated warning emails. This is a real DNS conflict — not a notification error — and it must be resolved at the DNS level to stop the emails and restore full SSL verification. Why Your Diagnostics Look Fine Third-party DNS lookup tools and your browser may show your site loading correctly because Cloudflare's proxy handles traffic successfully. However, our SSL verification system performs its own DNS resolution check that may reveal additional records Cloudflare introduces. The conflict can exist at the infrastructure level even when your site appears functional to end users. How to Fix the Issue Follow these steps in your Cloudflare account to resolve the conflict. 1. Log in to your Cloudflare account at cloudflare.com and select the domain receiving the warning emails. 2. Go to the DNS section using the left-hand navigation inside your Cloudflare dashboard. 3. Find the A record for your domain (typically your root domain or the subdomain you connected to Search Atlas). Look at the Proxy status column. 4. Disable the orange cloud by clicking the orange cloud icon next to the A record. It will turn grey. This switches the record from Proxied to DNS only mode. 5. Check for any standalone AAAA records listed separately in your DNS table for the same hostname. If any exist that were not intentionally added by you, delete them by clicking Edit then Delete. 6. Save your changes and allow time for DNS propagation to complete. Reverify Your Domain in Search Atlas Once you have switched to DNS only mode and removed any conflicting AAAA records, log in to your Search Atlas account and navigate to your whitelabel domain settings to locate your connected domain and trigger a fresh SSL verification check. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔧 Fix GSC Performance 'Site Is Not Active' Error

Overview If your GSC Performance tool displays a Site is not active error, or your settings are not importing as expected, this guide will help you identify the cause and resolve it. In many cases, this error is temporary and clears on its own. Step 1: Wait and Refresh First Before taking any other action, note that this error can be caused by a temporary sync delay or a short-lived authentication issue between Search Atlas and the GSC API. These often resolve on their own. 1. Wait a few minutes without making any changes. 2. Hard-refresh your browser and check whether the error has cleared. If the error disappears after a refresh, no further action is needed. Step 2: Confirm Your GSC Property Is Verified If the error persists, confirm that the affected property is fully verified inside Google Search Console. 1. Open Google Search Console in a new tab. 2. Check that the property matching your domain appears in your property list. 3. Confirm its status is Verified and that you have Owner or Full User permissions on that property. If the property is unverified or you have restricted permissions, GSC will not authorise Search Atlas to pull data, which can trigger the Site is not active error. Step 3: Reconnect Your GSC Integration If the property is verified in GSC but the error still appears in Search Atlas, the connection between the two platforms may need to be refreshed. 1. In Search Atlas, locate the option to manage your GSC connection. 2. Disconnect your current GSC account. 3. Reconnect by re-authorising with the Google account that holds Owner access to the affected property. 4. Once reconnected, return to GSC Performance and allow some time for the data sync to complete before refreshing the page. Step 4: Re-apply Your Import Settings If your settings did not import correctly alongside the error, follow these steps after the connection is restored. 1. Open the GSC Performance tool from your Search Atlas dashboard. 2. Confirm the correct property is selected — make sure it matches the domain showing the error. 3. Re-enter any date range, filter, or dimension preferences you had configured. 4. Save your settings and verify that data is now loading correctly. Still Seeing the Error? If the error persists after completing all steps above, please reach out to our support team. To help us investigate quickly, have the following ready: the affected domain name, the exact error message you are seeing, and the approximate time the issue began. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Fix Instant Indexing Token Generation Errors

🔍 Overview If you encounter an error when generating an instant indexing token inside Search Atlas, the most common cause is a cached conflict tied to your specific site's data. This guide explains why this happens and walks you through the steps to resolve it — without needing to contact support in most cases. 💡 Why Does This Error Occur? Instant indexing tokens are generated on a per-site basis. If the stored data for a particular site is outdated or conflicting, the token generation process can fail. This is a site-specific cache issue, not a platform-wide problem. Other sites in your account may work perfectly while one site triggers the error repeatedly. 🛠️ How to Fix the Token Generation Error 1. Log in to Search Atlas and navigate to the site that is showing the token generation error. 2. Open the relevant section of the platform where your instant indexing settings are managed for that site. 3. Locate the Instant Indexing settings and identify the token that failed to generate. 4. Clear the site-specific cache for the affected site. This resets only that site's stored data and does not affect your other sites or account settings. 5. Once the cache has been cleared, retry the token generation for the affected site. 6. Wait a few seconds for the platform to process the request. The token should now be created successfully. ⚠️ If the Error Persists If clearing the site-specific cache does not resolve the issue, the problem may require further investigation by our support team. Please have the following information ready when you reach out: - The name of the affected site in your Search Atlas account - The exact error message you are seeing - The approximate time and date when the error first occurred If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔧 Fix Blocked Alt Text and Indexing Failures

Overview Two separate but often co-occurring issues can disrupt your on-page optimization workflow in Search Atlas: blocked image alt text recommendations that cannot be deployed, and Instant Indexing activation failures during service account provisioning. This article explains the root cause of each issue and what to do next. Why Are My Alt Text Recommendations Blocked? Search Atlas deploys alt text changes through an API override layer. When that deployment is blocked, it is typically because the API override process itself is encountering an error — not a browser or cache issue. Clearing your browser cache or cookies does not resolve this error. This is a server-side and API-level issue that requires escalation to the support team so they can investigate the specific block on your account. What to Have Ready When Escalating To help the support team resolve your blocked alt text deployment as quickly as possible, please have the following information ready before reaching out: - The name of the project or site where the alt text deployment is being blocked - The exact error message or status shown when the deployment fails - The timestamp (date and time) when you first noticed the block - Whether the issue affects a single recommendation or all queued recommendations Why Is Instant Indexing Failing During Setup? Instant Indexing activation failures during service account provisioning are related to a plan requirement. The Instant Indexing feature and the associated service account setup require a specific plan level in Search Atlas. If your current plan does not include this feature, provisioning will fail during the activation process. To resolve this, confirm that your Search Atlas subscription includes Instant Indexing access. If you are unsure which plan you are on or whether it includes this feature, the support team can verify your plan details and enable the correct access for your account. What to Have Ready When Escalating To help the support team resolve your Instant Indexing provisioning error quickly, please have the following ready: - Your Search Atlas account email address - The exact error message shown during service account provisioning - The timestamp when the provisioning failure occurred If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔌 Fix GSC Connection Failures Caused by Domain Redirects

🧭 Overview Connecting Google Search Console (GSC) to Search Atlas usually takes just a few clicks. However, if your primary domain is redirecting to a secondary domain — or is temporarily unavailable — the OAuth process can complete without errors yet still fail to establish a working connection. This article walks you through diagnosing and fixing that specific scenario. ⚠️ Is This Your Issue? Standard GSC connection problems are often solved by clearing your browser cache, re-authorising permissions, or ensuring you have admin-level access in GSC. If you have already tried those steps and the connection still fails, a domain redirect or domain unavailability issue is likely the root cause. Look for these signs: - OAuth completes successfully but Search Atlas shows the property as disconnected or returning no data. - Your primary domain (e.g., example.com) automatically redirects to a secondary domain (e.g., www.example.com, a regional subdomain, or an entirely different domain). - Your primary domain is temporarily down, parked, or pending renewal. - GSC is verified under one domain variant but Search Atlas was connected using a different variant. - You can log in to GSC directly and see data, but Search Atlas shows an empty or broken property. 🔍 Step 1 — Identify the Domain Variant Verified in GSC Google Search Console treats different domain formats as separate properties. Before reconnecting, confirm exactly which property is verified and active in your GSC account. 1. Log in to Google Search Console at search.google.com/search-console. 2. Open the property selector and review all listed properties. 3. Note the exact URL format that is verified and actively receiving data — for example, https://www.example.com versus https://example.com. 4. If multiple properties exist, identify which one has the most recent data and a confirmed verification status. 🔄 Step 2 — Check Whether Your Primary Domain Is Redirecting A redirect from your primary domain to a secondary domain is one of the most common hidden causes of GSC connection failures. To check this: 1. Open a browser and type your primary domain (without www) directly into the address bar. 2. Watch the address bar after the page loads. If the URL changes, a redirect is active. 3. Note the final destination URL — this is the domain GSC is actually tracking. 4. If your domain shows a parking page, error page, or is completely unreachable, this confirms a domain unavailability issue that will block the connection. 🔗 Step 3 — Reconnect GSC Using the Correct Domain in Search Atlas Once you know the exact verified domain, disconnect the existing GSC property in Search Atlas and reconnect it using the precise URL that is verified in GSC (in If you need further assistance, open 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 Site Audit Crawler Blocked by Robots.txt

🧭 Overview When you run a site audit in Search Atlas, our crawler needs to access your website's pages to collect SEO data. If your robots.txt file is misconfigured — especially after a WordPress update — it can block our crawler entirely, resulting in incomplete or missing audit results. This article explains why this happens and how to fix it. ⚠️ Why Is the Search Atlas Crawler Being Blocked? There are several common reasons our crawler cannot access your site: - WordPress is set to discourage search engines: WordPress has a built-in setting that adds a Disallow: / directive to your robots.txt, blocking all crawlers. - A plugin overwrote your robots.txt: SEO plugins (e.g., Yoast, Rank Math) or security plugins may have regenerated or modified your robots.txt after an update. - A custom robots.txt rule blocks all bots: A wildcard rule like User-agent: * followed by Disallow: / blocks every crawler, including ours. - Your hosting provider or firewall is blocking crawlers: Some security configurations or WAF (Web Application Firewall) rules may block unknown user agents. 🛠️ How to Fix Robots.txt on WordPress 1. Check the WordPress search engine visibility setting. Log in to your WordPress dashboard. Go to Settings → Reading. Make sure the checkbox labelled "Discourage search engines from indexing this site" is unchecked. Save your changes. WordPress will update your robots.txt automatically. 2. Review your robots.txt file directly. Open a browser and visit yourdomain.com/robots.txt. Look for any line that says Disallow: / under User-agent: *. If you see this, it means all crawlers — including Search Atlas — are blocked. 3. Edit robots.txt via your SEO plugin. If you use an SEO plugin such as Yoast SEO or Rank Math, check your plugin's settings for a robots.txt editing option. Consult your plugin's official documentation for the exact location of this feature, as menu paths may vary by version. Make sure the file contains at minimum: User-agent: * followed by Allow: /. 4. Edit robots.txt via FTP or cPanel (advanced). If you do not use an SEO plugin, connect to your server via FTP or cPanel File Manager. Locate robots.txt in your root directory. Remove any Disallow: / lines that apply to all user agents. Save and re-upload the file. 5. Allow the Search Atlas crawler specifically. If you want to keep other crawlers restricted but allow Search Atlas, you can add a dedicated rule to your robots.txt for the Search Atlas crawler user agent. Place this rule above any wildcard rules to ensure it takes priority. Contact our support team to confirm the exact user-agent string to use. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

Fix WordPress Admin Bar False Positive Redirects

What Is This Issue? If your Site Auditor report flags pages as containing redirect links — but you inspect those pages and the listed URLs are nowhere to be found — you are likely experiencing a WordPress admin bar false positive. For example, the audit may report that /aim-tools/ contains a link redirecting to /about, but when you view the page in a browser or check its source code, that link does not exist. This is a known issue and does not indicate a real problem with your page content. How to Recognise This Symptom - Site Auditor lists redirect issues on multiple pages across your site. - The flagged URLs (e.g. /about, /wp-admin/, dashboard links) are not present in the visible page content or HTML source. - The same set of redirect URLs appears repeatedly across many different pages. - The flagged links often point to WordPress admin, profile, or navigation destinations. Root Cause: The WordPress Admin Bar When a user is logged into WordPress while a site crawl runs, WordPress automatically renders the admin toolbar at the top of every page. This toolbar contains links to areas such as the dashboard, your profile, site settings, and custom menus. Search Atlas's Site Auditor crawls pages the same way a browser would. If the crawler visits your site while a WordPress session is active, it reads the admin bar as part of each page's HTML. Any redirecting links inside that toolbar get attributed to every page the crawler visits — even though those links are not part of your actual page content. This is not a bug in Site Auditor. The crawler is accurately reporting what it finds in the page HTML. The issue is that the admin bar should not be visible to the crawler at all. How to Fix It Choose one of the following remediation methods based on your setup. Option 1: Ensure the Crawler Visits Pages While Logged Out (Recommended) 1. Log out of your WordPress account completely. 2. Open a private or incognito browser window and confirm the admin bar is no longer visible on your site's front end. 3. Return to Search Atlas and navigate to your project's Site Auditor. 4. Trigger a fresh crawl of your site. 5. Review the crawl results after the crawl completes. The false positives should no longer appear. This is the most reliable fix because it removes the admin bar from the crawled HTML entirely. Option 2: Hide the Admin Bar for Non-Admin Users or Bots If your site must remain logged in during crawls, or if you use a crawl user account, you can suppress the admin bar programmatically. Add the following code to your theme's functions.php file or a site-specific plug If you need further assistance, open 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 Site Audit Processing Errors

🔍 Understand the Issue A site audit may show as completed but actually have a background processing error that makes results appear incomplete or stuck. This is not an approval gate or account restriction — your subscription is active and you can run new audits. 🛠️ Re-run the Audit The fastest fix is to start a fresh audit for the same domain. This bypasses the stuck processing and generates complete results. 1. Go to Left sidebar → OTTO SEO → All Sites 2. Locate the domain (e.g. easygold.com.au) in your site list 3. Start a new audit for that domain 4. Wait for the new crawl to finish and review the updated report 📊 Verify Results After the new audit completes, check the report for full data. If the issue persists, it may indicate a deeper processing problem that our engineering team has addressed in recent updates for large sites and JavaScript rendering. 💡 When to Contact Support If re-running the audit does not resolve the issue, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 Site Pixel Not Detected in Search Atlas

🧭 Overview After installing the Search Atlas pixel on your website, you may notice that the platform has not yet detected it — even if a third-party tool confirms the pixel is present in your page header. This is expected behavior. Detection depends on the site auditor completing a full crawl of your site, which can take up to 24 hours. This article explains why the delay occurs, what to expect during that window, and how to confirm your pixel is correctly installed in the meantime. ⏱️ Why the Pixel Is Not Detected Immediately Search Atlas detects your site pixel by crawling your website during the site auditor process — it does not perform a real-time check at the moment of installation. Because of this, there is a natural delay between when you install the pixel and when the platform confirms detection. This delay is normal and does not mean your pixel is broken or missing. - The site auditor runs a full crawl of your domain to collect data, including pixel presence, page health, and technical SEO signals. - Crawl queue and site size affect how long the process takes. Larger sites or high-demand periods may push completion toward the full 24-hour window. - Your pixel can be correctly installed and fully functional even while the platform still shows it as undetected. 📋 What to Expect After Installing Your Pixel After installing your pixel, allow up to 24 hours for the site auditor to complete its crawl and update the detection status in the platform. You do not need to reinstall the pixel or take any action during this window. Allow the full 24-hour period to pass before treating the delay as an issue. If the pixel is still not detected after 24 hours, proceed to the verification steps below. 🤖 OTTO Status Update Expectations If you are using OTTO, Search Atlas's OTTO SEO automation, its status reflects data from the most recently completed site audit. This means: - OTTO will not show your pixel as active until the site auditor has finished processing and confirmed detection. - Any OTTO recommendations or automations that depend on pixel data will update automatically once the audit completes — you do not need to re-trigger anything manually. ✅ How to Verify Your Pixel Is Correctly Installed While Waiting While the site auditor processes your site, use the following steps to confirm your pixel is in place so you can be confident the detection update will succeed once the crawl finishes: 1. Open your website in a browser and view the page source (right-click → View Page Source). 2. Search for your Search Atlas pixel code in the <head> section of the page. 3. If the pixel code is present in the header, your installation is correct. No further action is needed — wait for the site auditor to complete its crawl. If you need further assistance, open 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 Crawl Failures: Fixing Homepage Redirect Issues

🧭 Overview When OTTO's crawler cannot successfully reach your homepage, it fails to initialize a site scan — even if your OTTO pixel is correctly installed in your source code. This creates a confusing situation where your pixel appears in the page HTML but OTTO still reports it as undetected. The root cause is almost always a redirect configuration that blocks the crawler before it can verify the pixel. ⚠️ Why OTTO Requires a Directly Accessible Homepage URL OTTO's crawler starts every site scan by fetching your homepage URL. For the scan to succeed, that URL must return a valid response without passing through a problematic redirect chain. If the crawler follows a redirect that leads to an unexpected destination, it may fail to complete the crawl or detect your pixel. Common redirect patterns that can cause this failure include: - HTTP → HTTPS redirects where the URL saved in OTTO uses http:// but your server forces https:// - Non-www → www redirects (or vice versa) where the saved URL does not match the canonical version of your homepage - Custom path redirects where the root domain redirects to a subdirectory such as /home or /en/ - Redirect chains combining two or more of the above 🔗 How Redirect Chains Block Crawler Initialization Each redirect hop adds latency and risk. When a redirect chain leads to a URL outside the registered domain, or otherwise prevents the crawler from reaching the page, the scan may fail. Because the scan never completes, OTTO cannot read your page source — which is why your pixel appears in the source code when you check manually but remains undetected inside the platform. Think of it this way: you installed the pixel correctly, but OTTO never got close enough to the page to see it. 🩺 Step-by-Step Diagnosis 1. Find the URL registered in OTTO. Navigate to your OTTO project and locate the homepage URL that was entered during setup. Note the exact URL, including the protocol (http or https) and whether it includes or excludes www. 2. Check what your homepage actually resolves to. Open a new browser tab and paste your registered URL into the address bar. Watch where the browser ends up after all redirects complete. Copy the final URL from the address bar. 3. Compare the two URLs. If the registered URL and the final resolved URL are different in any way — protocol, subdomain, trailing slash, or path — you have likely found the source of the crawl failure. 4. Update the registered URL in OTTO to match the final resolved URL exactly, so the crawler can reach your homepage without following any redirects. 5. Re-trigger the site scan after updating the URL and confirm that OTTO successfully detects your pixel. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 Fix Shopify Location Pages Missing from Site Audit

🗺️ What This Article Covers If your Shopify store has location pages stored under the /pages/ path and they are not appearing in Search Atlas's Site Audit or Page Explorer — or if their meta descriptions look outdated despite being updated in Shopify — this article explains what to have ready when reaching out to our support team. 🤔 Why This Happens Shopify location pages under the /pages/ path can go missing from the Search Atlas Site Audit crawler. The root cause varies by store and requires investigation by our support team to identify correctly. ✅ Information to Gather Before Contacting Support Because this issue requires investigation by our support team, please collect the following details so we can resolve it as quickly as possible: 1. Your Search Atlas project name and the full domain URL associated with the Site Audit project where pages are missing. 2. Example URLs of the specific Shopify location pages (e.g. yourstore.com/pages/location-name) that are not appearing in Site Audit or Page Explorer. 3. Whether the pages appear in your Shopify sitemap. You can check this by visiting yourstore.com/sitemap.xml in a browser and looking for your location page URLs. Note whether they are present or absent. 4. Whether each missing page is publicly visible in your Shopify store settings. 5. When the pages were last updated in Shopify and approximately when the most recent Site Audit crawl was run. Sharing these details upfront allows our team to identify the root cause and apply the correct fix. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 How to Troubleshoot Data Aggregator Submissions

This article helps you identify and fix problems with data aggregator submissions — including stalled submissions, missing business data, or submissions that appear stuck in a pending state. Follow the steps below to diagnose the issue before reaching out to support. 🔍 Common Causes - Incomplete business information: Aggregators require a complete and consistent NAP (Name, Address, Phone number). Any mismatch or missing field can cause a submission to fail or stall. - Duplicate listings: Existing duplicate listings at an aggregator can block a new submission from processing correctly. - Submission still processing: Aggregator submissions are not instant — propagation can take days to several weeks depending on the aggregator. - Project not fully configured: If the associated project is missing key business details, submissions may be incomplete at the point of send. 🛠️ Step-by-Step 1. Verify your business information is complete and consistent. Open your project settings and confirm that your business name, address, phone number, website URL, and business category are all filled in and match exactly what appears on your website and Google Business Profile. 2. Check the submission status in your project. Navigate to the relevant project inside Search Atlas and review the status for each aggregator to identify whether a submission is in progress or showing a problem state. 3. Allow adequate processing time. Aggregator submissions are not instant — allow several weeks for propagation before concluding there is an issue, as some aggregators update their databases on a monthly cycle. 4. Correct any business data issues and re-submit if needed. If a submission shows a clear error state, review your business information fields for inconsistencies or missing values, correct them in your project settings, and re-initiate the submission. 5. Check for duplicate listings. Search the aggregator's consumer-facing directory (e.g., search your business name on sites powered by that aggregator) to confirm whether a conflicting or duplicate listing exists. If found, note the details — this information will help support investigate further. ✅ How to Confirm It Worked To verify that a data aggregator submission has processed successfully, check the following: - The submission status in your project updates to a confirmed or completed state. - After the expected propagation window, your business information appears accurately on directories and platforms powered by the aggregator. 📋 Before Escalating If you have worked through the steps above and the issue remains unresolved, please have the following ready when you contact support: your project name, the specific aggregator(s) affected, the date the submission was initiated, and any error messages or statuses you are seeing. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

Fix Brand Vault Wix Crawl and Stuck Images

What This Article Covers If your Brand Vault is showing irrelevant or generic business information, your Style Guide images appear stuck or spinning, or an unexpected post was published to a social channel, your website may be built on Wix. This article explains why this happens and how to begin resolving each issue. Why Wix Sites Cause This Problem Wix websites render their content using JavaScript rather than plain HTML. When the Brand Vault crawler visits a Wix site, it can only read the page shell — the visible text, business details, and images are not accessible to the crawler. As a result: - Brand Voice detection picks up generic or placeholder content instead of your real business information. - Style Guide images may get stuck in a loading or spinning state because the crawler cannot retrieve images from a JavaScript-rendered page. - Any AI-generated content — including social posts — may be based on that incorrect data, leading to irrelevant output being published. Fix 1: Manually Enter Your Business Information Because the crawler cannot read your Wix site automatically, you need to provide your business copy directly inside Brand Vault rather than relying on automatic crawling. Open Brand Vault and look for the area where you can enter or edit your business details manually. Paste in your business description, services, tone, and any other key details so the system has accurate information to work from. Save your changes once complete. Once your real business information is saved, Brand Vault will use it to generate accurate Brand Voice data across the platform. Fix 2: Remove Any Incorrectly Published Social Posts If an irrelevant post was published to Facebook or another social channel as a result of the bad crawl data, you will need to delete or unpublish that post manually. Log in to the relevant social platform directly and remove the post. Then, after completing Fix 1 above, regenerate your social content so it reflects your correct brand information before publishing again. Fix 3: Resolve Stuck Style Guide Images Style Guide images that are stuck loading or spinning are a known issue tied to the same Wix crawl limitation. If your images remain stuck after following Fix 1 and allowing a few minutes for the system to update, try manually uploading your brand images directly inside Brand Vault's Style Guide section instead of relying on auto-discovery from your website. Still Need Help? If the steps above do not resolve your issue, please contact our support team via the chat widget and we will be happy to assist you further.

🔘 Schema Deploy Button Grayed Out After AI Generation

🧩 Overview After running AI schema generation in Search Atlas, you may notice the Deploy button remains grayed out and unclickable. This can be confusing because the AI generation appears to have completed successfully. This article walks you through self-serve steps to resolve the issue before escalating. 🔍 Why the Deploy Button May Be Grayed Out The Deploy button can remain inactive after AI schema generation for a variety of reasons. The following self-serve steps resolve the issue in most cases. ✅ Steps to Try First 1. Refresh the page. A full browser refresh (Ctrl+F5 or Cmd+Shift+R) can clear a stale UI state that is preventing the button from activating. 2. Re-run AI schema generation. Navigate back to the schema generation step and run the AI generation again. Once it completes, check whether the Deploy button becomes active. 3. Check for unsaved or incomplete changes. Make sure all required fields or schema selections have been completed. An incomplete schema state can keep the Deploy button disabled. 4. Try a different browser or clear your cache. Browser extensions or cached data can sometimes interfere with button states. Test in a private/incognito window or a different browser. 5. Log out and log back in. Re-authenticating can reset session state that may be causing the issue. ⚠️ What to Have Ready If You Still Need Help If the steps above do not resolve the issue, reach out to our support team with the following information ready: - Project or page URL where the Deploy button is grayed out. - Screenshot of the grayed-out Deploy button. - Any error messages visible on the screen. - Steps you have already tried from the list above. If you need further assistance, open 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 Site Audit Crawler Failures and Config Errors

🔍 Overview If your Site Audit is returning 0 crawled pages or you are seeing unexpected crawl configuration behavior, this article explains what to prepare and what to expect when our team investigates. Site Audit crawler failures and account configuration errors require backend review by a support agent. ⚠️ Common Symptoms - Site Audit completes but shows 0 pages crawled - Crawl settings cannot be saved or updated - Unexpected behavior in crawl configuration options - Audit results appear inconsistent with your site content 📋 What to Know Before Escalating Site Audit crawler failures and account configuration errors are typically caused by backend issues that cannot be resolved through the interface alone. Our support team will need to review your project and account configuration directly. To help us resolve your issue as quickly as possible, please have the following ready when you contact support: - Your project name as it appears in Search Atlas - The exact error message displayed in the Site Audit dashboard, if any - A timestamp of when the crawl failure occurred or when you first noticed the configuration issue - A description of any settings you changed before the issue appeared - Your current plan so our team can verify which features are available to your account 🛠️ Preliminary Checks You Can Do 1. Confirm your website is publicly reachable. The crawler cannot access password-protected, staging, or locally hosted sites. Verify your domain loads correctly in a browser without a login prompt. 2. Check that your domain is entered correctly in the project. A typo or missing protocol can prevent the crawler from reaching your site. 3. Note any error messages in the Site Audit dashboard. Record the exact wording of any errors shown so you can share them with the support team. 4. Do not repeatedly re-run the crawl while the issue is unresolved, as this may compound configuration conflicts that require backend correction. ⚙️ What Happens Next Once you contact support with the details above, a member of our team will review your account and project configuration on the backend and work with you to restore normal crawl behavior. We will confirm the outcome and any changes made to your account directly in the support chat. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Fix No-Index Pages After RankMath Migration

🔍 Why This Happens When you remove RankMath and import your SEO data into Search Atlas, RankMath's no-index settings can carry over during the migration process. This means pages and posts that should be publicly indexed may arrive in Search Atlas flagged as no-index, preventing search engines from crawling and ranking them. This is a known migration behaviour. The good news is you can resolve it in bulk without editing each page individually. ⚙️ Step 1 — Identify Affected Pages 1. In the left sidebar, click Site Metrics (Site Explorer) to open the Site Explorer. 2. Look for a filter or column related to indexability or no-index status. 3. Apply the No-Index filter to display only the affected URLs. 4. Review the list to confirm which pages should actually be indexed. 🚀 Step 2 — Bulk-Update the Indexing Status 1. While the no-index filter is active, select all affected pages using the Select All checkbox at the top of the list. 2. Look for the Bulk Actions or Edit option in the toolbar above the list. 3. Choose Set to Index (or the equivalent indexing option) from the bulk actions menu. 4. Confirm the action when prompted. Search Atlas will update the indexing status for all selected pages at once, saving you from making changes one by one. ✅ Step 3 — Verify the Changes 1. Clear the no-index filter and reload the page list. 2. Spot-check several previously affected URLs to confirm their status now shows as Index. 3. If any pages are still showing as no-index and should not be, repeat the bulk-update steps for those remaining URLs. 💡 Tips to Prevent This in Future Migrations - Audit before importing: Before completing a plugin migration, export your current page list from RankMath and review which pages are already flagged as no-index. Remove incorrect flags at the source first. - Test with a small batch: When migrating a large site, import a small subset of pages first and check their indexing status in Search Atlas before proceeding with the full import. - Check custom post types: No-index flags from RankMath often affect custom post types and archive pages. Make sure to include these in your post-migration audit, not just standard posts and pages. 🙋 Need More Help? If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Fix Shopify Pages Missing in OTTO

If your Shopify location pages or other /pages/ URLs are not appearing in your OTTO SEO audit, it is usually due to how our crawler detects your website's content management system (CMS). Shopify sites occasionally block automated crawlers, which can prevent OTTO from fully scanning your pages. 🔍 Understanding the Detection Issue Our team is actively improving how OTTO identifies and crawls sites built on platforms like Shopify, GoHighLevel, and HubSpot. Occasionally, these platforms restrict access to certain URL paths (like /pages/), causing them to remain undetected during a standard site audit. 🚀 What to Expect This is a known issue that our engineering team is actively working to resolve. We are currently rolling out updates to enhance Shopify crawler compatibility. Until these platform-wide fixes are finalized, some Shopify /pages/ URLs may continue to be excluded from the OTTO crawl. 📋 What to Have Ready When Contacting Support To help our engineering team investigate your specific case, please have the following information available: - Your project or website name as it appears in Search Atlas - The specific Shopify /pages/ URLs that are missing from your OTTO audit - The date you first noticed the pages were missing - Any confirmation that these pages are live and indexable (e.g., they load correctly in a browser) Our support team can manually review your account and escalate your case to engineering for further investigation. 💬 Need Further Assistance? If you need further assistance, open 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 Site Report Refresh and Crawl Quota Errors

🔍 Overview If your site report appears to have finished but the data hasn't updated — or you're seeing a message that you've run out of crawl quota — this guide explains what may be happening and how to get the right help. ⚠️ Why Your Site Report May Not Refresh A site report can display a completed status while still showing outdated data. This is a known issue that our team can investigate on a per-account basis. Common reported scenarios include: - The report status shows completed but data looks unchanged. This may indicate a processing or sync issue on the account. - A crawl quota error message appears. This means the account has reached its crawl limit for the current period and no new crawls can run. - The report appears stalled or stuck in progress. This may require a support team member to review the crawl status on the backend. 📊 Understanding Crawl Quota Search Atlas plans include a crawl quota — a limit on the number of pages that can be crawled within a given period. When this quota is reached, new crawls cannot be initiated until it resets or is increased. If you are seeing a quota-exceeded message, our team can confirm your current limit and advise on next steps. 🛠️ What to Do If Your Site Report Is Stalled or Showing a Quota Error 1. Note the exact error message or status displayed in your site report. 2. Note the domain or project name affected. 3. Note the approximate time the issue started or the crawl was triggered. 4. Contact our support team with this information so a teammate can review your account and crawl status 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 a Grayed-Out Schema Deploy Button

Overview After running AI schema generation in Search Atlas, you may notice the Deploy button remains grayed out and unclickable. This is a known issue that our support team can investigate and resolve on your account. Why This Happens The Deploy button may remain grayed out when the schema generation process does not complete successfully, leaving no valid schema available to deploy. The exact cause can vary by account and page configuration. What to Do Because the specific cause needs to be identified on a per-account basis, please reach out to our support team directly. When you contact us, please have the following ready so we can resolve this as quickly as possible: - Your project or site name in Search Atlas - The exact page URL where the Deploy button is grayed out - Any error messages you see on screen (exact wording, if any) - A screenshot of the grayed-out button if possible - The steps you have already tried (e.g., refreshing the page, re-running generation) If you need further assistance, open 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.

🛠️ Fix BreadcrumbList Schema Errors in Search Atlas

🔍 Overview If Google Search Console is flagging BreadcrumbList structured data errors or Review snippet issues on your site, the most common cause is an incorrect or missing URL field in your schema markup. This article explains how to approach fixing those errors in Search Atlas, connecting Google Ads, and resolving structured data warnings reported by Google Search Console. 📋 Before You Begin - Make sure your site is added and verified in Search Atlas. - Have Google Search Console open in a separate tab so you can cross-reference the specific errors being reported. - Confirm you have Editor or Admin access in your Search Atlas workspace. 🗂️ Step 1 — Locate Your Site in Search Atlas 1. Log in to Search Atlas. 2. Find your site in the site list and click its name to open the site dashboard. 🔗 Step 2 — Navigate to Schema Settings 1. From your site dashboard, locate the schema or structured data tools available for your site. 2. Find the BreadcrumbList schema associated with the page or pages flagged in Google Search Console. ✏️ Step 3 — Update the URL Field in BreadcrumbList Schema The BreadcrumbList schema requires every ListItem to contain a valid, absolute URL in its item property. A missing, relative, or malformed URL is the most frequent cause of Google Search Console errors. 1. Open the BreadcrumbList schema entry for editing. 2. Review each ListItem in the breadcrumb sequence. Each item should have a Name field and a URL field. 3. Ensure each URL value is an absolute URL — it must begin with https:// and match the exact canonical URL of that page. 4. Common issues to fix in the URL field: - Relative paths such as /toys/ — replace with the full absolute URL. - Trailing slash inconsistency — match the format used in your sitemap and canonical tags. - Typos or extra characters in the domain name. - HTTP URLs on an HTTPS site — always use https://. 5. After correcting each URL field, save your changes to apply them. 6. If your BreadcrumbList schema is deployed site-wide via a template, update the URL pattern in the template so all pages inherit the corrected format. 📊 Step 4 — Validate Your Changes 1. After saving, use Google Search Console's Rich Results Test or the URL Inspection tool to confirm the BreadcrumbList errors are resolved. 2. If Review snippet errors were also reported, check that your Review schema includes all required fields (such as ratingValue and reviewCount) and that the schema is properly associated with the correct page. 🔗 Step 5 — Connect Google Ads (if applicable) If your workflow also requires connecting Google Ads as part of schema deployment or site metrics setup, follow these steps: 1. Navigate to the integrations or connected accounts section of your Search Atlas workspace settings. 2. Select Google Ads and follow the on-screen prompts to authorize the connection using your Google account credentials. 3. Once connected, verify that data is flowing correctly by checking the relevant reporting or metrics area within Search Atlas. 4. If you encounter an error during the Google Ads connection process, note the exact error message displayed and the timestamp, as these will be needed if you require further support. ⚠️ If You Cannot Locate the Schema or Google Ads Settings Because Search Atlas is actively developed, the exact location of schema tools and integrations may vary depending on your plan or workspace configuration. If you cannot find the areas described above, please have the following ready before reaching out to support: - Your site name and the URL(s) flagged in Google Search Console. - The exact error message(s) shown in Google Search Console. - A screenshot of the error and the page(s) affected. - Whether you are trying to connect Google Ads, deploy schema, or troubleshoot structured data warnings — or a combination of these. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

Why OTTO Schema Isn't Detected by Validators Despite Correct Deployment

Overview If your OTTO schema deployments show a Connected or Deployed status inside Search Atlas but the schema is not appearing in external tools like validator.schema.org, Google Rich Results Test, or Google Search Console — and your other OTTO-managed sites are working correctly — you may be experiencing a schema generation or validation issue that requires investigation by our support team. This article explains how to identify the issue on your site. Because the resolution may depend on factors specific to your account and deployment configuration, please contact our support team so we can investigate and apply the appropriate fix. Common Root Causes Several technical issues can cause valid-looking schema deployments to fail external validation. Understanding these will help you diagnose the situation quickly. - Schema validation blocking deployment: In some cases, internal validation may prevent schema from being fully pushed to the page even though the deployment status appears as connected in the UI. - Unrecognized or malformed fields: Certain fields in OTTO-generated schema output may not be structured in a way that external validators recognize, causing the schema to be present on the page but not parsed correctly. - Schema not yet propagated: There may be a delay between when OTTO marks a deployment as connected and when the schema is fully live and detectable by external tools. How to Identify the Issue on Your Site 1. Navigate to OTTO SEO → All Sites (SEO Automation) inside Search Atlas and select the affected site. 2. Review which schema types are deployed on the affected pages. 3. Copy the raw schema JSON from the deployed page by right-clicking the page in a browser, selecting View Page Source, and searching for application/ld+json. 4. Paste the raw JSON into validator.schema.org and review any errors or warnings returned. Pay close attention to field-level errors, as these often indicate the root cause. 5. Also test the live page URL directly in the Google Rich Results Test to see whether Google can detect and parse the schema. Next Steps If your schema is still not being detected after reviewing the steps above, please reach out to our support team with the following information so we can investigate further: - The affected site URL and the specific pages where schema is not being detected - A screenshot of the OTTO deployment status for the affected pages - Any errors or warnings returned by validator.schema.org or the Google Rich Results Test Our team will review your deployment configuration and work with you to resolve the issue. If you need assistance, please contact us via the chat widget in Search Atlas or reach out to our support team directly.

🔄 Fix Quota Errors During Site Audit Refresh

🧭 Overview When a site audit appears to complete successfully but the report data does not update, a crawl quota error is often the underlying cause. This article explains how to identify quota exhaustion, reduce quota consumption through crawl speed settings, and decide when manual reprocessing is the right next step. ⚠️ Recognising the Symptoms You may be dealing with a quota-related refresh failure if you notice any of the following: - The site audit progress bar reaches 100% but the report metrics do not change. - A banner or inline message states you are out of quota or have exceeded your crawl limit. - A re-crawl you triggered recently shows as complete, yet page counts, issues, or scores remain identical to the previous run. - New pages you added to the site are not appearing in the report. If you see the out-of-quota message alongside a stale report, the quota error is the blocking issue. Resolving it first is required before any data can refresh. 📊 Check Your Current Quota Usage Before making any changes, confirm how much quota you have consumed: 1. Open Site Metrics (Site Explorer) from the left sidebar. 2. Select the project for your site — in this example, destinationinspiration.com. 3. Look for the Crawl Quota or Pages Crawled indicator on the project overview. This shows pages used against your plan limit for the current billing period. 4. If the used figure is at or near your plan limit, quota exhaustion is confirmed. Quota is consumed each time the crawler processes a page. A large site, a high crawl frequency, or a fast crawl speed setting can all accelerate consumption. 🐢 Reduce Crawl Speed to Preserve Quota Lowering the crawl speed is the fastest way to reduce how quickly your remaining quota is spent. This does not cancel an in-progress crawl, but it limits consumption on future crawls within the same billing period. 1. In Site Explorer, open the project settings for your site. 2. Locate the Crawl Speed or Crawler Settings option. 3. Reduce the speed from its current value — for example, move from Fast to Standard or Slow. Each step down meaningfully reduces pages processed per hour. 4. Save the settings. Use a slower crawl speed when you need to audit a large site toward the end of a billing period, when you want to spread quota usage across multiple projects, or when your plan limit is modest relative to your total page count. 🔁 When to Use Manual Reprocessing Manual reprocessing tells the platform to re-evaluate already-crawled data without consuming additional quota for a fresh crawl. Use it in the following situations: - You have resolved technical issues on the site and want the report to reflect those fixes without a full recrawl. - The crawl completed successfully but the report display did not update, and your quota is not exhausted. - You need updated scores quickly and cannot wait for the next scheduled crawl. To trigger manual reprocessing: 1. Go to Site Explorer and open your site project. 2. Look for the Reprocess or Recalculate Report option within the project actions menu. 3. Confirm the action. The report will regenerate from the most recent crawl data without initiating a new crawl. Important: If your quota is exhausted, manual reprocessing will refresh the display but will not pull in any new pages or changes made to the site after the last crawl. A fresh crawl is needed for fully updated data, and that will only be possible once quota resets or your plan is upgraded. 🔄 Quota Reset and Plan Upgrade Options Crawl quota resets automatically at the start of each billing period. If your current period ends soon, waiting for the reset is often the simplest path. If you regularly exhaust quota before the period ends, consider the following: - Reduce crawl frequency — switch from daily to weekly scheduled crawls for stable, mature sites. - Prioritise projects — pause crawl schedules on lower-priority sites to reserve quota for critical ones. - Upgrade your plan — if your site portfolio consistently exceeds your limit, a higher-tier plan provides a larger quota allocation. ✅ Step-by-Step Resolution Summary 1. Confirm the quota error by checking the Crawl Quota indicator in your Site Explorer project overview. 2. If quota is exhausted, lower the crawl speed in project settings to conserve any remaining allocation. 3. Use manual reprocessing to refresh the report display from existing crawl data if no new crawl is needed right now. 4. Adjust crawl frequency or pause lower-priority projects to prevent recurrence before your quota resets. 5. If the data must be fully up to date before your quota resets, consider upgrading your plan. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Fix Stale Crawl Sources and Phantom Records in Brand Vault

🔍 What Are Stale Crawl Sources and Phantom Records? When your website undergoes a major change — such as a domain migration, a site rebuild, or a hack cleanup — your Brand Vault may continue to reference URLs and crawl data from the old version of your site. These are called stale crawl sources. Alongside stale sources, you may also encounter phantom processing records: leftover data entries that appear in your Brand Vault's queue even though the underlying pages no longer exist or have changed significantly. These phantom records can cause issues such as: - Your knowledge base reflecting outdated or incorrect site content - Timeouts or errors when generating content in bulk with Content Genius - OTTO SEO referencing old page data during automation tasks - Slower Brand Vault performance overall 🗂️ When Should You Take Action? You should clean up your Brand Vault after any of the following events: - A domain or subdomain migration - A full site rebuild or CMS change - A security incident that required bulk URL removal or restructuring - A large-scale content audit that removed or redirected many pages - You notice Content Genius bulk generation timing out or producing irrelevant output ⚙️ Step 1 — Identify Your Stale Crawl Source Before removing anything, confirm which crawl source is outdated. 1. Access your Brand Vault: top-right More Features menu (grid icon, next to your Avatar Menu (👤)) → Brand Vault, (Brand Vault is accessed via the More Features menu.) 2. Once inside, select the relevant workspace or project. 3. Locate the Crawl Sources section. Each source is listed with a unique identifier (for example, a UUID such as e213e8ca-cc02-492c-be44-8f8fdee44479). 4. Review the source URL and the last crawled date. If the URL belongs to a pre-migration version of your site or returns errors, it is stale and safe to remove. 🗑️ Step 2 — Delete the Stale Crawl Source 1. In the Crawl Sources section, click the stale source you identified. 2. Select Delete or the trash icon next to the source entry. 3. Confirm the deletion when prompted. This removes the source and queues all associated crawl data — including page snapshots, media references, and indexed chunks — for cleanup. Note: Deleting a crawl source is permanent. Make sure the source is genuinely outdated before proceeding. If you are unsure, add your new site URL as a fresh crawl source first so your Brand Vault has up-to-date data before you remove the old one. 🧹 Step 3 — Clear Phantom Processing Records After deleting the stale crawl source, phantom records tied to that source will be marked for removal. In most cases, the platform clears these automatically within a short processing window. To verify the cleanup has completed: 1. Return to your Brand Vault and check the Processing Queue or Indexed Pages count. 2. Wait up to 30 minutes for the system to finish purging orphaned records. The exact time depends on how many records exist — larger sets (such as 1,000+ entries) may take slightly longer. 3. Refresh the Brand Vault page. The processing count should return to zero or reflect only your current, active crawl sources. If phantom records remain after 30 minutes, do not delete and re-add your source repeatedly — this can create duplicate entries. Instead, wait a full hour and refresh again before escalating. 🚀 Step 4 — Add Your Updated Site as a New Crawl Source Once the stale data is cleared, add your post-migration site to give Brand Vault fresh, accurate content to work with. 1. In Brand Vault, go to Crawl Sources and select Add Source. 2. Enter your current site URL (the live, post-migration domain). 3. Choose your preferred crawl depth and scope settings. 4. Click Start Crawl. The platform will index your updated pages and populate the Brand Vault with current data. Once the crawl is complete, Content Genius bulk generation and OTTO SEO automation will reference your updated knowledge base. 💡 Tips to Prevent This Issue in the Future - Before a migration: Note your existing crawl source IDs so you can identify and remove them quickly after go-live. - After a migration: Add your new domain as a crawl source immediately and delete the old one within the same session. - After a security incident: Remove any crawl sources that indexed spam or injected URLs before running Content Genius or OTTO SEO tasks. - Routine audits: Periodically review your Brand Vault crawl sources to ensure all entries point to live, relevant URLs. 💬 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.

🛠️ Restore Whitelabel Domain DNS After Migration

💡 Why Your Whitelabel Domain Stopped Working When you move your website to a new server or hosting provider, your DNS zone is usually rebuilt from scratch. Records that were not carried over during the migration — including the CNAME that connects your whitelabel subdomain (for example, app.yourdomain.com) to Search Atlas — are often dropped or replaced with a record pointing at your new server. Once that link is gone, your whitelabel URL stops loading and SSL cannot renew. The good news: this is easy to fix, and your account data is unaffected. 📋 What You Will Need - Access to the DNS settings at your new hosting provider or domain registrar - Your Search Atlas login with access to Agency Hub - The whitelabel subdomain you originally connected (for example, app.yourdomain.com) 🔍 Step 1: Get the Correct CNAME Target 1. Log in to Search Atlas. 2. In the left sidebar, open More Features → Agency Hub → White Label Setup (or go directly to /agency-settings). 3. Find the domain setup section and copy the exact CNAME target shown there. Important: Always copy the target directly from the platform. Do not reuse a target from old emails, notes, or screenshots — targets can change over time, and the domain verifier will reject a mismatched target even when everything else is correct. ⚙️ Step 2: Re-create the DNS Record at Your New Host 1. Open the DNS or zone file editor at your new hosting provider. 2. Search for any existing record for your whitelabel subdomain (for example, the host app). Delete any conflicting A, AAAA, or CNAME records for that host — a subdomain cannot have both an A record and a CNAME at the same time. 3. Create a new record with these values: Type: CNAME, Host / Name: your subdomain (for example, app), Value / Target: the CNAME target you copied from White Label Setup, TTL: 3600 or lower. 4. Save the record. Do not point the subdomain at your new server's IP address with an A record. The whitelabel connection only works through the CNAME to Search Atlas. 🔄 Step 3: Wait for DNS Propagation DNS changes can take anywhere from a few minutes to 48 hours to spread across the internet. You can check progress with any public DNS lookup tool: your subdomain should resolve to the Search Atlas target, not to your new server. If it still shows your new server's IP, an old record is still active somewhere — see the troubleshooting section below. ✅ Step 4: Re-verify the Domain and SSL 1. Return to More Features → Agency Hub → White Label Setup. 2. Re-save or re-verify your whitelabel domain. 3. Confirm the status shows as active with a valid SSL certificate. If SSL will not activate, the CNAME has most likely not finished propagating yet. Wait an hour and verify again — the SSL certificate is provisioned automatically once DNS resolves correctly. No manual certificate installation is needed. 🧩 Common Issues After a Migration - Verifier rejects your CNAME: the target does not match what is shown in White Label Setup. Delete the record and re-add it using the exact value copied from the platform. - Domain loads your new website instead of Search Atlas: an old A record or a virtual host on the new server is capturing the subdomain. Remove the record from DNS, and check that the subdomain is not configured as a site on your new server. - Changes at the new host have no effect: your domain's nameservers may still point to the previous host. Confirm in your registrar settings that the nameservers match wherever you are actually editing DNS. - OTTO pixel stopped tracking: OTTO tags are tied to your whitelabel domain. If the domain changed or was re-issued during the migration, pixels installed on client sites can break. Keep your primary whitelabel domain stable, and if you genuinely need additional domain aliases, contact our team first so they can be configured in a way that will not interrupt tracking. - Client bookmarks or logins fail: if you renamed the subdomain during the migration, update any links you share with clients, embedded widgets, and lead capture forms that reference the old URL. 🚀 Tips to Prevent This Next Time - Before any future migration, export or screenshot your full DNS zone file so no records are lost. - Lower your TTL to 300 at least 24 hours before migrating so changes apply quickly. - After migrating, test the whitelabel URL early and re-verify the domain in White Label Setup. 💬 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 GSC Performance Site Activation Errors

🔎 Understanding the Error If your GSC Performance tool displays a message like "Error loading data: Site is not active: sc-domain:yourdomain.com", it means Search Atlas cannot retrieve data from Google Search Console for that property. This usually happens because the site has not been properly activated within the platform, the GSC property is unverified, or the connection between Search Atlas and your Google account has been interrupted. ✅ Step 1: Verify Your Site in Google Search Console Before Search Atlas can import GSC data, your property must be fully verified inside Google Search Console itself. 1. Go to Google Search Console (search.google.com/search-console). 2. Confirm your property appears in the property selector and shows a verified status. 3. If the property shows as unverified, complete verification using one of Google's supported methods (DNS record, HTML file, or Google Analytics). 4. Once verified, wait up to 24 hours for GSC to begin collecting data before trying again. 🔗 Step 2: Reconnect Your Google Account An expired or revoked Google OAuth connection is a common cause of site activation errors. Reconnecting your account refreshes the permissions Search Atlas needs to pull GSC data. 1. In Search Atlas, click your Avatar Menu (👤) in the top-right corner and open Settings. 2. Navigate to the Integrations or Connected Accounts section. 3. Locate your Google account connection and click Disconnect. 4. Click Connect GSC Account (Site Metrics → Site Explorer) and complete the OAuth flow, making sure to grant all requested permissions including Search Console access. 5. Return to the GSC Performance tool and check whether the error has cleared. 🏠 Step 3: Activate the Site in Search Atlas After confirming your GSC property is verified and your Google account is connected, make sure the site is properly activated inside Search Atlas. 1. In the left sidebar, click Site Metrics (Site Explorer). 2. Locate the domain showing the activation error in your site list. 3. If the site is listed, click the settings or edit icon next to it and confirm the correct GSC property is mapped — for example, ensure sc-domain: properties are matched to the domain-level property, not a URL-prefix property. 4. If the site is not listed, click Add Site, enter your domain, and select the matching GSC property from the dropdown. 5. Save your changes and reload the GSC Performance report. ⚠️ Step 4: Check Property Type Mismatch Google Search Console supports two property types: Domain properties (shown as sc-domain:yourdomain.com) and URL-prefix properties (shown as https://yourdomain.com). A mismatch between the property type in GSC and what is configured in Search Atlas will trigger an activation error. - If your GSC property is a domain property, make sure Search Atlas is also set to use the sc-domain: format. - If your GSC property is a URL-prefix property, confirm the full URL including the correct protocol (https:// or http://) is entered in Search Atlas. - When in doubt, use the same property format shown in your Google Search Console dashboard. ⏳ Step 5: Allow Time for Data to Populate Even after a successful activation, GSC Performance data may not appear immediately. Keep the following timelines in mind: - Google Search Console typically delays data by 2–3 days. - Newly connected or re-connected properties can take up to 24–48 hours to begin syncing inside Search Atlas. - If you have just verified a brand-new domain in GSC, there may be no historical data available yet — data begins accumulating from the verification date. 🛠️ Quick Troubleshooting Checklist - GSC property verified? Check directly in Google Search Console. - Google account connected? Reconnect via Settings → Integrations. - Correct property type selected? Match sc-domain or URL-prefix consistently. - Site added in Search Atlas? Confirm under Site Explorer. - Waited 24–48 hours? Allow time after any reconnection or re-activation. 💬 Still Seeing the Error? If you have followed all the steps above and the GSC Performance tool still shows a site activation error or is not importing data correctly, our team is ready to investigate your specific account configuration. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Fix Website 404 Errors and Network Issues

🔍 What This Article Covers If your website is displaying only the home page correctly while other pages return 404 errors or show an ERR_NETWORK_CHANGED message in your browser, this guide will help you identify the cause and resolve it — without unnecessarily removing your OTTO SEO HTML sections. ⚠️ Understanding the Symptoms Before making any changes to your site, it is important to understand what these errors mean: - 404 errors on internal pages: The server cannot find the requested page. This is usually a server, hosting, or URL configuration issue — not a Search Atlas or OTTO SEO problem. - ERR_NETWORK_CHANGED: Your local network connection changed while the browser was loading the page. This is a client-side network issue (on your device or internet connection) and is not caused by your website's content or OTTO HTML sections. 💡 Should You Remove Your OTTO HTML Sections? No. OTTO SEO HTML sections are installed in your page content and do not affect your server routing, URL structure, or network connectivity. Removing them will not fix 404 errors or ERR_NETWORK_CHANGED messages, and doing so unnecessarily will undo your SEO optimisations. Leave your OTTO HTML sections in place while you follow the troubleshooting steps below. 🛠️ Step-by-Step Troubleshooting 1. Test your network connection first. Open a different website in a new browser tab to confirm your internet connection is stable. If other sites also fail to load or behave inconsistently, the issue is with your local network — try restarting your router or switching to a different network. 2. Clear your browser cache and cookies. A stale cache can cause pages to return incorrect 404 responses. In your browser settings, clear cached images, files, and cookies, then reload the affected pages. 3. Test in a private or incognito window. Open an incognito or private browsing window and navigate directly to the pages showing 404 errors. This rules out browser extensions or cached data as the cause. 4. Try a different browser or device. If the pages load correctly in another browser or on a different device, the problem is specific to your original browser's configuration. 5. Check your website's URL structure and redirects. Log in to your hosting control panel and verify that all page URLs are correctly configured. Look for broken redirects, recently changed permalink settings, or misconfigured .htaccess rules (for WordPress sites). 6. Check for recent hosting or DNS changes. If your domain's DNS records or hosting server settings were recently changed, propagation can take up to 48 hours and may cause intermittent 404 errors on certain pages. Contact your hosting provider to confirm no configuration changes were made. 7. Review your CMS permalink settings (WordPress users). Go to Settings → Permalinks in your WordPress dashboard and click Save Changes without modifying anything. This refreshes your rewrite rules and often resolves sudden 404 errors on internal pages. 8. Verify pages exist in your CMS or Website Studio. In Search Atlas, navigate to Website Studio (left sidebar → Website Studio) and confirm that all affected pages are published and have the correct URLs assigned. Unpublished or draft pages will return 404 errors for visitors. ✅ After Troubleshooting Once your pages are loading correctly, verify that your OTTO SEO HTML sections are still present and intact. If any sections appear to be missing after cache clearing or CMS changes, you can re-apply them from within the OTTO SEO workflow. Your SEO settings and configurations are saved in Search Atlas and are not lost during network or server-side issues. 🚫 Common Mistakes to Avoid - Do not remove OTTO HTML sections as a first troubleshooting step — they are not the cause of 404 or network errors. - Do not change your URL structure or permalink settings unless you understand the impact on existing indexed pages. - Do not assume a 404 error is permanent — intermittent 404s during network changes or DNS propagation are temporary and will resolve on their own. 💬 Still Need Help? If you have followed all the steps above and are still experiencing 404 errors or connectivity issues, If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 Fix OTTO Site Audit Crawl Failures

🗺️ Overview When OTTO runs a site audit, it crawls your website to collect SEO data. Occasionally, this crawl may fail or return incomplete results. This article explains the most common causes of crawl failures, how to tell whether the issue is on OTTO's side or yours, and the steps to get your crawl running again. 🔎 How to Check Crawl Status in OTTO 1. Go to Left sidebar → OTTO SEO → All Sites. 2. Locate the site you want to investigate and check its status indicator. 3. For a more detailed view, navigate to Left sidebar → OTTO SEO → Crawl Monitoring. 4. Review the crawl log entries for error messages, timestamps, and any noted interruptions. The Crawl Monitoring page is your first stop for diagnosing what went wrong. It shows whether the crawl started, how far it got, and where it stopped. ⚠️ Common Reasons a Crawl Fails Crawl failures can originate either on OTTO's side or on your website's side. Use the list below to identify which applies to your situation. - Site was unreachable during the crawl: If your server was down, in maintenance mode, or returning 5xx errors at the time OTTO attempted to crawl, the crawl will fail. Check your server logs for the crawl timestamp. - Robots.txt is blocking the crawler: If your robots.txt file disallows all bots or specifically blocks OTTO's user agent, pages will not be crawled. Review your robots.txt at yourdomain.com/robots.txt. - Password protection or authentication walls: If your site requires a login, HTTP authentication, or is behind a firewall, OTTO cannot access pages without credentials. - Crawl budget exceeded or timeout: Very large sites may time out before the crawl completes. This appears as a partial or failed crawl in Crawl Monitoring. - OTTO installation issue: If the OTTO script is not correctly installed, audit features may not function as expected. Verify your setup via Left sidebar → OTTO SEO → Installation Guide. - Temporary platform-side issue: On rare occasions, a crawl may fail due to a transient issue within Search Atlas. These are typically resolved quickly and a recrawl will succeed. ✅ How to Rule Out Issues on Your End Follow these steps to confirm your website is accessible and correctly configured for crawling: 1. Check server uptime: Confirm your site was online at the exact time the crawl was attempted. Cross-reference with your hosting provider's uptime logs. 2. Review robots.txt: Visit yourdomain.com/robots.txt and confirm no rules are blocking all crawlers or OTTO specifically. 3. Disable password protection temporarily: If your site is behind a login or IP restriction, disable it briefly and trigger a recrawl to test access. 4. Verify OTTO installation: Go to Left sidebar → OTTO SEO → Installation Guide and confirm the OTTO script is correctly placed on your site. 5. Test with an external crawler: Use a tool like Google Search Console's URL Inspection to confirm Google can also access your pages. If Google is blocked, OTTO likely is too. 🔄 How to Trigger a Recrawl Once you have identified and resolved the issue, you can manually start a new crawl: 1. Go to Left sidebar → OTTO SEO → All Sites. 2. Select the site you want to recrawl by checking its checkbox. 3. Click the Scan button in the top action bar. 4. Navigate to Left sidebar → OTTO SEO → Crawl Monitoring to watch the crawl progress in real time. If the crawl completes successfully, your updated audit data will appear under Left sidebar → OTTO SEO → All Audits. 📋 What to Do If the Crawl Keeps Failing If you have checked all of the items above and the crawl still fails, gather the following information before reaching out to support: - The domain name of the affected site. - The date and time of the failed crawl (visible in Crawl Monitoring). - Any error messages shown in the crawl log. - Confirmation of whether your robots.txt and server access have been verified. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Fixing Schema Creator Generation Failures

Schema Creator uses AI to build structured data (schema markup) for your pages. If the Generate Schema button seems to do nothing, the Deploy button stays grayed out, or the page keeps reverting to "You haven't generated a schema yet," this guide will help you get back on track quickly. 🔍 Common Symptoms You are likely experiencing one or more of the following: - The Deploy button is disabled (grayed out) after you generate a schema. - The page reverts to "You haven't generated a schema yet" even after clicking Generate Schema several times. - Error and success messages appear at the same time, but no schema is actually created. - FAQ or Breadcrumb schemas generate with empty content, such as missing questions (mainEntity) or missing breadcrumb steps (itemListElement). - A single-page generation returns an error while a bulk generation keeps spinning without finishing. - An intermittent message: "The AI was unable to generate valid schemas for the requested pages." 💡 Why This Happens Most of these issues were caused by bugs on our side, including temporary server errors, conflicting status messages, and empty FAQ or Breadcrumb output. These have been fixed in recent platform updates. However, your browser can still load an older, cached version of the page, which makes the problem reappear even after the fix. In addition, incomplete required fields and clicking Generate Schema repeatedly can interrupt an in-progress request and cause the page to reset. 🛠️ How to Fix It Work through these steps in order. Most customers are back up and running after the first two steps. 1. Hard refresh the page. This clears stuck status messages. Press Ctrl + Shift + R on Windows or Cmd + Shift + R on Mac. 2. Clear your browser cache or open an incognito/private window. This forces your browser to load the latest version of Schema Creator, including the recent bug fixes. 3. Complete all required fields. For FAQ schema, every question needs an answer. For Breadcrumb schema, every step needs a name and a URL. Missing details can cause empty or failed output. 4. Generate one schema at a time. If a bulk generation keeps spinning, try generating a schema for a single page first. Once that succeeds, add more pages in small batches. 5. Wait a few minutes and retry. If you see "The AI was unable to generate valid schemas for the requested pages," the AI service may be briefly busy. Wait 5 to 10 minutes, then click Generate Schema once. 6. Log out and log back in. This resets your session and clears any stale page state that survived the refresh. 📊 Confirming the Fix Worked After completing the steps above, verify everything is working: 1. Open Schema Creator from the Content section in the left sidebar. 2. Click Generate Schema****once and wait for the confirmation message. Generation can take up to a minute, so avoid clicking multiple times. 3. Review the preview. FAQ schemas should list your questions and answers (mainEntity), and Breadcrumb schemas should list every step (itemListElement). 4. Confirm the Deploy button is now active, then click it to publish the schema to your page. ✅ Tips to Avoid Future Failures - Click Generate Schema once and wait. Repeated clicks can interrupt the request and reset the page. - Keep bulk runs small. We recommend generating schemas for 10 pages or fewer at a time. - Fill in every field before generating, especially for FAQ and Breadcrumb schema types. - Hard refresh Schema Creator after a platform update so you are always using the latest version. 💬 Still Failing? Talk to Us If the problem continues after following all of the steps above, have this information ready to speed things up: the page URL you were targeting, the schema type you selected, the exact error message, and the approximate time you clicked Generate Schema. If you need further assistance, open 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 Repeated OTTO Site Audit Crawl Failures

🔍 What a failed crawl means OTTO must crawl your site before it can complete a site audit. A repeated failure can come from your website, access restrictions, slow JavaScript rendering, or an issue during OTTO processing. The message “Crawl failed. We’ll try again soon.” does not by itself identify the exact cause. A failed crawl does not automatically mean the problem is on OTTO’s side. Use the checks below to rule out common website and configuration issues first. 🧭 Check the crawl status 1. Open OTTO SEO from the left sidebar. 2. Open Crawl Monitoring to review the latest crawl status and timing. 3. Open All Audits to confirm whether the audit is still processing, failed, or completed. 4. Check whether multiple attempts failed for the same site and whether the failures occurred at similar stages. Long processing times do not always indicate a failure. Sites that rely heavily on JavaScript may take substantially longer to crawl. Wait for the status to update before starting repeated manual scans. 🌐 Check your website access - Open the site in a private browser window and confirm it loads without a login. - Check that the domain and preferred protocol, such as HTTPS, are correct in the project settings. - Review firewall, CDN, bot protection, and security tools for blocked or challenged crawler requests. - Confirm that robots.txt, noindex rules, or server permissions are not preventing access to important pages. - Check server logs for timeouts, repeated 403 or 429 responses, or 5xx errors during the crawl window. - Make sure the site is not undergoing maintenance or experiencing intermittent downtime. ⚙️ Review OTTO settings 1. Go to OTTO SEO → All Sites. 2. Select the affected site and confirm its URL and configuration. 3. Use Scan to start a new crawl only after checking access and server health. 4. Review OTTO SEO → Installation Guide if the site connection or installation has recently changed. Do not repeatedly start scans while an earlier attempt is still processing. Multiple overlapping attempts can make it harder to identify the original failure and may increase processing time. 📊 How to tell where the issue is The issue is more likely related to your site when the site is unavailable, protected by a challenge page, returning server errors, blocking crawlers, or taking a long time to respond. It is more likely related to platform processing when the site is publicly reachable, server logs show successful access, several attempts fail in the same way, and other site checks work normally. Customers may also see a failure when the crawl completes but the handoff to audit processing does not finish. In that case, the crawl itself may have succeeded even though the audit displays a failure. Share the exact status and timestamp when reporting the issue. 📝 What to collect before contacting support - Site name and domain. - The exact error message. - Approximate start and failure times, including your time zone. - Screenshots from Crawl Monitoring and All Audits. - Whether the site uses a CDN, firewall, bot protection, or JavaScript-heavy pages. - Relevant server log results, including status codes, timeouts, or blocked requests. - Whether a normal browser visit and other crawling tools can access the site. This information helps the team determine whether the failure is caused by site access, crawl duration, or an OTTO processing stage. 💬 Get help with a confirmed failure If the site is accessible, access controls are not blocking crawlers, and multiple attempts continue to fail, the issue may require platform investigation. Include the details above so the team can check the crawl and post-processing stages. If you need further assistance, open 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 Stale Cached Content Still Showing in Crawls

🧩 Why This Happens When Search Atlas crawls your website, it stores a snapshot of your page content in its cache. If you remove text, deactivate a plugin, or make other changes to your site, Search Atlas may still display the old cached version of that page until a fresh crawl is completed and the cache is cleared. This is a common reason customers see removed content — such as phrases like "24/7" — still appearing in Search Atlas reports even after the content has been deleted from the live page. ⚠️ Common Triggers - Plugin deactivation: Deactivating OTTO SEO or another plugin does not immediately force a recrawl. The previous crawl data remains until refreshed. - Page edits without recrawl: Saving changes in your CMS updates your live site but does not automatically notify Search Atlas to recrawl that URL. - Conflicting SEO plugins: Tools like Rank Math can override meta deployments. Search Atlas may show "Deployed" while the live page still renders the original meta from a competing plugin. - Server-side or CDN caching: Your hosting provider or CDN may be serving a cached version of your page to Search Atlas crawlers, making it appear as if old content is still live. ✅ How to Fix Stale Crawl Data 1. Confirm the live page is updated: Open the URL in an incognito/private browser window to verify the content you removed is no longer visible on the actual page. 2. Clear your site cache: If you use a caching plugin (e.g., WP Rocket, W3 Total Cache) or a CDN (e.g., Cloudflare), purge the cache for the affected page so Search Atlas crawlers receive the latest version. 3. Trigger a manual recrawl in Search Atlas: Navigate to the relevant project in Search Atlas, locate the affected URL, and use the Recrawl or Refresh option to queue a fresh crawl of that page. 4. Wait for the crawl to complete: Depending on your site size and crawl queue, this may take a few minutes. Once finished, the updated content will replace the stale snapshot. 5. Verify the result: After the recrawl, reopen the page report in Search Atlas to confirm the outdated content is no longer displayed. 🛠️ If You Use OTTO SEO OTTO SEO includes a Cache Self-Verification system that monitors the health of deployed changes and checks whether your server is accessible to Search Atlas crawlers. If connectivity issues prevent OTTO from verifying a deployment, it will flag this in the platform so you can take action. To check the status of your OTTO deployments: - Go to OTTO SEO → All Sites (SEO Automation) in your Search Atlas dashboard. - Review the deployment status for affected pages. A status of "Deployed" confirms Search Atlas successfully applied the change — but if a conflicting plugin is active, it may override the output on the live page. - If you suspect a conflict, deactivate competing SEO plugins (such as Rank Math or Yoast) and trigger a recrawl to let OTTO's settings take full effect. 🚫 Avoid These Mistakes - Do not assume deactivating a plugin instantly updates Search Atlas data — a manual recrawl is always needed. - Do not run multiple SEO plugins simultaneously. Conflicting plugins can silently override each other's meta settings, causing discrepancies between what Search Atlas reports and what actually renders on your page. - Do not skip clearing your server or CDN cache before triggering a recrawl, as crawlers may still receive the old cached page. 💬 Still Seeing Outdated Content? If you have completed all the steps above and Search Atlas is still displaying stale content, there may be a deeper crawl or connectivity issue that requires investigation. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🗂️ Fix Site Catalog Publisher Filtering Issues

🔍 Overview The Find Publishers button in Site Catalog lets you discover relevant publishers for your website. In some cases, clicking this button may not trigger a publisher search — and a JavaScript error may appear in your browser. This article explains the most common causes and how to fix them. ⚠️ Common Symptoms - Clicking Find Publishers does nothing — no results load and no search request is sent. - A JavaScript error appears in the browser console after clicking the button. - The publisher-search feature works for some websites but not others. 🛠️ Step-by-Step Troubleshooting 1. Check your URL format. Make sure the website URL entered in Site Catalog is correctly formatted. Use the full domain without trailing slashes (e.g., quicksortindia.com rather than www.quicksortindia.com/). Inconsistent URL formats can prevent the publisher-search request from firing correctly. 2. Remove the "www" prefix if present. Some domains trigger a JavaScript parsing error when entered with the www. prefix. Try removing it and entering just the root domain (e.g., quicksortindia.com), then click Find Publishers again. 3. Clear your browser cache and cookies. Cached scripts can interfere with button functionality. Clear your cache, close and reopen your browser, then log back into Search Atlas and retry. 4. Try a different browser. Test the feature in an alternative browser (e.g., Chrome, Firefox, or Edge) to rule out browser-specific JavaScript conflicts. 5. Disable browser extensions. Ad blockers, privacy extensions, or script blockers can prevent publisher-search requests from being sent. Temporarily disable all extensions and try again. 6. Check for JavaScript errors in the console. Open your browser's developer tools (press F12), go to the Console tab, click Find Publishers, and note any red error messages. This information is helpful when contacting support. ✅ Confirming the Fix After following the steps above, a successful publisher search will display a list of relevant publisher results below the Find Publishers button. No error messages will appear in the browser console, and the network request will complete without issue. 💡 Best Practices for Site Catalog - Always enter the root domain without "www" or trailing slashes when adding a site. - Use a modern, up-to-date browser for the best compatibility with Search Atlas features. - If you manage multiple sites, verify each one is correctly listed under Site Metrics (Left sidebar → Site Metrics → Overview) before using publisher filtering. 🆘 Still Need Help? If the Find Publishers button is still not working after completing the steps above, gather the JavaScript error message from your browser console and the exact URL you entered. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.

🔧 How to Fix an Incorrect Page-Level Schema Type

This article explains what to do when the automatically generated schema assigns the wrong page type to your content. Based on known platform behavior, the schema page type is determined by AI inference and cannot be manually changed through a user-facing setting. Triggering another crawl is unlikely to resolve the misclassification, as pages with mixed or ambiguous signals may be consistently assigned an incorrect type. 📍 What This Means for You If your page has been assigned an incorrect schema page type, this is a platform limitation — there is currently no confirmed self-serve workflow that allows you to override the AI-assigned schema type directly within the tool. Attempting to retrigger a crawl will not reliably fix the misclassification. 🛠️ How to Get This Resolved Because the schema page type cannot be manually changed, the resolution requires direct assistance from our support team. To help us investigate and act on your request as quickly as possible, please have the following ready before reaching out: - The exact URL(s) of the affected page(s) - The schema type currently being assigned (the incorrect one) - The schema type you expect or need for that page - The project name in Search Atlas where the issue is occurring - Any relevant screenshots or error details showing the misclassification Having this information ready will allow our team to investigate the AI classification behavior for your specific page and take the appropriate backend action. If you need further assistance, open 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 Site Auditor False Positive Redirect Flags

🧭 Overview Some customers notice that Site Auditor raises two specific issues even when their website redirects are correctly configured: - HTTP doesn't redirect to HTTPS - Protocol/WWW variants don't redirect to the same place These flags are false positives — meaning your redirects are working as expected, but the auditor has incorrectly marked them as errors. This article explains why this happens and what steps you can take to resolve it and recover your Site Health points. ⚠️ Why These False Positives Occur Site Auditor checks your site's redirect behaviour by testing several URL variants, including: - http://yourdomain.com - http://www.yourdomain.com - https://yourdomain.com - https://www.yourdomain.com In some cases, the auditor may not correctly confirm that all variants resolve to the same canonical destination, and flags the redirects as broken — even if they are functioning correctly. This is a known detection limitation and does not mean your site has an actual SEO problem. ✅ How to Confirm Your Redirects Are Correct Before taking any action inside Search Atlas, verify your redirects are properly set up using an external tool. This rules out a genuine configuration issue on your end. 1. Go to a free redirect checker such as httpstatus.io or redirect-checker.org. 2. Test all four URL variants listed above for your domain. 3. Confirm that each variant returns a 301 redirect leading to your preferred canonical URL (typically https://www.yourdomain.com or https://yourdomain.com). 4. Make sure all variants ultimately land on the same final destination. If your external redirect test passes cleanly, the flags in Site Auditor are confirmed false positives and the steps below will resolve them. 🔄 How to Clear the False Positive Flags The most reliable way to resolve false positive redirect flags is to trigger a fresh crawl of your site. Follow these steps: 1. Log in to your Search Atlas account. 2. In the left sidebar, go to OTTO SEO → Site Audit. 3. Initiate a new crawl of your site using the crawl option available within Site Auditor. 4. Wait for the crawl to complete — this can take a few minutes depending on your site size. 5. Once the crawl finishes, return to your Site Health report and check whether the two redirect flags have been cleared. In most cases, a fresh crawl is enough to resolve these false positive flags and restore your Site Health score. If the flags persist after re-crawling, please escalate so our team can investigate further. When reaching out, have the following ready: your project name, the exact flag names shown in Site Auditor, and a screenshot or export of your external redirect checker results. If you need further assistance, open 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 Crawl Failures and Pixel Detection Issues

Site Explorer Fails on Bot-Protected Websites

Overview When you add a client website to Site Explorer, Search Atlas crawls the domain to populate its report. If the site uses bot-protection measures — such as a CAPTCHA challenge — the crawler may be blocked mid-crawl. This can result in the project displaying an incorrect site name or image, and in some cases the project may appear to have failed even though your quota has been used. This article explains what causes the issue, how to identify it, and what steps to take. What Causes This Issue Some websites use bot-detection services that trigger a CAPTCHA or access-denial page when automated crawlers visit them. When this happens during a Site Explorer crawl, the crawler captures the CAPTCHA page rather than the real website. As a result: - The project may display an incorrect site title or thumbnail image. - The report may appear incomplete or show unexpected data. - Your project slot quota is consumed even though the crawl did not complete successfully. This is a known platform behaviour. It cannot be resolved from within the platform UI, and there are no steps you can take on your side to fix the affected project. Engineering has already implemented improvements to detect and handle bot-protected pages more gracefully, so false site titles are less likely to be captured going forward. How to Identify the Problem You may be experiencing this issue if: - You tried to add a client domain to Site Explorer and the project saved but shows incorrect or placeholder information. - You see a site name or image that clearly belongs to a CAPTCHA or access-denied page rather than the real website. - You attempted to add a second domain and received a quota-limit message, even though you believed you had available slots — this may indicate a previous crawl silently consumed a slot due to a bot-protection failure. Steps to Take 1. Confirm which domains are already saved. Open Site Explorer and review your existing projects. This helps you verify whether a domain was added (even if the crawl failed) and whether your quota has genuinely been consumed. 2. Do not attempt to re-add the same domain repeatedly. Each attempt may consume an additional quota slot without producing a usable report. 3. Check whether the client site uses bot protection. If you can confirm the site has a CAPTCHA or firewall service (such as Cloudflare's challenge page, hCaptcha, or similar), this is most likely the root cause. 4. Contact support. Because this issue requires a manual fix on the back end — including restoring any quota incorrectly consumed — you will need to reach out to our team. If you need further assistance, please contact our support team directly so we can restore any affected quota and investigate the failed crawl.

🚫 Fix Google Image URL Errors in PR Distribution

🔍 What Is This Error? When you proceed after creating a press release in PR Distribution, you may see an error message that reads [URL] is too long. This error appears when an image URL in your press release is hosted on Google's servers — specifically any URL containing googleusercontent.com. Google-hosted image URLs are blocked in PR Distribution. This is a platform-level restriction, not a browser or account issue. The error will always appear for these URLs regardless of the image size or file type. ⚠️ Why Google-Hosted URLs Are Blocked URLs from googleusercontent.com are blocked in PR Distribution. Because PR Distribution syndicates your press release to multiple third-party publishers, all image URLs must be stable and publicly accessible. Google-hosted URLs do not meet these requirements and are blocked at the point of submission. ✅ Three Ways to Fix This You have three options to resolve this error. Choose the one that best fits your workflow. 📤 Option 1 — Upload the Image Directly 1. Open your press release in PR Distribution. 2. Replace the existing Google-hosted image URL with an image uploaded from your device. 3. Proceed to the next step to continue. This is the recommended option. Directly uploaded images are stored on Search Atlas servers, ensuring they remain accessible to all distribution partners. 🌐 Option 2 — Use a Publicly Hosted Image URL 1. Upload your image to a reliable public hosting service such as your own website, a CDN, WordPress Media Library, Imgur, or a similar platform. 2. Copy the direct image URL from that service. The URL should end in a file extension such as .jpg, .png, or .webp. 3. Open your press release in PR Distribution and replace the Google-hosted URL with the new public URL. 4. Proceed to the next step to continue. Make sure the URL you use is a direct link to the image file itself, not a webpage that contains the image. You can verify this by opening the URL in a browser — it should display only the image, with no surrounding page content. 💾 Option 3 — Download the Image, Then Upload It 1. Open the Google-hosted image URL in your browser. 2. Right-click the image and select Save image as to download it to your device. 3. Open your press release in PR Distribution. 4. Replace the existing Google-hosted URL with the image file you just downloaded. 5. Proceed to the next step to continue. This option is useful if you do not have access to the original image file and need to re-host it yourself. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

⏱️ Site Audit Suddenly Taking Much Longer Than Usual

🔍 What This Article Covers If your site audit is taking significantly longer than usual — for example, an hour when it normally completes in five minutes — this is called a performance regression. This is different from an audit that has always been slow. A sudden, dramatic increase in duration usually has a specific cause that can be identified and resolved. This article walks you through how to diagnose it. ⚠️ First: Confirm It Is a Regression, Not a One-Off Before investigating, confirm the pattern is real and not an isolated incident. - Check when the slow audit occurred and whether it has happened more than once recently. - Compare the current audit duration with your last three to five completed audits to establish a clear baseline. - Note whether any changes were made to your site or audit settings around the time the slowdown began. If the duration has increased consistently and significantly (more than three times your normal baseline), proceed with the steps below. 📋 Step 1: Check Whether Your Site Has Grown The most common reason for a legitimate audit slowdown is that your site now has substantially more pages to crawl than before. 1. Open Site Metrics → Site Explorer (Site Explorer) from the left sidebar. 2. Locate your domain and review the total indexed or crawled page count from your most recent audit report. 3. Compare this with historical audit reports to see whether the page count has increased significantly. A site that has grown from 200 pages to 2,000 pages will naturally take longer to audit. If this is the case, the increased duration is expected and no action is required beyond adjusting your expectations. 🛠️ Step 2: Review Your Crawl Settings Misconfigured crawl settings can cause the crawler to work much harder than necessary, dramatically increasing audit time. 1. Navigate to your site audit project settings. 2. Check the crawl limit — if it has been increased recently, the audit will take longer. 3. Check whether subdomains or external links have been enabled for crawling, as these expand the scope significantly. 4. Verify that URL patterns you do not need audited (such as pagination, filtered URLs, or staging paths) are excluded using the URL exclusion settings. Reset any settings that were changed unintentionally and re-run the audit to see whether duration returns to normal. 🌐 Step 3: Check for Site-Side Issues If your crawl settings are unchanged and your page count is the same, the slowdown may be caused by your website responding more slowly than usual to the crawler's requests. - Server response time: If your server is under heavy load or experiencing issues, every page request takes longer, multiplying across hundreds or thousands of pages. - Redirects: A sudden increase in redirect chains (for example, after a site migration or plugin update) forces the crawler to follow multiple hops per URL. - JavaScript rendering: If JavaScript rendering has been enabled in your audit settings and your site recently added heavy JavaScript pages, crawl time increases substantially. - New redirect loops: Even a small number of pages caught in redirect loops can stall the crawler and inflate total audit time. To check for these issues, run an independent speed test on your site (such as Google PageSpeed Insights or a server uptime monitor) and review your site's recent change log or deployment history for anything that may have affected response times or URL structure. 🔄 Step 4: Cancel the Stuck Audit and Re-Run If the audit has been running for an unusually long time with no sign of completing, it may have stalled rather than simply being slow. In this case: 1. Cancel the current audit run from within your site audit project. 2. Wait two to three minutes before starting a new run. 3. Monitor the new run for the first few minutes to confirm pages are being processed at a normal rate. A stalled audit is different from a slow one — stalled audits show little or no progress in page count over a long period. Re-running typically resolves this. 📊 Step 5: Compare Audit Reports for Clues Your completed audit reports contain information that can help identify what changed. 1. Open your most recent completed audit report and note the total URLs crawled, total issues found, and any high volumes of specific issue types such as redirect chains or server errors. 2. Compare these figures with a report from before the slowdown began. 3. A spike in 3xx redirects, 5xx server errors, or total URL count between reports is a strong indicator of what is causing the increased duration. ✅ Quick Reference: Common Causes and Fixes - Page count increased: Expected — audit takes longer as your site grows. - Crawl limit raised in settings: Lower it back to your previous value. - Subdomains or external links enabled: Disable if not needed. - Server slowdown or high load: Investigate with your hosting provider and re-run when resolved. - Recent site migration or URL restructure: Review and fix redirect chains. - Audit stalled rather than slow: Cancel and re-run the audit. 💬 Still Seeing Unusually Long Audit Times? If you have worked through all the steps above and your audit is still taking much longer than your normal baseline, our team can investigate whether there is a system-level issue affecting your project. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Fix Shopify Title Tags and Crawler Whitelisting

🔍 Overview Two of the most common issues Search Atlas customers encounter with Shopify are: title tag changes not appearing on the live site and the Search Atlas crawler being blocked from accessing the site. This article walks you through the causes and the steps to resolve both problems. ⚙️ Why Title Tag Updates Are Not Appearing Shopify's architecture differs from traditional CMS platforms. Meta title changes made through Search Atlas are applied via your site's deployment channel, but several Shopify-specific factors can prevent those changes from going live. Common reasons title tags are not updating: - Theme not connected: Search Atlas must be connected to your active Shopify theme. If your theme was recently changed or republished, the connection may have been lost. - Deployment not visible: Shopify website deployments are sometimes not detected inside the platform. If your site does not appear under your Website Deployments list, the changes cannot be pushed correctly. - Metafield or app embed not enabled: Search Atlas delivers on-page optimisations through a theme app extension. If the app embed block is not active in your Shopify theme editor, updates will not render on the front end. - Caching: Shopify and third-party CDNs (such as Cloudflare) cache page content aggressively. Even after a successful update, you may see outdated title tags until the cache clears. ✅ How to Fix Title Tag Updates 1. Confirm your Shopify site is connected: Go to Settings → Websites in Search Atlas and verify your Shopify store appears as an active deployment. If it is missing, go to Settings → CMS Connectors and use the Edit, Reconnect, or Disconnect options for your Shopify connection. 2. Enable the app embed block: In your Shopify Admin, navigate to Online Store → Themes → Customize. Open App Embeds and make sure the Search Atlas embed is toggled on. Save the theme. 3. Re-publish your active theme: If you recently switched themes or made theme edits, re-saving and publishing the active theme re-triggers the app extension render. 4. Clear your cache: After confirming the above steps, purge any CDN or browser cache and reload the page. Use an incognito window or a tool like Google's URL Inspection in Search Console to check the live title tag as Google sees it. 5. Check OTTO deployment status: If you are using OTTO SEO, open the OTTO dashboard and confirm the site status shows as Active. A status of Undetected or Inactive means OTTO has not successfully fingerprinted your Shopify store. 🚫 Why the Search Atlas Crawler Is Being Blocked The Search Atlas Site Audit and OTTO use a dedicated crawler to scan your pages. Shopify stores can inadvertently block this crawler in several ways, which prevents audits from running and stops OTTO from reading your live page data. Common causes of crawler blocking: - Password-protected storefront: If your Shopify store is in development mode or behind a storefront password, all external bots — including the Search Atlas crawler — are blocked. - Cloudflare or firewall rules: WAF (Web Application Firewall) rules, bot-fight mode, or custom firewall policies can identify and block the crawler before it reaches your pages. - robots.txt restrictions: A restrictive robots.txt file may be disallowing the crawler user agent from accessing key paths. - Shopify bot protection: Shopify has built-in bot protection that can flag and block unfamiliar crawlers, especially on high-traffic or enterprise plans. ✅ How to Whitelist the Search Atlas Crawler 1. Remove the storefront password: In Shopify Admin, go to Online Store → Preferences and disable the storefront password if it is enabled. 2. Whitelist the crawler IP in Cloudflare: If your store uses Cloudflare, create a WAF Allow rule or an IP Access rule that permits the Search Atlas crawler. Contact our support team via the chat widget to obtain the current crawler IP range. 3. Disable Bot Fight Mode temporarily: In Cloudflare, go to Security → Bots and temporarily disable Bot Fight Mode, then re-run your Site Audit to confirm access. Re-enable it after creating an explicit allow rule. 4. Check your robots.txt: Visit yourstore.com/robots.txt and confirm there are no Disallow directives that would block the Search Atlas user agent. Shopify's default robots.txt is generally crawler-friendly, but custom apps or scripts may have modified it. 5. Re-run the Site Audit: After making these changes, go to OTTO SEO → Site Audit → Overview (Website Overview) in Search Atlas and click Recrawl Site to trigger a fresh scan. Monitor the crawl progress to confirm pages are now being indexed. 📊 How to Verify Everything Is Working - Your Shopify store appears as Active under Website Deployments in Search Atlas. - The Site Audit completes with a full page count and no crawler-blocked errors. - Title tag updates are visible when you inspect the page source or use Google's URL Inspection tool. - OTTO shows a detected CMS: Shopify status on the site dashboard. 💬 Still Need Help? If you have followed all the steps above and are still experiencing issues with title tags or crawler access, our team is ready to 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.

🔍 Fix Website Ownership Verification Tag Issues

🧭 Overview Before Search Atlas can fully analyse and manage your website, it needs to confirm you own it. This is done by adding a verification tag to your website's <head> section. If ownership verification still fails after adding the tag, this guide explains what to check on your end — and what to have ready if the issue requires escalation to our support team for a backend fix. ⚙️ How Verification Works Search Atlas generates a unique meta tag for your website. You add this tag inside the <head> element of your homepage's HTML. Search Atlas then crawls your homepage and looks for that exact tag. If it finds the tag, ownership is confirmed. If it does not, verification fails. 🛠️ Common Things to Check First 1. Copy the tag exactly as provided. Open Search Atlas, navigate to the website verification area, and copy the full meta tag. Even a single extra space or missing character can cause the check to fail. 2. Confirm the tag is inside <head>, not <body>. The tag must appear between the opening <head> and closing </head> tags of your homepage. Tags placed in the body or footer are not detected. 3. Check that it is on the correct page. Verification only checks your root domain homepage (for example, https://yoursite.com). If your tag is on a sub-page or a staging URL, it will not be found. 4. Confirm the page is publicly accessible. Search Atlas cannot crawl pages that are behind a login, password protection, or a maintenance-mode screen. Temporarily disable any access restrictions and retry. 📋 What to Have Ready When Escalating If you have checked all of the above and verification still fails, the issue may require a backend action from our team. When you reach out, please have the following ready so we can resolve it as quickly as possible: - The exact website URL you are trying to verify (your root domain homepage) - The project name in Search Atlas where the verification is set up - A screenshot or copy of the verification tag as it currently appears in your page's HTML source - Any error message displayed on screen, including the exact wording - The date and time you last attempted 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.

🔄 Fix a Site Audit Stuck in Recrawling

🔍 What Is the Recrawling Status? When you trigger a manual crawl in Site Audit, the tool sets the crawl status to Recrawling while it processes your pages. In most cases this completes within a reasonable amount of time, depending on your site size and page limit. Occasionally, a crawl can get stuck in Recrawling status for an extended period without progressing to completion. During this time, some controls may become unavailable. This is a known platform issue that our engineering team is actively working to resolve. ⚠️ Why Does This Happen? A crawl can become stuck due to internal processing conditions that prevent it from completing or resetting automatically. Importantly, a stuck crawl does not overwrite or delete your existing audit data. Your previously collected data remains intact while the crawl is stalled. ✅ What You Can Do Right Now 1. Wait and allow time to pass — Short stalls occasionally resolve on their own once the background process catches up. If the crawl has not been stuck for very long, allow it more time before escalating. 2. Refresh the page — After waiting, do a hard refresh (Ctrl + Shift + R on Windows, Cmd + Shift + R on Mac) to reload the latest crawl status from the server. 3. Check if results have populated — Even if the status still shows Recrawling, scroll through your Site Audit results. Data often finishes processing before the status label updates correctly. 4. Do not delete the audit — Deleting the audit is irreversible and will permanently remove all previously collected data. Avoid this step unless instructed by the support team. 🛠️ When to Contact Support If your crawl has been stuck in Recrawling status for an extended period without any progress, our support team can intervene on the backend to cancel or force-complete the crawl without deleting your audit data. Before reaching out, gather the following information so the team can act quickly: - The name or URL of the affected site audit project. - How long the crawl has been stuck (approximate start time and current page count). - A screenshot showing the Recrawling status and any unavailable controls, if possible. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Fix Site Audit, JS Rendering, and Credit Errors

🔍 Overview This article covers four common issues Search Atlas customers run into: a Site Audit showing 0 crawled pages, JS Rendering appearing enabled on a Starter plan, article generation failing despite available credits, and OTTO SEO showing a Disengaged status. Each section explains why the issue happens and the steps to resolve it. 📊 Site Audit Shows 0 Crawled Pages If your Site Audit completes but shows 0 crawled pages, or appears stuck for many hours, one of the following is likely the cause. JS Rendering is slowing the crawl significantly. When JS Rendering is enabled, crawls run approximately 19 times slower than a standard crawl. A site with a modest crawl budget can take 13–31 hours to finish. This is expected behaviour, not a failure — the crawl is still running in the background. What to do: 1. Go to OTTO SEO and open your Site Audit settings. 2. Check whether JS Rendering is toggled on. 3. If you do not specifically need JavaScript rendering for your site, turn it off and re-run the crawl. The audit will complete much faster. 4. If JS Rendering is required, allow up to 31 hours for the crawl to finish before assuming it is stuck. 5. If the crawl remains at 0 pages after 31 hours with JS Rendering off, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team. ⚙️ JS Rendering Appears Enabled on a Starter Plan JS Rendering is a feature available on higher-tier plans. If you are on a Starter plan and see JS Rendering toggled on inside your Site Audit settings, this is a display issue — the toggle may appear active but the feature does not run at the crawl level on your plan. What to do: 1. Navigate to your Site Audit settings within OTTO SEO. 2. Manually toggle JS Rendering off, then save your settings. 3. Re-run the Site Audit to confirm pages are crawled correctly. 4. If the toggle cannot be changed or the problem persists, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team. If you need JS Rendering as a core part of your workflow, consider upgrading your plan. You can review plan options from your account settings. 💡 Cannot Generate Articles Despite Having Credits Seeing an error when generating articles — even though your credit balance shows available credits — is usually caused by one of three things: a temporary sync delay, a session issue, or credits being allocated to a different workspace. What to do: 1. Refresh your browser and navigate back to Left sidebar → Content → Content Genius (What are we writing today?). 2. Check that you are in the correct workspace — credits are workspace-specific. Switch workspaces from the top of the left sidebar if you manage more than one. 3. Try generating a single article rather than multiple at once to rule out a bulk-request error. 4. Log out and log back in to force a session refresh, then attempt article generation again. 5. If the error message references a specific credit type (for example, AI words vs. article credits), confirm which credit pool applies to the article type you are generating. Different content tools within Content may draw from different credit pools. 6. If none of the above resolves the issue, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team — share a screenshot of the error message to speed up the resolution. 🚀 OTTO SEO Shows "Disengaged" Status An OTTO Disengaged status means OTTO is not actively applying or monitoring optimisations for the connected site. This can happen after a plan change, a site reconnection, or if OTTO was manually disengaged previously. What to do: 1. Open OTTO SEO → All Sites (SEO Automation) from the left sidebar. 2. Select the site that shows Disengaged. 3. Look for the Engage OTTO button on the site dashboard and click it. 4. Confirm the engagement prompt if one appears. 5. Wait a few minutes, then refresh the page to verify the status has changed to Active. 6. Re-run your Site Audit after re-engaging OTTO so that suggestions and deployed changes are reported accurately. Note: If OTTO was disengaged during a period when JS Rendering was active, some page titles or deployed changes may have been misreported. Re-running the audit after re-engaging resolves this display inconsistency. 🔄 Quick Troubleshooting Reference - Crawl stuck or slow: Disable JS Rendering and re-run, or wait up to 31 hours if JS Rendering is needed. - JS Rendering toggle on Starter plan: Turn it off manually and re-run the audit. - Article credit error: Check workspace, refresh session, confirm correct credit pool. - OTTO Disengaged: Click Engage OTTO, then re-run the Site Audit. If you need further assistance, open 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 Site Audit Postprocessing Failures and Schema Quota

🔍 Overview Some customers notice that their site audit crawls complete the crawling phase but then show both crawl_state: failed and postprocessing_status: failed. In the same session, schema generation may consume quota credits for pages — sometimes 17 or more — while producing no visible output. This article explains what causes these issues, what they mean for your data, and what steps you can take right now. ⚙️ What Is Postprocessing and Why Does It Fail? After Search Atlas finishes crawling your site, it runs a postprocessing stage that compiles raw crawl data into the audit issues, scores, and recommendations you see in your dashboard. If this stage fails, the audit cannot display results — even if pages were successfully crawled. The most common reason postprocessing fails is a data conflict caused by concurrent activity. If a second crawl starts — or existing crawl data shifts — while the first crawl is still being processed, the system encounters rows it cannot reconcile and throws an internal error. This is a known platform issue and engineering has already deployed a fix for the most common crash scenarios (KeyError and IndexError during issue compilation). Other factors that can contribute to postprocessing failures include: - JavaScript-heavy pages: Sites with JS rendering can take significantly longer to crawl (median crawl time is over 13 hours in some cases). A crawl that appears stuck may still be running. Do not cancel and restart — this can trigger the concurrent conflict described above. - Homepage detection errors: On certain site configurations, the system fails to identify the homepage correctly, resulting in zero pages crawled and a failed state. This is actively being resolved by engineering. - Stale recrawl frequency settings: Some audits are stuck on a "never reprocess" state due to missing recrawl frequency data. A backfill fix is in progress to resolve this automatically. 📊 Why Does Schema Generation Consume Quota With No Output? Schema generation quota is deducted at the point the generation job is triggered — before output is confirmed. If postprocessing fails or the crawl produces incomplete page data, the schema generation job may still fire for the pages that were queued, consume credits, and then fail silently because it has no valid page content to work with. This means you can lose quota credits for pages — such as the 17-page scenario — without receiving any schema markup in return. The credits are consumed because the generation attempt was made, not because output was produced. Your credits are not lost permanently. If schema generation fails due to a platform-side postprocessing error rather than invalid input on your end, the support team can review your account and arrange a credit adjustment where appropriate. 🚀 Steps to Take Right Now 1. Check your crawl status: Go to Left sidebar → OTTO SEO → Site Audit → All Audits and review the status of the affected audit. If the status shows failed, do not immediately trigger a re-crawl. 2. Wait before retrying: If your site uses JavaScript rendering, allow at least 14–16 hours before concluding a crawl is stuck. Cancelling early and restarting increases the risk of a concurrent conflict. 3. Avoid running overlapping crawls: Do not start a new crawl for the same site while a previous crawl or postprocessing job is still active. Check Left sidebar → OTTO SEO → Site Audit → Crawl Monitoring to confirm all jobs for that site have fully completed before launching a new one. 4. Retry the audit once: After confirming no other crawl is active for the site, go to Left sidebar → OTTO SEO → Site Audit → All Audits, locate the failed audit, and trigger a fresh crawl. The platform fix for postprocessing crashes is already deployed and should resolve the most common failure mode. 5. Note your quota consumption: If schema generation consumed credits without producing output during the failed session, make a note of the affected site name, the date of the failed crawl, and the approximate number of pages affected. You will need this when contacting support for a credit review. 💡 What to Expect Going Forward The engineering team has resolved the primary crash causing postprocessing failures. Additional fixes currently in development will address homepage detection errors and stale recrawl frequency settings. These will be applied automatically — no action is needed on your part. If you re-run the audit and it fails again, or if you believe your schema quota was consumed unfairly, the support team can investigate your specific account logs and take action. 🆘 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 Bing IndexNow Connection and Quota Issues

🗺️ Overview Bing IndexNow lets Search Atlas submit URLs directly to Bing for faster indexing. However, IndexNow connections are governed by platform-wide daily quotas managed by Bing. If your connection attempt fails — even after following the correct setup steps — a quota limit is almost always the cause. This article explains how quotas work, how to recognise exhaustion, and how to restore a working connection. ⚙️ How to Connect Bing IndexNow If you have not yet connected IndexNow, follow these steps first: 1. In the left sidebar, go to Authority → Indexer. 2. Click Index URLs. 3. Select Bing IndexNow as your indexing channel. 4. Follow the on-screen prompts to authenticate and activate the connection. If the connection completes without errors, you are ready to submit URLs. If you see a connection failure or an error message at step 4, continue to the quota section below before retrying. 📊 Understanding Platform-Wide Daily Quotas Search Atlas uses a shared pool of IndexNow submissions allocated by Bing. Key points to understand: - The quota is platform-wide. It is not tied to your individual account — it is shared across all Search Atlas users submitting to Bing IndexNow on the same day. - Quotas reset daily. Bing resets the available submission pool once every 24 hours, typically in the early hours UTC. Exact reset timing can vary slightly day to day. - High-demand periods exhaust the quota faster. During peak usage hours (roughly mid-morning to early afternoon UTC), the shared pool can be consumed quickly, leaving later connection attempts or URL submissions unable to complete. - Your account settings and API key remain intact. A quota-related failure does not break your integration — it simply means no submissions can be sent until the pool refreshes. 🚨 Symptoms of Quota Exhaustion You are likely hitting a quota limit — not a configuration problem — if you observe any of the following: - The IndexNow connection shows as failed or inactive despite previously working correctly. - URL submission attempts return an error or silently fail with no confirmation. - The issue appeared suddenly without any changes to your account or settings. - Retrying the connection immediately produces the same failure. - Other Search Atlas users report similar IndexNow issues on the same day. If your setup was working before and none of your credentials or project settings changed, assume quota exhaustion first and proceed to the troubleshooting steps below. 🔧 Troubleshooting Steps When a Connection Fails 1. Check the Quotas panel. Click the Quotas icon in the global header (visible on every page). This panel shows current usage and may indicate whether the Bing IndexNow pool is exhausted for the day. 2. Do not retry immediately. Repeated connection attempts while the quota is exhausted will not succeed and may count against rate limits. Wait for the daily reset instead. 3. Note the time of failure. If the failure occurs during peak hours (mid-morning to early afternoon UTC), plan to retry after the daily reset in early UTC morning hours. 4. Verify your configuration has not changed. Go to Authority → Indexer and confirm your project is still selected and your IndexNow channel is listed. If settings appear altered, re-enter your credentials and save before waiting for the reset. 5. Retry after the daily reset. Once the quota pool refreshes, return to Authority → Indexer, click Index URLs, and attempt the connection or submission again. 6. Confirm success. A successful submission will show a confirmation message. If the failure persists after the reset, escalate using the chat widget (see below). ✅ Best Practices to Minimise Quota Failures - Schedule submissions for off-peak hours. Submit URLs in the early UTC morning (approximately 00:00–06:00 UTC) when the quota pool has recently reset and platform-wide demand is lowest. - Batch your URLs efficiently. Rather than submitting URLs one at a time throughout the day, group submissions to make the most of available quota in a single session. - Prioritise high-value URLs. If quota is limited, submit your most important new or updated pages first rather than resubmitting already-indexed content. - Monitor the Quotas panel regularly. Check the Quotas icon in the global header before large submission runs to confirm capacity is available. - Avoid peak hours for large batches. Mid-morning to early afternoon UTC sees the highest platform-wide usage. Save bulk submissions for quieter periods. 💬 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 Your Website Not Globally Crawlable Flag

🔍 What Does 'Not Globally Crawlable' Mean? When Google flags your website as not globally crawlable, it means Googlebot is being blocked from accessing your site from certain regions or entirely. This prevents Google from fully indexing your pages, which can seriously hurt your search visibility and rankings. This flag typically appears in Google Search Console and signals that something in your site's configuration is restricting crawl access at a global level. ⚠️ Common Causes of This Issue - IP-based geo-blocking: Your server or CDN is blocking requests from Google's IP ranges, which are routed through US-based data centers but crawl on behalf of all regions. - Robots.txt misconfiguration: A disallow rule is unintentionally blocking Googlebot from crawling key pages or your entire site. - Firewall or security rules: Web application firewalls (WAFs) or DDoS protection tools (e.g., Cloudflare) may be flagging Googlebot as suspicious traffic and blocking it. - CDN or hosting restrictions: Your content delivery network may have regional access rules that prevent crawlers from non-local IP ranges. - HTTP authentication: Password-protected staging environments or pages requiring login block all crawlers by default. - VPN or proxy detection: Some security plugins block requests that appear to come from proxy servers or data centers, which includes Googlebot. 🛠️ How to Diagnose the Problem 1. Check Google Search Console: Navigate to Settings → Crawling in Google Search Console. If the "Not globally crawlable" warning is active, note any additional details provided. 2. Test your robots.txt: Go to https://yourdomain.com/robots.txt and review the rules. Use Google Search Console's robots.txt Tester to check if Googlebot is being blocked. 3. Use the URL Inspection Tool: In Google Search Console, use the URL Inspection Tool on your homepage and key pages. Select Test Live URL to see if Googlebot can currently access those pages. 4. Review your firewall and CDN settings: Log in to your hosting panel, CDN dashboard (e.g., Cloudflare), or WAF settings and check for any rules that block bot traffic or restrict access by IP range or geography. 5. Check for HTTP authentication: Confirm that no password protection is active on your live site, especially if you recently migrated from a staging environment. ✅ How to Fix the Issue - Update robots.txt: Remove any Disallow: / rules that block all crawlers. Make sure the rule targeting Googlebot does not restrict access to important pages. A correctly configured robots.txt should include User-agent: * followed only by specific disallow rules for pages you intentionally want excluded. - Whitelist Googlebot in your firewall or CDN: Add Google's verified crawler IP ranges to your allowlist. You can find the current list at developers.google.com/search/apis/ipranges/googlebot.json. In Cloudflare, create a firewall rule that allows requests where the verified bot equals Googlebot. - Disable geo-blocking for crawlers: If you use server-side geo-restrictions, configure an exception for verified search engine bots. Work with your hosting provider or developer to implement this safely. - Remove HTTP authentication from live pages: Ensure your production environment does not have basic auth enabled. This is a common oversight after launching from a staging setup. - Disable aggressive bot-blocking plugins: If you use a WordPress security plugin (e.g., Wordfence, iThemes Security), check that it is not blocking requests from data center IPs, as Googlebot crawls from data centers. 📊 Verify the Fix in Search Atlas After making changes, use Search Atlas to monitor your site's crawlability and indexing health. Navigate to Left sidebar → Site Metrics (Site Explorer) to review your site's overall performance and spot any remaining technical issues affecting your search visibility. You should also return to Google Search Console and re-run the URL Inspection Test on your homepage to confirm Googlebot can now access your site. It may take a few days for the flag to clear after Google re-crawls your site. 💡 Prevention Tips - Always review your robots.txt before and after a site migration or relaunch. - Test crawl access in a staging environment before going live. - Set up Google Search Console alerts so you are notified immediately if crawl issues are detected. - Regularly audit your firewall and CDN rules to ensure legitimate bots are not accidentally blocked. 🙋 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.

🔗 What to Do If Your Published Link Returns a 404

🔗 Why a Live Placement Can Start Returning a 404 Occasionally a link that was live and working stops resolving. This has a few different causes, and the fix depends on which one applies: - A system bug moved the article back to draft. If support confirms this, it's fixed on our side and the article goes back to its original URL — no action needed from you once it's resolved. - An issue on the publisher's own site. If the publisher's site itself had a temporary problem, the article becomes accessible again once they resolve it on their end. - The publisher can't or won't fix it. In this case, support can offer a replacement placement or process a refund, depending on the situation. ✅ What to Expect When You Report a 404 When you report a broken link, support will check the specific order and give you an itemized status — some links may already be confirmed live and good, others reset and reassigned to a new publisher, and others flagged for a refund if a placement genuinely can't be recovered. If several orders are affected at once, each one gets checked individually rather than resolved as a single blanket action. If a refund applies, it's typically issued as HDC (Hyperdrive Credits) to your account rather than a reversal to your original payment method. 🎯 Updating a Target URL After Checkout If you need to change the destination URL for a placement you've already checked out (for example, you selected the wrong page by mistake), support can update the target landing page on an existing order — you don't need to cancel and reorder. 🧭 Keeping This Separate from Other Search Atlas Brands This applies to Link Laboratory backlink placements specifically — separate from Publication Media (the publisher-side platform), Signal Genesys (press release distribution), and Search Atlas's own Authority Building/Digital PR features. If you need further assistance, open 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 Inaccurate N/A Results in Grid Map Scans

🔍 Understanding the Problem Grid map scans (also called Local SEO Heatmaps) may sometimes display N/A across most or all grid points, appear to scan indefinitely, or show a "scan is taking longer than expected" message. When a scan does complete, rankings may not match what you see on a live Google search. These issues can be caused by a few different factors, including incorrect grid configuration, coordinate mismatches, or a temporary backend processing delay. The good news is that most of these problems can be resolved by following the steps below. ⚙️ Common Causes of N/A Results - Incorrect grid spacing or radius: If the grid spacing setting does not align with the scan radius, the system may scan the wrong area entirely and return no usable ranking data. - Coordinate mismatch: In some cases, the coordinates stored for your business location may not match what is being passed to the scan, causing pins to appear in the wrong place or not at all. - Scan timeout: Large grid sizes (for example, a 21×21 grid or higher) require significantly more processing time. If the scan exceeds the expected window, it may return incomplete or empty results. - Cached or stale scan data: The last-scan date shown in the list view may sometimes differ from the detail view, meaning you could be looking at outdated results rather than the most recent scan. - Competitor data not loading: Pins may complete without populating competitor analysis, which can make rankings appear artificially low or show unexpected drops. 🛠️ Steps to Resolve the Issue 1. Check your grid settings before scanning. Go to your Local SEO Heatmap configuration and confirm that the grid size, point spacing (in miles or kilometres), and scan radius are set consistently. A mismatch between spacing and radius is one of the most common causes of inaccurate results. 2. Verify your business location pin. On the map setup screen, confirm that the centre pin is placed directly on your Google Business Profile location. If it appears offset or in the wrong area, drag it to the correct position and save before rescanning. 3. Reduce the grid size for a test scan. If you are using a large grid (15×15 or higher), try running a smaller test scan first (for example, 7×7 or 9×9). This completes faster and helps confirm whether the issue is grid-size related or something else. 4. Wait and then refresh the results. If the scan shows "taking longer than expected," do not cancel it. Leave the page open or return after 10–15 minutes and refresh. Large scans process in the background and will complete. 5. Run a fresh scan rather than relying on cached results. If the last-scan date looks inconsistent between the list view and the detail view, start a new scan manually to ensure you are viewing up-to-date data. 6. Compare results against a live Google search. After a scan completes, manually search your target keyword on Google Maps in an incognito window from the same approximate location. If the ranking shown in Search Atlas is significantly different (especially for positions above 10), note the keyword, grid point, and date — this information helps our team investigate further. 📊 What Good Results Should Look Like A successfully completed scan should show colour-coded ranking pins across all (or nearly all) grid points. Green pins indicate strong rankings (positions 1–3), yellow pins indicate mid-range rankings, and red pins indicate weaker positions. N/A should only appear for grid points where your business genuinely has no ranking data — for example, points that fall outside a serviceable area or where Google returned no result for that keyword. If the majority of pins show N/A after a completed scan, this is a signal that something went wrong during the scan process rather than a reflection of your actual rankings. 🚀 When to Escalate to Our Team Try the steps above first. If you have verified your settings, run a fresh scan, and are still seeing widespread N/A results or rankings that clearly do not match live Google data, our team can investigate the backend scan data directly. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team. To help us resolve your issue faster, please have the following ready: the business name, the keyword used in the scan, the grid size, and a screenshot of both the heatmap result and the live Google search result you are comparing it to.

📧 Fix Site Audit Export Email Not Arriving

🔍 Overview After requesting a Site Audit export, Search Atlas sends a download link to your registered email address. In some cases, this email may be delayed or fail to arrive entirely. This is a known delivery issue that our team resolves on the backend — there are no account settings you can change to fix it yourself. ⚠️ What May Be Happening - Email routed to spam or junk: Automated emails from SaaS platforms are occasionally filtered by email providers. - Incorrect email address on your account: The notification is sent to the email associated with your Search Atlas account, which may differ from the one you expect. - Backend delivery failure: In some cases the export email fails to send due to a platform-side issue that requires our team to investigate and resolve directly. 🛠️ Initial Checks Before Escalating 1. Check your spam, junk, and promotions folders. Search for emails from searchatlas.com or no-reply in all folders, including any filtered or archived views. 2. Verify the email address on your account. Log in to Search Atlas, navigate to your account settings, and confirm the registered email address matches the inbox you are checking. 📋 How to Escalate to Our Team If the email is not in your spam folder and your account email is correct, this is a backend issue that our support team needs to investigate. When you contact us, please have the following ready so we can resolve it as quickly as possible: - The name of the Site Audit project for which you requested the export - The email address registered on your Search Atlas account - The approximate date and time you triggered the export - Confirmation that you have already checked your spam and junk folders Our team will look into the delivery failure and ensure your export link is sent successfully. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔄 Fix Stuck OTTO Recrawl and Site Audit Jobs

🔍 Overview OTTO recrawl and Site Audit jobs normally complete within a few hours. If your job has been running for more than 24 hours without finishing, it is likely stuck due to a processing error. This article explains why this happens, what you can do right now, and when to contact support. ⚠️ Why Jobs Get Stuck Several known issues can cause a recrawl or audit job to stall indefinitely: - Status misread: OTTO incorrectly reads a completed task as still processing, causing it to wait indefinitely for a result that already exists. - Orphaned reprocess task: A background reprocessing task gets detached from its parent job and loops without ever finishing. - No staleness guard: Older jobs lacked a timeout mechanism, so a stuck job had no automatic way to recover. - Recrawl frequency not set: Some audits were missing a recrawl frequency value, which prevented them from progressing through the queue correctly. - Image recheck routing: OTTO image rechecks were not always routed correctly to the Site Audit queue, causing them to stall. The Search Atlas engineering team has resolved the most common root causes. If your job is still stuck, the steps below will help you recover it manually. 🛠️ How to Unstick a Recrawl or Audit Job 1. Check the current status. Go to Left sidebar → OTTO SEO → All Audits. Find the affected site and note how long the job has been running. If it has been more than 24 hours, it is safe to assume it is stuck. 2. Refresh the job. On the All Sites page (Left sidebar → OTTO SEO → All Sites), locate your site and click Scan. This triggers a fresh crawl request and can override a stalled job. 3. Wait up to 30 minutes. After triggering a new scan, allow up to 30 minutes for the status to update. Refresh the page periodically to check for progress. 4. Check Crawl Monitoring. Navigate to Left sidebar → OTTO SEO → Crawl Monitoring to see if the crawl is actively processing URLs. If the counter is moving, the job has recovered. 5. Review the Overview page. Go to Left sidebar → OTTO SEO → Overview to confirm that suggestions and audit results are being generated after the crawl completes. ✅ What a Healthy Job Looks Like - The crawl status updates within a few minutes of being triggered. - Crawl Monitoring shows a URL counter actively increasing. - The audit completes and new suggestions appear in the Overview within a few hours for most sites. - Sites with very large page counts (thousands of pages) may take longer but should still show visible progress. 💡 Tips to Prevent Future Stuck Jobs - Avoid triggering multiple scans in quick succession. Starting a new scan before the previous one finishes can create conflicting tasks in the queue. - Check your site is reachable. If your website is down or returning errors when OTTO tries to crawl it, the job may stall waiting for a valid response. Confirm your site loads correctly before starting a scan. - Keep your OTTO connection active. A disconnected or improperly installed OTTO may cause audit tasks to fail silently. Refer to Left sidebar → OTTO SEO → Installation Guide if you need to verify your setup. 💬 Still Stuck After Following These Steps? If your recrawl or audit job is still not progressing after you have tried the steps above, our team can manually investigate and reset the job on your behalf. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team. Please have the following information ready to speed up the investigation: - Your website URL (e.g. sowebdesigns.co.uk) - The date and time you first noticed the job was stuck - Any error messages or unusual statuses shown in All Audits or Crawl Monitoring

🔍 Fix OTTO Site Audit Crawl Failures and Recrawls

🔍 Overview If your OTTO site audit shows a "Crawl failed. We'll try again soon." message, or if a crawl appears stuck and never completes, this article explains what causes these failures, what OTTO does automatically, and what steps you can take to resolve the issue. ⚠️ What Causes a Crawl Failure? OTTO crawl failures can be caused by issues on either the platform side or your website. Common causes include: - Temporary server unavailability — your site was unreachable at the time of the crawl - Crawl budget or rate-limiting — your server blocked or throttled the crawl bot - robots.txt restrictions — crawling is blocked for the user agent OTTO uses - Post-processing interruptions — the crawl completed but data failed to process correctly afterward - Platform-side processing errors — an internal issue prevented the crawl from finishing or handing off results In most cases, the failure is not caused by something you did wrong. OTTO is designed to detect these failures and retry automatically. 🔄 What OTTO Does Automatically When a crawl fails, OTTO will attempt to retry the crawl on your behalf. You do not need to take any action immediately. However, if the retry does not resolve the issue within a reasonable time, or if the audit remains stuck, you should follow the manual steps below. 🛠️ How to Manually Trigger a Recrawl 1. Go to Left sidebar → OTTO SEO → All Sites. 2. Locate the site showing the crawl failure or stuck audit. 3. Click the Scan button associated with that site to trigger a fresh crawl. 4. Monitor the crawl progress under Left sidebar → OTTO SEO → Crawl Monitoring. 5. Once the crawl completes, check Left sidebar → OTTO SEO → All Audits to confirm audit results have been generated. ✅ How to Rule Out Issues on Your End Before escalating, check the following on your website: - robots.txt — confirm that crawlers are not blocked. Visit yourdomain.com/robots.txt and look for any Disallow rules that may apply to all bots or the OTTO crawl agent. - Server availability — confirm your site was online and responding at the time of the crawl failure. - Firewall or security plugins — tools like Cloudflare, Wordfence, or similar services may block automated crawlers. Temporarily whitelist the crawl or add an exception if needed. - Site speed and stability — if your server is slow or overloaded, the crawl may time out. Check your hosting performance during the crawl window. If none of the above apply and your site appears healthy, the failure is likely on OTTO's side and our team can investigate further. 📊 Check Crawl Status in Real Time Use Left sidebar → OTTO SEO → Crawl Monitoring to view the live status of your crawl. This page shows whether the crawl is in progress, completed, or failed. If the status appears stuck for more than 30 minutes without updating, proceed with a manual recrawl using the steps above. 💡 Tips to Prevent Future Crawl Failures - Ensure your site is accessible to crawl bots and not behind authentication walls during scheduled crawls. - Avoid running large server maintenance tasks or deployments during active crawls. - Keep your robots.txt updated and review it after any site changes. - Check your hosting plan to ensure it can handle crawl traffic without rate-limiting or throttling. 🆘 Still Experiencing Issues? If you have followed the steps above and your crawl is still failing or stuck, our team can investigate whether the issue is on the platform side and manually trigger reprocessing if needed. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔄 Fix a Stalled OTTO Recrawl Investigation

🔍 What Is a Stalled OTTO Recrawl? When OTTO runs a recrawl, it scans your website to refresh audit data and generate updated SEO suggestions. In most cases, a recrawl completes within a few hours. If your recrawl has been running for more than 24 hours without finishing, it is considered stalled. This can happen due to a processing loop, an orphaned reprocess task, or a missing staleness guard that normally resets stuck jobs automatically. ⚠️ Common Causes - Async task loop: The recrawl job enters a repeated "still processing" state and never exits. - Orphaned reprocess task: A background task loses its connection to the crawl job and keeps running silently. - Missing recrawl frequency setting: Some audits were previously set to "never reprocess," which prevented automatic restarts. - Spinner never clears: The UI shows a loading spinner indefinitely, even though the underlying job has stalled. 🧭 How to Check Your Recrawl Status 1. In the left sidebar, click OTTO SEO, then select All Sites. 2. Find your website in the list and check the recrawl status indicator next to it. 3. Click on your site to open its detail view, then navigate to Crawl Monitoring in the left sidebar under OTTO SEO. 4. Review the crawl log for the most recent entry. If the status reads "processing" or "still processing" and the timestamp is older than 24 hours, the recrawl is stalled. 5. You can also go to All Audits to confirm whether audit data or suggestions appear outdated or missing. 🛠️ Steps to Attempt Recovery 1. Go to OTTO SEO → All Sites in the left sidebar. 2. Select the checkbox next to your stalled site. 3. Click Scan at the top of the page to trigger a fresh crawl manually. 4. Wait 10–15 minutes, then return to Crawl Monitoring to verify the new crawl has started and the previous stalled status has cleared. 5. If the spinner is still visible and no progress is shown after 30 minutes, do not trigger additional scans — multiple overlapping jobs can worsen the issue. 📊 What to Expect After a Successful Restart Once the crawl resumes correctly, you will see the status update in Crawl Monitoring and new audit data will appear under All Audits. OTTO suggestions including title tag recommendations and on-page fixes will regenerate automatically. Depending on your site size, this can take anywhere from 30 minutes to a few hours. 💡 How to Prevent Stalled Recrawls - Avoid triggering multiple manual scans in quick succession — let each scan complete before starting another. - Check Crawl Monitoring regularly if you have a large site, as bigger crawls are more prone to timeout issues. - If you notice suggestions are not updating even though no crawl appears to be running, use the Scan button to kick off a fresh recrawl rather than waiting for the automatic schedule. 🆘 When to Contact Support If your recrawl remains stalled after following the steps above, or if triggering a new scan does not resolve the issue, our team can investigate and manually clear the orphaned task on the backend. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team. When reaching out, please have the following ready to speed up the investigation: your website URL, the approximate time the recrawl started, and a screenshot of the Crawl Monitoring page showing the stalled status.

🔍 Fix Auto Scan Failures and Run Manual Crawls

🧭 Overview If your auto scan did not run on its scheduled date, there are several possible causes. This article walks you through the most common reasons a scan is skipped and shows you exactly how to run a manual crawl so you never lose an audit cycle. ⚠️ Why Your Auto Scan May Have Been Skipped A missed auto scan is rarely caused by a single issue. Work through each of the following checks before concluding the root cause. ✅ Check 1: Scheduling Settings The most common reason a scan does not run is that the schedule was never saved correctly or was changed accidentally. 1. Open the project that missed its scan. 2. Navigate to the scheduling or crawl settings for that project. 3. Confirm the scan frequency (daily, weekly, monthly) is set to the option you expect. 4. Check that the scheduled date and time match your intended configuration. 5. If anything looks incorrect, update the settings and save your changes. ✅ Check 2: Account Permissions and Crawl Credits Auto scans may require the correct role permissions and sufficient crawl credits on your plan. - Permissions: If your account role was recently changed, your scheduled scan may have been affected. Check with your account owner if you are unsure about your current permissions. - Crawl credits: If your account reached its crawl credit limit, the scan may have been skipped. Check your account's usage or billing information to verify your remaining credits. ✅ Check 3: Rate Limiting on Your Website Search Atlas respects server-side rate limits. If your website's server returned too many errors or throttled the crawler, the scan may have stopped or been skipped entirely. - Check your website's server logs around the expected scan time for any error spikes or throttling activity. - If rate limiting is active, consider adjusting your server's crawl rate settings or reducing the crawl depth in your project's settings. ✅ Check 4: Bot-Blocking or Firewall Rules (Including Cloudflare) Security tools such as Cloudflare, Sucuri, or a custom Web Application Firewall (WAF) can block the Search Atlas crawler, causing a scan to fail silently. - Log in to your firewall or CDN provider and review the firewall activity log for blocked requests around the scheduled scan time. - Look for blocked requests from the Search Atlas crawler user agent. - If you find blocks, add the Search Atlas crawler to your allowlist, or contact the person who manages your website's security settings. - Note: If you do not have access to these settings yourself, you will need to ask your website administrator or developer to make this change. 🔄 How to Run a Manual Crawl If you need to run a crawl immediately rather than waiting for the next scheduled scan, you can trigger a manual crawl from within your project's crawl or audit settings. Look for an option to start or run a new crawl and confirm the action to begin. 📞 Still Need Help? If you have worked through all of the checks above and your auto scan is still not running, or if you are unsure which step applies to your situation, please reach out to our support team. When you do, have the following ready: your project name, the date and time the scan was expected to run, and any error messages you have seen. If you need further assistance, open 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 Crawl Processing and URL Tracking

🔍 Overview Search Atlas audits crawl your site, then process the collected pages before adding them to audit results and page catalogs. A post-processing failure can prevent newly discovered pages from appearing. Tracking scripts may also report incorrect URLs when trailing slashes are handled inconsistently. 🧭 Check the Audit 1. Open AI SEO → OTTO SEO → All Audits. 2. Find the affected audit, such as audit ID 120474, and review its status and results. 3. Check whether the audit shows a processing, partial crawl, or page collection warning. 4. Compare the number of crawled pages with the number of cataloged pages. If the crawl completed but new pages are not cataloged, the issue may be in the handoff or post-processing stage rather than in the site crawl itself. ⚙️ Retry a Blocked Process Open AI SEO → OTTO SEO → Crawl Monitoring to review the crawl and processing status. Allow an active job to finish before starting another scan. If the process remains blocked, record the audit ID, site, approximate start time, and the affected page URLs. Do not repeatedly launch scans for the same site while a previous job is still processing. This can make it harder to identify the original failure. Search Atlas is improving post-processing reliability with safer retries, clearer partial-failure messages, and more reliable crawl-to-processing handoffs. 🔗 Check Trailing-Slash URLs A URL with a trailing slash and the same URL without one can be treated as different strings by tracking systems. For example, https://example.com/page/ and https://example.com/page may produce separate records even when the server treats them as the same page. 1. Confirm the canonical URL format used by your site. 2. Check whether the MetaSync or OTTO tracker script generates URLs in that same format. 3. Use one consistent format for page URLs, canonical references, internal links, and tracking events. 4. After updating the implementation, run a fresh scan and compare the reported URLs with the canonical format. Do not manually remove the slash from every URL unless your site officially uses the non-slash format. The correct format is the one enforced by your redirects and canonical URLs. 🛠️ Validate OTTO and MetaSync Setup Open AI SEO → OTTO SEO → Installation Guide and confirm that the current installation instructions are followed. Then review the affected site under AI SEO → OTTO SEO → All Sites. Confirm that the site is selected correctly and that its crawl and tracking configuration matches the live site. For deeper site-level comparison, use Site Metrics → Analyze and review the project history for duplicate URL variants or missing pages. 📊 What to Include in a Report - Audit ID and site name. - Examples of pages that were crawled but not cataloged. - Examples showing both trailing-slash URL formats. - The audit, crawl, or processing status displayed in the platform. - The approximate time the issue occurred. - Whether the issue affects one site or multiple sites. This information helps the team distinguish a crawl problem from a post-processing or URL-normalization problem. 💬 Get Help If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Fix OTTO Schema Reversions

🔍 Why schema markup can revert An approved LocalBusiness schema correction may appear to revert when a later OTTO deployment action replaces, undeploys, or reprocesses the page-level schema. A mass undeploy or domain-level deployment change can remove a previously applied correction. In some cases, stale schema records with an invalid status can also block a new deployment. The live page may continue serving older schema if the previous markup was not fully removed or if another deployment source is still active. Approval confirms the proposed correction; it does not prevent later deployment changes from updating the live markup. 📋 Audit the deployment history 1. Open the affected project and identify the exact URL where the schema changed. 2. Review the OTTO schema deployment history for that URL and the domain around the time of the reversion. 3. Look for page-level undeployments, mass undeploy actions, domain-level changes, failed deployments, or records marked stale or invalid. 4. Compare the last approved schema with the schema currently shown on the live page. 5. Record the event time, affected URL, schema type, deployment status, and any error or validity message. This audit identifies whether the change came from an intentional deployment action, a cleanup process, or a stale schema record that prevented the correction from being applied. ✅ Restore accurate structured data 1. Confirm the business facts first, including the business name, address, phone number, hours, URL, and location details. 2. Remove or resolve the stale or invalid schema record through the OTTO schema workflow. Do not change valid business facts just to work around a deployment error. 3. Submit the corrected LocalBusiness schema for approval when required. 4. Deploy the approved schema through OTTO using the affected page or domain deployment workflow. 5. After deployment, verify the live page source and a structured-data testing tool to confirm that the intended schema is present and outdated markup is gone. Using the OTTO workflow preserves the approved facts and creates a traceable deployment record. Avoid manually adding replacement schema to the site while an OTTO deployment is being repaired, because multiple sources can cause conflicting or duplicate markup. 🧪 Verify deployment integrity - Confirm the schema record is valid and no longer marked stale. - Check that the deployment status shows completed rather than stuck or failed. - Verify the live page contains one consistent LocalBusiness definition where appropriate. - Recheck the page after caching has cleared, since the live result may not update immediately. - Keep the deployment event details if the schema changes again. 💡 Prevent future reversions Before approving or deploying a correction, confirm the target URL and deployment scope. Review recent domain-level and page-level actions before running bulk changes. When a deployment is stuck, resolve the stale schema status first instead of repeatedly submitting the same correction. This protects valid business information and makes the deployment history easier to trace. 💬 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.

🛠️ Investigate Crawl Post-Processing Issues

🔍 What this issue means Crawl post-processing happens after pages are discovered. During this stage, Search Atlas prepares crawl data for cataloging, reporting, and downstream tools such as MetaSync and OTTO. If processing is blocked or incomplete, newly discovered pages may not appear in the catalog even though the crawl started successfully. 📋 Review the affected audit 1. Open OTTO SEO from the left sidebar. 2. Select All Audits. 3. Find the affected audit, such as audit ID 120474, and open its results. 4. Check whether the audit shows processing, partial crawl, or page-level errors. 5. Compare the number of discovered pages with the number of cataloged pages. A difference between discovered and cataloged pages usually indicates a crawl-to-processing handoff or post-processing issue rather than a problem with the site’s page content. 🔄 Retry processing safely 1. Allow an audit that is still processing time to complete before starting another scan. 2. If processing is stalled, return to OTTO SEO → All Sites and select the site. 3. Use Scan to start a fresh crawl after confirming the site is accessible. 4. Review the new audit and confirm that discovered pages move into the catalog. Do not repeatedly launch scans for the same site while an audit is active. Repeated scans can make it harder to identify which crawl produced the incomplete results. 🔗 Check trailing-slash tracking URLs Tracking scripts must use the same URL format as the pages they reference. A trailing-slash mismatch can cause tracking, matching, or page updates to fail. For example, these are different URL strings: - https://example.com/page/ - https://example.com/page 1. Confirm the site’s preferred URL format by checking its canonical tags and redirect behavior. 2. Use that format consistently in MetaSync and OTTO tracker configuration. 3. Make sure the script does not add or remove a trailing slash inconsistently. 4. Test the script on the homepage and on a representative interior page. 5. Re-run the audit and verify that the tracked URL matches the cataloged URL exactly. ✅ Validate the result - Open OTTO SEO → Crawl Monitoring to review crawl activity. - Confirm that processing finishes without a blocker. - Check that newly discovered pages are cataloged. - Verify that page URLs in tracking requests use the site’s preferred trailing-slash format. - Use OTTO SEO → Overview to confirm that site status and page counts are updated. If pages remain missing after a fresh scan, record the audit ID, site URL, approximate start time, discovered page count, and cataloged page count. This information helps the team distinguish a processing failure from a site access or URL-format issue. 💬 Get help with a persistent blocker Some post-processing failures require platform-side investigation or a retry of the crawl handoff. If the issue continues after these checks, include the audit ID and the validation results when reporting it. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Troubleshoot OTTO Site Audit Crawls

🔍 What a Failed Crawl Means An OTTO site audit crawl can fail because the website blocks the crawler, access details are incomplete, the site is temporarily unavailable, or a platform processing step encounters an error. A failed crawl does not automatically mean the issue is on your side or on OTTO’s side. Some crawls also take longer when JavaScript rendering is enabled or when a site is large. During this time, the crawl may appear stuck even though processing is still in progress. 📊 Check the Crawl Status 1. In the left sidebar, open OTTO SEO. 2. Select Crawl Monitoring to review recent crawl activity and status messages. 3. Open All Audits to check whether the audit completed, failed, or is still processing. 4. Review the affected site under All Sites and note the latest crawl time and error message. Messages such as “Crawl failed. We’ll try again soon.” indicate that the platform could not complete the crawl. The message alone may not identify whether the cause is website access, site performance, or an internal processing issue. ⚙️ Check Your Website Setup - Confirm the website is online and loads normally in a browser. - Check that robots.txt or security tools are not blocking Search Atlas or OTTO crawlers. - Review firewall, CDN, bot protection, and rate-limit settings for blocked requests or challenge pages. - Confirm that required OTTO installation or access settings are complete. Open OTTO SEO → Installation Guide to review the setup. - Check whether recent hosting, DNS, redirect, authentication, or security changes could affect crawling. - For JavaScript-heavy sites, allow additional processing time before treating a long-running crawl as failed. 🔄 Retry the Crawl Safely 1. Resolve any access or website availability issues first. 2. Open OTTO SEO → All Sites. 3. Select the affected site and choose Scan. 4. Monitor the new attempt in Crawl Monitoring. Avoid starting many scans in quick succession. Repeated retries can make it harder to identify the original cause and may increase processing time. 🧭 Tell Platform Issues From Site Issues The issue is more likely related to the website when the site is unavailable, crawler requests are blocked, security challenges appear, or the failure begins after a site configuration change. The issue may be platform-related when the website is reachable, crawler access is allowed, the same site repeatedly fails without configuration changes, or multiple sites show similar failures at the same time. Internal handoff and post-processing failures can also cause a crawl to fail after the crawling stage has completed. 💬 When to Contact Support Before contacting support, record the site name, approximate failure time, exact status message, recent website changes, and whether a retry produced the same result. This helps the team determine whether the failure occurred during crawling or later processing. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔭 Site Explorer Sub-Folder Auto-Detection Fixed

A bug in Site Explorer prevented the Sub Folder analyze mode from auto-detecting when setting up a new project — this has now been resolved so your project setup works as expected from the start. ✨ What's New When creating a new project in Site Explorer and selecting Sub Folder as the analyze mode, the mode will now automatically detect the correct sub-folder as intended. Previously, this auto-detection never triggered, requiring manual intervention or causing incorrect project configurations. 🛠️ What Changed This was a backend engineering fix (SE-1043) shipped as part of the Site Explorer release on 2026-07-24. No action is required on your part — the improvement applies automatically to all new projects going forward. 📋 What to Expect This fix applies automatically — no changes to your existing workflow are needed. New projects created with the Sub Folder analyze mode will now auto-detect without any manual workaround. Existing projects are not affected by this change. If you experience any unexpected behavior with Sub Folder auto-detection, please have the following ready when reaching out: your project name, the URL you entered, and a description of what you observed. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔀 Fix Persistent Redirects After Disabling Plugin Rules

🔍 Why Does the Redirect Still Happen? When you deactivate a redirect rule in the Search Atlas plugin, the rule is removed from the plugin's configuration immediately. However, a 301 redirect is cacheable by design — browsers, CDNs, hosting servers, and edge networks are all permitted to store and serve a 301 response without checking the origin server again. This means the redirect can continue firing even after the rule no longer exists, because a cached copy is being served from one or more layers in the delivery chain. Common sources of a cached redirect include: - Browser cache — your own browser or a visitor's browser has stored the 301 locally - CDN or proxy cache — services like Cloudflare, Fastly, or a hosting-level proxy cache the response at the edge - Server-level page cache — caching plugins (e.g. WP Rocket, W3 Total Cache, LiteSpeed Cache) or server software (Nginx, Apache) may have cached the redirect response - Search Atlas backend cache — in some configurations, redirect responses routed through Search Atlas infrastructure may be held in a short-lived cache 🛠️ Step-by-Step: Clear the Redirect From Every Layer 1. Confirm the rule is deactivated in Search Atlas. Go to the Search Atlas plugin → Settings tab and turn on the Disable Redirection toggle to disable the feature. Save your changes. 2. Clear your browser cache. In Chrome or Edge, open Settings → Privacy and Security → Clear Browsing Data and select Cached images and files. In Firefox, go to Settings → Privacy and Security → Clear Data. Alternatively, open the URL in a private/incognito window to test without any local cache. 3. Purge your caching plugin or server cache. If you use WP Rocket, LiteSpeed Cache, W3 Total Cache, or a similar plugin, navigate to its dashboard and click Purge All or Clear All Cache. If your host provides a server-level cache (e.g. SiteGround, WP Engine, Kinsta), log in to your hosting dashboard and clear the cache there as well. 4. Purge your CDN cache. If your site runs behind Cloudflare or another CDN, log in to your CDN dashboard and purge the specific URL or purge everything. Refer to your CDN provider's documentation for the exact steps to clear a cached URL. 5. Test with a redirect checker. Use a tool such as httpstatus.io or redirectdetective.com to trace the redirect chain for the affected URL. If the 301 no longer appears, the cache has been cleared successfully. If it still appears, note which server or IP address is returning the redirect — this helps identify which cache layer is still holding the response. 6. Wait for TTL expiry if needed. If you cannot manually purge a particular cache layer, the redirect will eventually stop once the cached entry's TTL (time to live) expires. TTL values vary by CDN and server configuration but are typically between a few minutes and 24 hours. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 Fix an Inactive Publication Site Verification Status

🧭 Overview After adding your site to the Search Atlas Publisher Dashboard and placing the required ownership meta tag, you may notice the site still shows an Inactive status — even days or weeks later. This article explains why this happens and walks you through the steps to resolve it. ❓ Why Is My Site Still Showing as Inactive? Verification is confirmed when Search Atlas detects and records a timestamp against your site's ownership meta tag (internally tracked as domain_ownership_verified_at). If that timestamp was never recorded — or if the platform cached an outdated verification state — your site will remain inactive despite the meta tag being correctly in place. A known issue caused some sites to display a stale verification status. The verification banner relied on an older data point (pending_validation) instead of the actual ownership timestamp, meaning sites that met the requirements were sometimes still shown as inactive or unverified. This has been addressed, but manually triggering re-verification is the fastest way to resolve lingering cases. ✅ How to Re-Verify Your Site 1. Make sure your ownership meta tag is still present in the section of your site's homepage. Do not remove it. 2. Log in to Search Atlas and go to your Publisher Dashboard. 3. Locate the affected site in your site list. 4. Click Verify ownership on the site card or within the site's settings. 5. Wait a few moments while Search Atlas re-checks your meta tag and updates the verification timestamp. 6. Once successful, the site status will change from Inactive to Active. 🛠️ Before You Re-Verify — Quick Checklist - Meta tag is present: The ownership meta tag must appear in the of your homepage, not just an inner page. - Meta tag is correct: Copy the tag directly from your Publisher Dashboard to avoid typos. - Page is publicly accessible: Search Atlas must be able to crawl your homepage. Ensure it is not password-protected or blocked by robots.txt. - No caching issues: If you recently added the tag, clear your site's server or CDN cache so the latest version of your page is served to crawlers. ⏱️ How Long Does Re-Verification Take? In most cases, clicking Verify ownership triggers an immediate check and the status updates within a few minutes. If the status does not update after 10–15 minutes, confirm the checklist above is fully satisfied and try again. 📊 Checking Your Site Status You can monitor your site's verification status at any time from the Publisher Dashboard. If your site also appears under Site Metrics (left sidebar → Site Metrics), you can review domain-level data there once verification is confirmed. 💬 Still Need Help? If you have completed all the steps above and your site is still showing as inactive, If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.

🛠️ Site Audit Quota and OTTO Site Allocation Fix

🔍 Overview Each OTTO site you activate requires a Site Audit project for the same domain — if one does not already exist, OTTO automatically creates the Site Audit project first, then creates the OTTO project. OTTO site slots and Site Audit project slots are separate quotas, each with its own limit. If either quota is lower than expected — or does not match what your plan includes — you may be unable to add new OTTO sites, even if you are paying for more capacity. This article explains what causes the mismatch and how to get it resolved quickly. ⚙️ Why This Happens Your Site Audit quota is tied directly to your subscription plan. If your account was set up incorrectly or your quota was not updated when you upgraded, the number of Site Audit slots available on your account may be lower than the number your plan entitles you to. This can leave you stuck: you cannot add new OTTO sites because you have no free OTTO site slot, or no free Site Audit project slot for a brand-new domain, and you cannot free up slots by deleting existing Site Audits because they are linked to active OTTO projects. 📊 What You Can Check First 1. Navigate to the Site Audit section of your account and review how many Site Audits are currently in use. 2. Compare this number against the Site Audit allowance stated on your current plan. You can find your plan details in your account billing or subscription settings. 3. If the number of slots available is lower than your plan's stated allowance, your quota has not been correctly applied and needs to be corrected by our team. 🚀 How to Get Your Quota Corrected This type of quota mismatch cannot be self-corrected from inside the platform — it requires a manual adjustment by our support team. Here is exactly what to do to get it resolved as quickly as possible: 1. Contact our support team through the chat widget in the platform. 2. Tell the agent: "My Site Audit quota does not match my plan entitlement and I cannot add new OTTO sites." 3. Share your current plan name and the number of Site Audit slots you expect to have based on your subscription. 4. The agent will verify your plan details and apply a manual quota correction to your account — this is a straightforward fix that is typically completed within the same support session. 5. Once the agent confirms the fix is applied, return to the Site Audit section and verify that your available slot count has increased. You should then be able to add additional OTTO sites immediately. 💡 Important Notes - Do not delete active Site Audits that are linked to running OTTO projects in order to free up space — this can disrupt your active OTTO automation. Wait for the quota correction instead. - Once your quota is corrected, new Site Audit slots will become available and you can add additional OTTO sites without removing any existing ones. - If you are planning to scale your OTTO usage significantly, mention this to the support agent so they can confirm your total entitlement and apply the right number of slots.

🏠 OTTO Domain Schema Reverting to Old Address

Overview Some users find that after manually updating their domain-level schema in OTTO — particularly the business address — the schema reverts to an older, incorrect address after a few days. This incorrect address can even appear in the live website source code, which affects your local SEO signals. This article explains what to do if you experience this. Why This Happens This is a known platform issue where OTTO may reapply an outdated address to your domain-level schema. Because the root cause exists at the account level rather than in a setting you can directly edit, resolving it requires assistance from the support or engineering team. What You Should Do Now 1. Confirm the correct address. Before reaching out, make a note of the exact address, city, province/state, and postal/ZIP code you want to appear in your schema. Having this ready speeds up the resolution significantly. 2. Check your domain-level schema settings in OTTO. Navigate to your domain schema configuration and verify whether the address shown there matches your intended address. If it appears correct in the settings but still reverts in the deployed schema or site source code, this confirms the issue is occurring at the account level and requires escalation. 3. Attempt a manual re-save. In some cases, opening the domain schema record, re-entering the correct address fields, and explicitly saving the record again can temporarily stabilise the output. Check the site source code after 24 hours to see whether the correct address is now present. 4. Contact support if the issue persists. If the schema continues to revert after a manual re-save, reach out to the support team and provide your correct address details along with the information listed below. The team will review the address stored against your account, confirm the correct entry with you, and work with engineering as needed to ensure the right address is applied going forward. Information to Have Ready When you contact support, please have the following ready so the team can act quickly: - Your correct business address in full (street, city, province/state, postal/ZIP code, country) - The incorrect address currently appearing in your schema or site source code - The domain the schema is deployed on - Roughly when you first noticed the reversion - Whether a manual re-save was attempted and what the result was What Happens After You Report It The support team will review the address stored against your account, confirm the correct entry with you, and work with engineering as needed to ensure the right address is applied. Once resolved, OTTO will use the correct address in your domain-level schema. If you need help at any point, please reach out to our support team and we will be happy to assist.

🛠️ Fix Post-Migration 404 and Indexing Issues

🔍 Why Migrations Cause 404 and Indexing Issues When you migrate a website to a new domain, platform, or URL structure, search engines and visitors may encounter broken pages (404 errors) and indexing delays. This happens because old URLs no longer resolve to active pages, and search engines need time to discover and re-crawl your new URL structure. Common causes include: - Changed URL slugs — Page URLs were altered during migration without redirects in place. - Missing 301 redirects — Old URLs were not mapped to their new destinations. - Outdated XML sitemaps — Sitemaps still reference old URLs or are missing new ones. - Broken internal links — Links within your content still point to old URLs that no longer exist. 📊 Step 1: Identify Issues After Migration After migration, the first step is to identify 404 errors, broken internal links, and pages that are not indexed. You can check Google Search Console's Coverage and Page Indexing reports to see which URLs Google has dropped or cannot index. Review server access logs or your CMS's redirect-manager to find old URLs still receiving traffic but returning 404 status codes. Compile a prioritized list of issues so you know exactly what to fix first — start with your highest-traffic pages and most important internal links. 🛠️ Step 2: Fix 404 Errors on Your Website These fixes must be applied on your website server or CMS. No additional payment is required — these are standard SEO tasks you can handle yourself or with your web developer. The most common and effective solutions are: - Set up 301 redirects — Map each old URL to its new corresponding URL using a permanent redirect. This preserves link equity and automatically sends visitors to the correct page. - Update internal links — Replace any links pointing to old URLs with the new destination URLs across your site. - Update your XML sitemap — Remove old URLs, add the new ones, and submit the updated sitemap in Google Search Console. - Restore deleted pages — If a page was accidentally removed during migration, restore it or redirect it to the most relevant alternative page. Work through the issues in priority order. Start with your highest-traffic pages and most important internal links. 🚀 Step 3: Submit URLs for Re-Indexing Once your redirects and fixes are live, you can accelerate the re-indexing process. You can request re-indexing directly in Google Search Console for individual high-priority URLs by using the URL Inspection tool and selecting 'Request Indexing.' If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 Fix GSC Site Activation 404 Errors

🔍 What the 404 error means A 404 error during Google Search Console (GSC) activation means Search Atlas could not find or update the site connection endpoint. This can result from a temporary backend issue, an unsupported property URL format, or a mismatch between the verified GSC property and the site added in Search Atlas. ✅ Check your GSC property 1. Open Google Search Console and confirm the property is verified. 2. Check whether it is a Domain property or a URL-prefix property. 3. Confirm that the Google account connected to Search Atlas has access to the property. 4. For URL-prefix properties, copy the exact property URL, including https://, the correct domain, and any required path. ⚙️ Use the correct site URL In Search Atlas, use the website’s canonical URL whenever possible. For example, use https://victorypavingnc.com if that is the site’s primary version. Avoid adding extra spaces, page paths, query parameters, or a trailing slash unless the same format appears in the GSC property. Make sure the versions of your site are consistent. These are separate properties in GSC: - http://example.com - https://example.com - https://www.example.com - https://example.com/folder/ 🔗 Activate the site in Search Atlas 1. Open the project in Search Atlas. 2. Go to the GSC integration or Manage Sites panel. 3. Choose the verified GSC property that matches your project URL. 4. Save or activate the site, then wait for the confirmation message. If the property appears in GSC but activation still returns a 404, refresh the page, sign out and back in to the connected Google account, and try once more. Do not create duplicate properties while troubleshooting. 🛠️ If activation still fails A 404 can be caused by a temporary issue with the GSC activation service rather than your website or verification. If the property is verified, the URL matches exactly, and your Google account has access, record the project URL, GSC property type, and approximate time of the failed attempt. This information helps identify whether the issue is account-specific or service-wide. If you see a message such as “Activate your first site” even though sites are already active, the Manage Sites display may not be synchronized with the activation status. Avoid repeatedly changing properties and wait before trying again. 💬 Get help from our team If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔧 Fix WordPress Plugin Approvals, Robots.txt & Content Score

Overview This article covers three common issues Search Atlas customers encounter when using the WordPress Atlas plugin and Content Genius: approval buttons that appear unclickable, AI crawlers being blocked in robots.txt, and content scores that don't improve after generating content. If you are experiencing any of these issues, please reach out to our support team with the details below so we can investigate and resolve them for you. Issue 1: Approval Buttons Are Unclickable (Red Circle Icons) If recommendation approval buttons show a red circle icon and cannot be clicked, this is likely related to a plugin authentication or connectivity issue between the Search Atlas dashboard and your WordPress site. What to have ready when contacting support: - Your project name and the URL of the affected WordPress site - A description of what the approval buttons look like (e.g., red circle icons, greyed out) - The current connection status shown in your Search Atlas dashboard for the WordPress plugin - Any error messages displayed in the plugin or dashboard - Whether you have recently updated the plugin or changed any authentication credentials Issue 2: AI Crawlers Are Blocked in Robots.txt Search Atlas uses AI-based crawlers to analyse your site and generate recommendations. If these crawlers are blocked in your robots.txt file, the plugin may not be able to read your pages and approvals may fail or have no effect. What to have ready when contacting support: - Your site's robots.txt file contents (visit yourdomain.com/robots.txt in your browser and copy the text) - The name of any SEO or robots.txt management plugin you are using (e.g., Yoast SEO, Rank Math) - Your project name in Search Atlas - A description of what crawling or approval behavior you are seeing Issue 3: Content Score Does Not Improve If your content score is not improving after generating or updating content in Content Genius, this may be related to how the plugin is reading your page content or how topical terms are being evaluated. What to have ready when contacting support: - The URL of the page where the content score is not updating - Your project name and the target keyword or topic - A screenshot or description of the current content score and any recommendations shown - Whether you have recently published or updated the page content If you need further assistance, open 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 Site Audit Failures After Hosting Migration

🔍 Overview After migrating your website to a new host, you may notice that Site Audits inside Search Atlas repeatedly fail. This article explains why this happens and what to have ready when contacting our team so the issue can be resolved as quickly as possible. ⚠️ Why This Happens A hosting migration changes several technical details about your site — including its IP address, DNS records, SSL certificate, and server response behaviour. These changes can prevent Search Atlas's audit pipeline from completing successfully, resulting in postprocessing failures and, in some cases, quota consumption without a completed report being produced. ✅ What to Check Before Escalating 1. Confirm your site is publicly reachable. Open a browser in a private/incognito window and navigate to your domain. If the site does not load, the issue is with your hosting setup — resolve DNS propagation or SSL errors with your hosting provider before contacting us, as Search Atlas cannot audit a site that is not publicly accessible. 2. Check for redirects on your root URL. After a migration, root domains sometimes temporarily redirect to a staging URL or return a non-200 status code. Verify that your homepage is loading correctly for external visitors before re-running any audit. 3. Do not repeatedly re-trigger audits while the issue persists. Running multiple audits in quick succession while the underlying connectivity problem is unresolved may result in additional quota consumption without producing output. Wait until your site is confirmed publicly reachable before attempting another audit run. 📋 What to Have Ready When You Contact Support Because this type of failure requires a backend investigation by our engineering team, please gather the following information before reaching out: - The exact project name and domain affected - The approximate date and time the migration took place - The approximate date and time the failed audit was triggered - Any error messages or status indicators you can see within the platform - Confirmation of whether your site is now publicly reachable (and when it became reachable, if it was temporarily down) Having this information ready will allow our team to investigate the backend failure and, where applicable, review any quota consumed during the failed audit. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔧 Fix Shopify 410 Gone Error in Search Atlas

🔍 Overview If you access Search Atlas through Shopify and encounter a 410 Gone error, this is almost always caused by a conflicting browser cookie from a previous Search Atlas session — not a problem with your account or subscription. This article explains why it happens and how to fix it. ⚠️ What Is the 410 Gone Error? A 410 Gone error in Shopify means the browser cannot establish a valid session between Shopify and Search Atlas. It is caused by a conflicting browser cookie from a previous Search Atlas session. This typically happens when: - You have previously logged into Search Atlas directly at app.searchatlas.com in the same browser. - A leftover authentication cookie conflicts with the Shopify-initiated login flow. - The browser tries to use an old session token that is no longer valid. 🛠️ How to Fix the 410 Error Follow these steps to clear the conflict and restore access: 1. Clear your browser cookies and cache. Go to your browser settings, find the option to clear browsing data, select Cookies and other site data and Cached images and files, then confirm. For best results, clear data for All time. 2. Close all browser tabs that have Search Atlas or Shopify open. 3. Reopen your browser and go directly to your Shopify Admin. 4. Navigate to Apps and click on Search Atlas from your installed apps list. 5. The app should now load without the 410 error. If you prefer not to clear all cookies, you can instead try opening Search Atlas from Shopify in a private or incognito window, which starts with a clean cookie state. 💡 Pro Tip: Avoid Future Cookie Conflicts To prevent this issue from recurring, use separate browsers (or browser profiles) for your direct Search Atlas login and your Shopify Admin access. For example, use Chrome for Shopify and Firefox for direct access to app.searchatlas.com. This keeps session cookies isolated and prevents conflicts. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team. Reconnect the Search Atlas app from within Search Atlas: go to Settings → CMS Connectors, find your Shopify connection, and use the Edit, Reconnect or Disconnect options to refresh the authentication session. Your data and settings are stored in your Search Atlas account and will not be affected.

🗺️ Fix Heat Map Data Sync Issues

🔍 What causes this issue? Heat maps may show updated data in the backend while the frontend displays an older result. The frontend retrieves heat map data through background requests and refresh hooks. A delayed refresh, mismatched scan settings, or temporary request overload can prevent the latest data from appearing. ✅ Check the heat map status 1. Open the relevant heat map or local SEO report. 2. Confirm that the backend status shows the scan or data update as complete. 3. Check the scan date, location, device, and selected scan type. 4. Compare these settings with the filters currently selected in the frontend. Different scan types or filters can make the frontend appear outdated even when newer data is available. 🔄 Refresh the frontend data 1. Wait a few minutes after the backend update finishes. Large scans may take additional time to appear. 2. Refresh the heat map page. 3. Reopen the report or grid view and select the correct project, scan, location, and date. 4. If available, switch to another view and then return to the heat map to trigger a new data request. Avoid repeatedly refreshing or opening many heat maps at once. Multiple simultaneous requests can delay processing or cause temporary gateway errors. 🧹 Verify browser and report settings - Confirm you are viewing the correct project and report. - Check that no saved filter is hiding the latest scan. - Sign out and back in if the page continues showing an old result. - Try the page again after a short interval if you see a loading error or gateway timeout. ⚠️ When the issue needs investigation If the backend remains updated but the frontend still shows older data after refreshing and waiting, the issue may involve a synchronization failure between the report view and the data service. This can occur when frontend requests use different scan parameters or when temporary request volume delays the response. When reporting the issue, note the project, heat map or report name, scan date, location, device, selected filters, and the time of the last backend update. Screenshots of the backend status and frontend result can also help the team compare the two views. 💬 Get help If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.

Cloudflare Crawler Whitelisting: Troubleshooting Guide and Alternatives

🔍 Overview When the Search Atlas crawler cannot access a Cloudflare-protected site, the recommended resolution is to have your client whitelist the Search Atlas crawler IPs in their Cloudflare configuration. This guide explains what to request from your client and what information to have ready if you need to escalate. ✅ Step 1: Confirm the Crawler Is Actually Being Blocked Before changing any Cloudflare settings, verify that Cloudflare is the true source of the block. A misconfigured project or incorrect URL can produce the same symptoms. - In your Search Atlas project settings, confirm the target domain is entered correctly, including any subdomain. - Ask your client to check their Cloudflare dashboard for blocked requests around the time the crawl was attempted. If Search Atlas IPs appear as blocked, Cloudflare is actively preventing access. - If no blocks appear in Cloudflare, the issue may be a robots.txt restriction, a server-side firewall, or a login/paywall rather than Cloudflare. Resolve those first before proceeding. ⚙️ Step 2: Review Cloudflare Protection Settings with Your Client Many crawl failures stem from Cloudflare protection settings that your client can adjust without a full IP whitelist. Work with your client to check whether any bot protection, firewall, or rate limiting configurations are blocking the crawler, and whether temporarily adjusting those settings during a scheduled crawl window is feasible. 📋 Step 3: Request IP Whitelisting from Your Client If reviewing and adjusting Cloudflare settings is not sufficient or practical, the resolution is to have your client whitelist the Search Atlas crawler IPs in their Cloudflare configuration. Contact our support team using the method below to obtain the current list of Search Atlas crawler IP addresses to share with your client. 📞 Need Help Escalating? If you are escalating this issue, please have the following ready: the affected project name, the target domain (including any subdomain), and a description of the crawl behavior observed (e.g., fully blocked, partial data returned, specific error messages). If you need further assistance, open 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 SSL Certificate and Subdomain Traffic Issues

Overview OTTO serves optimized content to your website visitors by acting as a proxy layer between your domain and the Search Atlas infrastructure. For this to work correctly, every domain and subdomain connected to OTTO must have a valid SSL certificate. If SSL certificates are missing or misconfigured, OTTO cannot serve traffic on the affected domains, and your SEO automation will not take effect. This article explains the most common causes of SSL and subdomain traffic issues with OTTO and what information to have ready when contacting support. Common Causes of SSL and Traffic Serving Failures - Missing SSL certificate on a subdomain: OTTO requires a valid SSL certificate on every domain and subdomain it serves. If a subdomain (e.g., blog.yourdomain.com or shop.yourdomain.com) does not have an SSL certificate, OTTO will be unable to serve traffic on that subdomain. - Certificate not yet propagated: Newly issued SSL certificates may take time to propagate across DNS. OTTO will not serve traffic until the certificate is fully active and verifiable. - Subdomain not included in OTTO's configuration: If a subdomain was added to your website after OTTO was initially set up, it may not be recognized by OTTO's current configuration. What to Check Before Contacting Support Before escalating, gather the following information so our team can investigate quickly: - The exact domain or subdomain where traffic serving has stopped or SSL errors are appearing - The name of the OTTO project associated with the affected domain - Any error messages you are seeing in your browser or hosting panel - When the issue started and whether any recent changes were made to your domain, DNS settings, or SSL certificate Next Steps Because resolving OTTO SSL certificate and subdomain traffic issues requires our team to inspect your project configuration and certificate status on the backend, there are no self-serve steps that can fully resolve this issue. Please contact support with the details listed above so we can investigate and restore traffic serving 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 404 Errors on Published Website Studio Pages

🔍 Overview After publishing a page in Website Studio, you may occasionally see a 404 error on the live domain even though the page status shows as published and ready inside the platform. This can affect new pages, blog posts, and pages in languages other than your primary site language. This article explains what is happening and how to escalate effectively so our team can resolve the issue for you. ⚙️ Why This Happens A 404 error on a published page is typically a routing issue on the platform side. When a page is published in Website Studio, the live domain's routing layer must register the new URL. In some cases this registration does not complete as expected, leaving the page inaccessible even though it appears published inside the platform. This is a known bug that requires backend investigation to resolve. 🚀 What You Can Try While Waiting 1. Wait a few minutes and hard-refresh. Open the live URL in a new private/incognito browser window and press Ctrl + Shift + R (Windows) or Cmd + Shift + R (Mac) to bypass any cached response. 2. Check that you are using HTTPS. Ensure the URL you are testing starts with https:// rather than http://. Copy the exact URL shown inside Website Studio and paste it directly into your browser. 3. Try republishing the page. Inside Website Studio, open the affected page and publish it again. This can sometimes prompt the routing layer to re-register the URL. If the page is still returning a 404 after attempting the steps above, this will need to be investigated by our support team. 📋 What to Have Ready When You Escalate To help our team resolve this as quickly as possible, please have the following information ready before reaching out: - The exact live URL that is returning the 404 error - The name of the project or website in Website Studio - The page name and the language it was created in (if applicable) - The approximate date and time when you first noticed the error - Any screenshot or screen recording showing the 404 and the published status inside the platform If you need further assistance, open 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 Blank Data in OnPage Audit Fields

🧩 What This Issue Looks Like You open an OnPage Audit and the field labels — such as Content Score, Word Count, and others — are visible but contain no data. (Note: Domain Rating is found under Keywords → Keyword Research (Keyword Research), not in the OnPage Audit.) The audit appears to have run, but every metric is blank or missing values. This is a known bug that requires investigation and a fix on the backend. There are no self-serve UI controls that reliably resolve it. 🛠️ What Is Actually Happening This is a backend data-loading issue affecting certain OnPage Audit projects. When it occurs, the audit fields fail to populate even though the audit appears to have completed. The root cause requires intervention from our engineering team and cannot be resolved by refreshing the page or adjusting browser settings alone. 📋 How to Escalate This Issue Because this is a backend bug, the fastest path to resolution is to contact our support team directly. To help us investigate as quickly as possible, please have the following information ready before reaching out: - Project name — the exact name of the project where the blank fields appear. - Affected fields — list which specific fields are blank (e.g. Content Score, Word Count). - When it started — the approximate date and time you first noticed the issue. - Any error messages — the exact text of any error or warning message displayed on the page, if applicable. Having these details ready will allow our team to locate your project quickly and apply the appropriate backend fix without unnecessary back-and-forth. 💡 What to Expect Once our team investigates your project on the backend, the missing data should be restored. You do not need to delete or recreate your audit — your existing audit and any historical snapshots will remain intact after the fix is applied. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

Site Audit Export Email Not Arriving in Inbox

🔍 Overview After requesting an export of your Site Audit issues, you should receive a download link by email. If that email hasn't arrived after several minutes — or even after multiple export attempts — a known issue may be preventing delivery. This article explains what to check and how to escalate if needed. ⚠️ Known Cause of Missing Export Emails There is a confirmed issue where the Site Audit issues export email is not being delivered to the inbox. This is a known bug that our team is aware of and is being investigated. ✅ Steps to Take Before Contacting Support 1. Check your spam or junk folder. Export emails can occasionally be filtered by your email provider. Search for emails from Search Atlas or with the subject line containing "Site Audit Export." 2. Wait a few minutes and retry. Large audits can take extra time to process. If the export was triggered successfully, the email may still be on its way. Try requesting the export again after waiting. 3. Confirm your email address is correct. Check that the email address associated with your Search Atlas account is accurate and active. You can verify this in your account settings. 💡 Alternative Way to Access Your Data While you wait for the email, you can review your site issues directly inside the platform. All audit findings are available in the Site Audit section without needing to download an export file. You can browse, filter, and action issues from within the tool immediately. 🆘 Still Not Receiving the Email? If you have followed all the steps above and still haven't received the export email, please escalate to our support team. When you do, have the following ready to help us investigate quickly: your project name, the exact time you triggered the export, and the email address 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 Phone Number Timestamp Not Updating After Submission

🔍 Overview After submitting a phone number update, you may notice that the Last Submitted On timestamp does not reflect the new submission date. In some cases, the change may appear to complete successfully but the timestamp remains unchanged, or the update does not fully process. This is a backend issue that our team will need to investigate and resolve on your behalf. ⚠️ Why This Happens The timestamp not refreshing after a phone number submission is a backend-side issue. The exact cause requires investigation by our support team, as it is not something that can be diagnosed or corrected from the platform interface alone. 🛠️ What to Do Because this is a backend issue, there are no self-serve steps that will reliably resolve it. Please reach out to our support team so we can investigate and correct the problem on your account. To help us resolve this as quickly as possible, please have the following ready when you contact us: - The project name or workspace where the phone number update was submitted - The phone number you attempted to submit or update - The date and approximate time of the submission attempt - A description of what you observed — for example, whether the timestamp remained unchanged or the update appeared to succeed but was not saved ✅ What a Successful Update Looks Like Once our team has resolved the issue on the backend, a successful phone number update will be reflected by an updated Last Submitted On date that matches the date the change was applied. If you need further assistance, open 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 Cloud Stack Google Maps URL Errors

If Cloud Stack won't accept a Google Maps short link (like a maps.app.goo.gl URL) or even a full Google Maps URL, this is expected — Cloud Stack does not read map links directly. Instead, it requires the actual iframe embed code from Google Maps. This article shows you exactly where to get that code and where to paste it. 📍 Where to Find It You'll add your map inside Left sidebar → Authority → Cloud Stacks, using the New Cloud Stack or Select Sites options to open the location where your map field lives. 🛠️ Step-by-Step 1. Open Google Maps in a browser and search for the exact business location you want to display. 2. Click the Share button for that location. 3. In the Share window, choose the Embed a map tab — not "Send a link." This tab generates an HTML iframe snippet, not a URL. 4. Click Copy HTML to copy the full iframe embed code. 5. Go to Left sidebar → Authority → Cloud Stacks and open the Cloud Stack you're editing (or start a New Cloud Stack). 6. Find the map/location field for the stack and paste the copied iframe embed code directly into it — do not paste a short link or full Google Maps URL here. 7. Save your Cloud Stack. ✅ How to Confirm It Worked After saving, reopen the Cloud Stack entry and check that the map preview renders visually (an embedded map, not an error message or blank field). If your Cloud Stack has a preview or view report option, use it to confirm the map displays correctly on the live output before considering the task complete. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 Blog Post Showing a Fatal Cache Error

This article explains what to do if your blog post is displaying a fatal cache error on your website. This type of error requires direct investigation by our support team to identify the root cause and guide you to the right resolution, as the fix will depend on your specific setup. What Is This Error? A fatal cache error on a blog post typically means something went wrong during the publishing or rendering process, and your site is unable to serve the post correctly. The exact cause can vary depending on your hosting environment, active plugins, and how the post was built. What to Have Ready Before Contacting Support Our support team will need to investigate your case directly. To help us resolve this as quickly as possible, please have the following information ready when you reach out: - The exact URL of the blog post showing the fatal cache error - The exact error message displayed on the page (copy and paste it if possible, or take a screenshot) - The date and time you first noticed the error - The name of your hosting provider - Any recent changes made to the post, your site's plugins, or your theme before the error appeared If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🖼️ Fix Website Images Not Showing in Browser

🔎 What This Issue Looks Like You open your website and the photos are gone. Instead you may see empty boxes, a small broken-image icon, or blank spaces where pictures used to be. This is alarming, but in many cases your images are still safe. The browser you are using is simply not loading them correctly. Common signs of a browser-related image problem include: - Images are missing in one browser but show up in another - Images appear on your phone but not on your computer (or the other way around) - Text and layout load normally, but only the pictures are missing - The problem began suddenly, with no changes made to your website 🧭 Why Images Stop Displaying Your browser stores temporary copies of website files so pages load faster. Sometimes these saved files become outdated or corrupted. Other times, a browser add-on or setting blocks images on purpose. The most common causes are: - Old cached data: The browser is showing a saved version of the page that has broken image links. - Ad blockers or privacy extensions: These tools can mistakenly block image files. - Browser settings: Images may be turned off for your site, or data-saver features may be active. - Outdated browser: Older versions can fail to load newer image formats such as WebP or AVIF. - VPN or network filters: Some connections block the server that hosts your images. ⚡ Step 1: Do a Quick Refresh Start with the simplest fix. A hard refresh forces your browser to download the page again instead of using saved files. 1. Open your website in the browser where images are missing. 2. On Windows or Linux, press Ctrl + Shift + R. On Mac, press Command + Shift + R. 3. Wait for the page to finish loading and check whether the images return. 🧹 Step 2: Clear Your Browser Cache If a hard refresh did not help, clear the saved files for your browser. 1. Open your browser settings and find the section for privacy or browsing data. 2. Choose the option to clear browsing data. 3. Select Cached images and files. You do not need to delete passwords or saved forms. 4. Set the time range to All time and confirm. 5. Close the browser completely, reopen it, and visit your website again. 🕵️ Step 3: Test in a Private Window A private (incognito) window loads your site without most extensions and without saved data. This helps you find out whether the problem comes from your browser setup. 1. Open a new private or incognito window. 2. Type in your website address and press Enter. 3. If the images show up, the issue is caused by your cache or an extension. Continue to the next step. 🧩 Step 4: Turn Off Extensions Ad blockers, privacy tools, and script blockers are the most common reasons images disappear in only one browser. 1. Open your browser extensions or add-ons page. 2. Temporarily turn off ad blockers, privacy tools, and any image or data-saving extensions. 3. Reload your website. 4. If the images return, turn extensions back on one at a time to find the one causing the problem. Then add your website to that extension's allow list. ⚙️ Step 5: Check Browser Settings Make sure your browser is allowed to show images on your site. - Open the site settings in your browser and confirm that Images is set to allowed or shown. - Turn off any lite mode, data saver, or battery saver features that may reduce image loading. - Make sure your browser is updated to the latest version. 🌐 Step 6: Try Another Browser, Device, or Network These quick checks help you confirm where the issue is coming from: - Open your website in a different browser such as Chrome, Firefox, Safari, or Edge. - Check the site on your phone using mobile data instead of Wi-Fi. - If you use a VPN, turn it off and reload the page. If your images display correctly in another browser or on another device, your website is fine and the issue is limited to your original browser. Repeat the steps above on that browser or reinstall it if needed. 🚨 When the Issue Is Not Your Browser If images are missing everywhere, including on other devices, networks, and browsers, the cause is likely on the website itself. Possible reasons include: - Image files were deleted or moved in your website's media library - A plugin, theme, or recent update changed how images load - Your hosting service is having a temporary problem - The image links point to an old address after a domain or site change Before you contact us, it helps to gather a few details so we can resolve things faster: - Your website address - The browsers and devices where you see the problem - Whether the images show in a private window or another browser - When you first noticed the images were missing - A screenshot of the page, if possible ✅ Tips to Prevent This in the Future - Keep your browser updated to the latest version. - Clear your cache from time to time, especially after making website changes. - Add your website to the allow list in any ad blocker or privacy extension. - Check your site in more than one browser after major edits. 💬 Need More Help? If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.

🔗 Internal Links Feature — Fixing Page Load Failures

Overview If the Internal Links update feature fails to load despite repeated attempts, this article explains what to do and what information to gather so the support team can resolve it quickly. What to Do When the Feature Won't Load Because page load failures in this feature can stem from account-level or backend causes that are not visible to the user, the most effective path to resolution is to escalate directly to the support team with the right details ready. Before reaching out, please gather the following information: - Your project name — the exact name of the project where the Internal Links feature is failing to load. - The exact error message — if any message appears on screen, copy it word for word. - When it started — note the date and approximate time you first encountered the issue. - What you have already tried — for example, refreshing the page or logging out and back in. Having this information ready when you contact support will allow the team to investigate and resolve your issue 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 a Stalled OTTO Recrawl

🔍 What Is a Stalled OTTO Recrawl? When OTTO recrawls your website, it audits your pages and generates updated SEO suggestions. A stalled recrawl occurs when the crawl remains in a processing state without completing or producing new results. ⚙️ How to Check Your Recrawl Status 1. Open the affected website in OTTO. 2. Review the displayed recrawl status and note whether it remains in a processing state. 3. Record the project or website name and how long the recrawl has been running. 🛠️ Steps to Resolve a Stalled Recrawl Refresh the page and check the recrawl status again. If it still has not completed, avoid repeatedly starting new recrawls and contact support with the affected project or website name, the current status, and the approximate time the recrawl began. 📊 What to Expect After the Fix If the recrawl remains stalled after refreshing the status, support can investigate the affected project and determine the next step. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 Site Still Inactive After Meta Tag Verification

✅ Verification vs. Activation: What's the Difference? Many customers add the meta tag, click verify, see a success message, and then notice their site still shows as inactive. This is expected in many cases, because these are two separate steps. - Verification confirms that you own the website. The meta tag proves you can edit the site's code. - Activation turns on the features for that site in your Search Atlas account. This may require an additional setup step or a short processing time. Verification is the first step, not the last. A verified site is ready to be activated, but it may not be live yet. 🔎 Why Your Site May Still Look Inactive These are the most common reasons a verified site still shows as inactive: - Status hasn't refreshed yet. The platform may need a few minutes to update after verification, and your browser may be showing an older view. - Setup isn't finished. Some features need an extra step after verification, such as installing a script, connecting a plugin, or completing the on-screen setup checklist. - Cached pages. If your website uses caching, the page may still serve the old version without your meta tag, or the new version may not be visible to everyone yet. - A different version of the domain. The tag may be on one version of your site (for example, with www) while the site was added to Search Atlas without it, or the other way around. - The tag was removed later. A theme update, a page builder change, or a plugin may have removed the meta tag after verification. 🛠️ Step-by-Step: How to Get Your Site Active 1. Refresh the platform. Reload the page or log out and back in. Wait 5 to 10 minutes, then check the site status again. 2. Look for remaining setup steps. Open your site's settings or dashboard in Search Atlas and check for any banners, checklists, or buttons such as Activate, Install, or Connect. Complete each one. 3. Confirm the meta tag is still on your site. Open your homepage in a browser, right-click, and choose View Page Source. Search for the word "meta" and find the Search Atlas verification tag. It should be inside the head section of your homepage. 4. Check the domain version. Make sure the address you added in Search Atlas matches the one that loads in your browser, including http vs. https and www vs. non-www. 5. Clear your site cache. If you use a caching plugin, a CDN, or a hosting-level cache, clear it. Then reload your homepage source and confirm the tag appears. 6. Try verifying again. After clearing the cache, return to Search Atlas and click verify once more. Then check the site status again. 💡 Tips to Avoid This Issue - Keep the verification meta tag in place. Do not remove it after verifying. - Paste the tag exactly as provided, with no extra spaces or missing characters. - Add the tag to the homepage head section, not the body or a sub-page. - Clear your cache any time you add or change code on your site. - Finish every item on the setup checklist in the platform before expecting the site to go live. ❓ Frequently Asked Questions My site says verified. Why isn't it active? Verification only proves ownership. Activation is a separate status that may need extra setup steps or a short processing time. How long does activation take? In most cases the status updates within a few minutes. If it hasn't changed after you complete the setup steps and refresh, follow the troubleshooting steps above. Should I remove the meta tag now that I'm verified? No. Leave it in place. Removing it can cause the site to lose its verified status. Can I ask the team to activate my site for me? Yes. If the steps above don't work, our team can review your site and help get it 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 instantly connected with a member of our team. To help us resolve things faster, include your website address and let us know which steps you've already tried.

🛠️ Fix WooCommerce SEO Metadata Errors

🔍 Understand the issue WooCommerce pages may be missing from Page Explorer or show outdated information when Search Atlas cannot successfully crawl them. Common causes include blocked URLs, redirects, noindex settings, duplicate product URLs, caching, or content that is rendered only after JavaScript loads. Incorrect SEO Suite data does not always mean that Search Atlas changed your website. It may reflect an earlier crawl, a different URL version, or metadata supplied by your WooCommerce SEO plugin. 🧭 Check the affected URL 1. Open the product, category, or shop page directly in your browser. 2. Confirm that the page loads without a login, password, or error. 3. Copy the exact live URL, including its HTTPS version and trailing slash. 4. Check whether the URL redirects to another page. The final destination is usually the URL that should be reviewed. 5. Confirm that the page is not marked noindex and is not blocked by robots.txt. ⚙️ Review WooCommerce settings In WordPress, review your SEO plugin and WooCommerce settings for the affected page type. Make sure product, category, shop, and tag pages have the intended index and canonical settings. Avoid assigning the same canonical URL to unrelated products or categories. Check that product titles, descriptions, and headings are present in the page editor. If a template generates these elements, confirm that the template uses the correct WooCommerce product fields. 🧹 Clear conflicting or outdated data 1. Save the affected product or page again, even if you made no changes. 2. Clear your WordPress, hosting, CDN, and browser caches. 3. Regenerate any SEO plugin metadata or sitemap files. 4. Temporarily check for conflicts between SEO plugins. Two plugins should not manage the same title, description, canonical, or robots settings. 5. Run a fresh crawl after the live page displays the correct information. ✍️ Prevent heading overwrites If a heading is changing unexpectedly, identify which system is writing it. Check the page source and compare it with the WordPress editor, your theme, WooCommerce templates, and any active SEO automation. Review active OTTO SEO recommendations before applying them. If an automated change is not desired, remove or disable that recommendation and restore the intended heading in WordPress or the relevant template. Keep one system responsible for each heading to prevent repeated changes. 📊 Use Search Atlas to verify the result Open AI SEO → OTTO SEO from the left sidebar. Review the available actions, including Scan, and check whether the page is included after the site is accessible and correctly configured. Compare the reported title, description, headings, canonical URL, and crawl status with the live page. If the page still does not appear, verify that the URL is included in your sitemap and that your site allows the Search Atlas crawler to access it. A page that is intentionally private, blocked, redirected, or set to noindex may not appear as an eligible SEO page. ✅ Troubleshooting checklist - The URL loads publicly and returns a successful status. - The final URL uses the preferred HTTPS and canonical version. - Robots.txt does not block crawling. - The page is not unintentionally set to noindex. - Product and category templates contain the intended headings. - Only one plugin or automation controls each SEO field. - Caches and generated metadata have been refreshed. - A new crawl has completed after the changes. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.

🛠️ Fix the Site Audit Recrawl Integer Required Error

🔍 What the Error Means When you try to recrawl a page in Site Audit, you may see a message that says integer required. In plain language, the platform expected a whole number (such as 5 or 120) but received something else, like a blank value, text, or a decimal. This usually happens when the recrawl request is not passed to the system correctly. This message does not mean there is a problem with your website, and it does not affect your existing audit results. It only means the recrawl request could not be processed. 🤔 Why It Happens The most common causes are: - The audit page was left open for a long time, and the session or page data became outdated. - The page you selected did not load fully, so the platform could not read its internal ID number. - A numeric setting, such as a page limit, was left empty or contains letters, spaces, or decimals. - A temporary glitch occurred while the request was being sent. - A browser extension or cached data interfered with the request. ✅ Quick Fixes to Try First Work through these steps in order. Most customers resolve the error within the first few. 1. Refresh the page. Reload Site Audit so the latest data is loaded, then try the recrawl again. 2. Re-select the page. Go back to the list of audited pages, choose the page again, and start the recrawl from there. 3. Check any number fields. If you see a field for a page limit or similar setting, enter a whole number only. Do not use decimals, commas, letters, or leave it blank. 4. Log out and back in. This refreshes your session and often clears request errors. 5. Clear your browser cache. Then reload the platform and try again. 6. Try another browser or a private window. This helps rule out extensions or stored data causing the problem. 🔄 Alternative Ways to Recrawl If the single-page recrawl still shows the error, you can try one of these options: - Start a new full audit of your site instead of recrawling one page. - Wait a few minutes and retry. If a crawl is already running, a new request may not be accepted until it finishes. - Make sure the page is still live and reachable. Pages that are redirected, removed, or blocked can cause unexpected request problems. 💡 Tips to Avoid the Error - Avoid leaving Site Audit open for many hours before running a recrawl. - Wait for the page list and results to fully load before clicking recrawl. - Use whole numbers only in any numeric field. - Keep your browser up to date and pause extensions that modify web pages, such as ad blockers or script blockers, if problems continue. 📋 What to Share If the Error Continues If none of the steps above work, gather the following details so our team can help you faster: - The URL of the page you tried to recrawl - The project or site name - The exact message you see on screen, or a screenshot - The browser you are using - The time the error occurred 💬 Need More Help? If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.

🔍 Fix Stale Site Diagnostics

🔍 Why your analysis may be outdated A site diagnostics analysis can remain unchanged when a scheduled scan has not started, is still processing, or was unable to complete. The date shown is the latest successfully completed analysis, not necessarily the date of the most recent attempt. Common causes include a paused project, an inactive schedule, changed project settings, temporary access issues, or a scan that is still in progress. 📅 Check the project and schedule 1. Open the affected project in Search Atlas. 2. Review the site diagnostics area and confirm the project is active. 3. Check that scheduled scans are enabled and that the next run is configured. 4. Verify the target domain is correct and accessible. ⚙️ Check for a recent scan Look for a scan that is processing, queued, failed, or completed. A completed scan should update the last analysis date. If a scan is processing, allow it to finish before starting another scan. If the schedule is active but no new analysis appears after the expected run time, refresh the page and review the scan status again. Scheduling can also be affected by the selected time zone or a recent project change. 🚀 Run a manual diagnostic If your project is active and no scan is running, start a manual diagnostic when that option is available. This can confirm whether the site can be scanned successfully while you investigate the scheduled run. - Use the correct domain and protocol. - Make sure the site is publicly reachable. - Check that security tools or access restrictions are not blocking the crawler. - Wait for the scan to finish before comparing the analysis date. ✅ When to request help Request assistance if the last successful analysis remains outdated after an enabled schedule should have run, repeated scans fail, or the project shows no scan status. Include the project name, domain, last analysis date, expected schedule, and any visible error message. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.

🛠️ Reset Playbook Cooldown After Errors

🚦 What causes the Playbook cooldown? OTTO may place a temporary cooldown on a Playbook after repeated redirect errors or unsuccessful actions. This protects your site from additional changes while the issue is reviewed. 🔍 Check the OTTO error first 1. Open AI SEO → OTTO SEO from the left sidebar. 2. Review the affected Playbook and its error details. 3. Confirm that the target URLs, redirect destinations, and site access are correct. 4. Fix any redirect loops, invalid destinations, missing pages, or conflicting rules on your site. 🔄 Request a cooldown reset Customers cannot manually override a Playbook restriction from the interface. After correcting the underlying redirect issue, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team. Include the project, affected Playbook, approximate failure time, and the error message. Our team can review the failure and determine whether the cooldown can be reset safely. 📊 Review possible crawl charges If repeated failures may have triggered multiple crawls, include the approximate dates and times in your message. Our team can review the related activity and explain any applicable usage or billing impact. Do not repeatedly retry the Playbook while the issue is being investigated. ✅ Prevent repeat failures - Test redirect destinations in a browser before retrying. - Check that URLs use the correct protocol, domain, and path. - Remove redirect loops and chains where possible. - Wait for the cooldown review before starting another Playbook run. - Keep the error details available so the issue can be diagnosed quickly. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.

🔑 Fix HighLevel Advanced SEO “Invitation Required” Error

🧭 Overview If HighLevel Advanced SEO shows an Invitation Required error, the issue relates to access through HighLevel Advanced SEO SSO. 🔍 How to Confirm the Issue 1. Open Advanced SEO from the affected HighLevel location. 2. Check whether the Invitation Required error appears. 🛠️ Steps to Resolve the Error 1. If the error appears, contact support for assistance with the HighLevel Advanced SEO SSO invitation. 2. When contacting support, provide the affected HighLevel location name, the exact Invitation Required message, and when the issue occurred. 📋 What Support Will Do Support can review the Invitation Required error and determine the appropriate next step. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.

🛠️ Fix Noindex Error When Submitting URLs

🔍 What This Error Means When you submit a URL or try to publish an article in the Publisher dashboard, the platform checks the page first. If the page contains a noindex instruction in its meta robots tag, the submission is blocked and you see an error. A noindex tag tells search engines not to include the page in search results. Because the purpose of publishing and submitting a URL is to get it found, a page that asks not to be indexed can't be accepted until the tag is removed. ❓ Why You May See It The noindex tag is usually added by your website or CMS, not by Search Atlas. Common causes include: - The page or post is still set to draft, private, or hidden in your CMS. - A site-wide setting such as Discourage search engines from indexing this site (WordPress) is turned on. - An SEO plugin (such as Yoast, Rank Math, or All in One SEO) has the page set to noindex. - The URL points to a staging, development, or test version of your site. - Your server sends a noindex instruction in the page's HTTP header (known as an X-Robots-Tag). - The page template, theme, or a custom code snippet adds a noindex tag. ✅ Step 1: Confirm the Tag Is on the Page 1. Open the URL you are trying to submit in your browser. 2. Right-click the page and choose View Page Source. 3. Press Ctrl+F (Cmd+F on Mac) and search for noindex. 4. Look for a line similar to meta name=robots content=noindex. If you find it, the tag is the cause of the error. If you don't find it in the page source, the instruction may be coming from your server header. Ask your web developer or hosting provider to check for an X-Robots-Tag set to noindex. ⚙️ Step 2: Remove the Noindex Setting The right fix depends on where the tag comes from. Start with the most common options: - WordPress site-wide setting: Go to Settings, then Reading, and make sure Discourage search engines from indexing this site is unchecked. Save your changes. - SEO plugin: Open the page or post in the editor, scroll to the SEO plugin section, open the advanced settings, and set the page to allow search engines to show it in results (index). - Draft or private pages: Change the page status to Published and the visibility to Public. - Other platforms (Wix, Shopify, Webflow, Squarespace): Open the page's SEO settings and turn off the option that hides the page from search engines. - Custom code or theme: Ask your developer to remove the noindex tag from the page template or header. 🔄 Step 3: Clear the Cache and Re-Check 1. Save and update the page in your CMS. 2. Clear any caching plugin, CDN, or server cache so the updated page is served. 3. Open the page source again and confirm that noindex no longer appears. 4. Return to the Publisher dashboard and submit the URL again. 🚀 Step 4: Resubmit in the Publisher Dashboard 1. Open the Publisher dashboard. 2. Paste the URL or select the article you want to publish. 3. Submit it again. If the error is gone, your submission will go through as normal. Changes can take a few minutes to appear, so wait briefly and try again if the error persists right after your update. 💡 Tips to Avoid This Error - Always publish the page on your site before submitting its URL. - Don't submit URLs from staging or test environments. - After launching a new site, double-check that search engine visibility is turned on. - Review your SEO plugin defaults, since some set new pages or certain page types to noindex automatically. - Make sure you are submitting the exact live URL, including the correct version (https and the right domain). 🛟 Still Seeing the Error? If the noindex tag is gone from the page source and you still can't submit the URL or publish your article, gather these details before contacting us so we can help faster: - The exact URL you are submitting - A screenshot of the error message - The platform your site is built on (for example WordPress or Shopify) - The steps you have already tried If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.

🔍 Why Crawl Monitoring Shows 404 URLs Crawled

📌 Overview You may open Crawl Monitoring and see URLs that do not exist on your website, such as pages that return a 404 (Not Found) status. This can look alarming, but it is common and usually easy to explain. This article covers why it happens, how to find the source, and what to do next. ❓ What Crawl Monitoring Is Showing You Crawl Monitoring records the URLs that crawlers request from your site and the response each request received. If a crawler asks for a URL and your server answers with a 404, that request is still logged. A 404 entry means the crawler tried to visit the address and your site correctly reported that no page exists there. It does not mean a real page was created or is missing from your site. 🧭 Why Non-Existent URLs Get Crawled Crawlers find URLs from many places, not only from the pages you see today. The most common sources are: - Old or deleted pages: Pages you removed, renamed, or moved in the past may still be remembered by search engines and other crawlers. - Outdated internal links: A menu, footer, blog post, or button may still link to a page that no longer exists. - External backlinks: Other websites may link to an old address or contain a typo in the link to your site. - Old sitemap entries: A sitemap that has not been updated can list pages that have since been removed. - URL variations: Differences in capitalization, trailing slashes, or added parameters (such as tracking tags) can create addresses that do not exist. - Script-generated links: Some themes, plugins, or scripts create link-like text that crawlers read as URLs, even though the pages are not real. - Automated probing: Some bots request common addresses (for example, admin or login paths) to test websites. These requests usually return a 404. - Pages that were never live: Staging, test, or draft URLs may have been exposed briefly and picked up. 🔎 How to Find Where the URL Came From Follow these steps to trace a 404 URL back to its source: 1. Open Crawl Monitoring and note the exact URL, including capitalization, slashes, and any parameters. 2. Open the URL in your browser. Confirm that it shows a Not Found page. 3. Search your website content, menus, and footer for that address or a similar one. 4. Check your XML sitemap to see whether the URL is listed. 5. Use a backlink tool to see whether another site links to it. 6. Check your recent site changes, such as a redesign, URL structure update, or plugin installation. 🛠️ How to Fix It The right fix depends on the cause and on whether the URL should exist. - The page was moved or replaced: Set up a 301 redirect from the old URL to the most relevant new page. - An internal link is broken: Update or remove the link so it points to a working page. - The sitemap is outdated: Regenerate it so it only includes live pages that return a 200 status. - The page should exist: Publish or restore it, then confirm it loads correctly. - The URL is a typo from another site: If it is a valuable link, add a redirect to the right page. Otherwise, you can leave it alone. - The URL was never real: Make sure it returns a proper 404 status and take no further action. ✅ When You Can Safely Ignore a 404 Not every 404 needs to be fixed. A 404 is the correct response for a page that does not exist. You can usually ignore it when: - The URL is random, spammy, or clearly generated by a bot. - The page was removed on purpose and has no close replacement. - The URL receives no traffic and has no valuable backlinks. - The number of 404 entries is small and stable over time. Search engines do not penalize a site simply for having 404 pages. The issue arises when important pages return 404 by mistake, or when your own site keeps linking to broken URLs. ⚠️ When to Take Action Quickly Look into the problem soon if you notice any of the following: - Pages that should be live are returning 404. - The number of 404 URLs suddenly rises after a site update or migration. - Many 404s share the same pattern, such as a missing folder or a broken parameter. - The URLs have backlinks or previously received organic traffic. - Your own pages link to the 404 URLs. 🔁 How to Prevent It in the Future - Set up 301 redirects whenever you delete, rename, or move a page. - Review internal links after any site redesign or URL change. - Keep your sitemap clean and up to date. - Use consistent URL formats, including lowercase and a single trailing-slash style. - Check Crawl Monitoring regularly so you can catch unusual spikes early. 💬 Need More Help? If you still see URLs you cannot explain, send our team the exact URL, the date it appeared, and what you have already checked. This helps us review it faster. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.

🔭 Site Explorer Bug Fixes and Accuracy Improvements

🛠️ Fixing Publisher Placement Validation Errors

🔍 What This Error Means When you submit a published article for a publisher placement, Search Atlas checks the live page to confirm it is ready to deliver SEO value. If the check fails, the article will not be accepted, even if the page looks fine in your browser. The two most common reasons are: - Noindex: the page tells search engines not to include it in their results. - Missing anchor: the page does not contain the expected link (the anchor text pointing to your target URL). Because both problems are invisible when you simply read the article, they are easy to miss. 🎯 Why These Checks Exist A link on a page that search engines cannot index passes little or no value. A page without the agreed link does not fulfil the placement. Validation protects your campaign so you only accept placements that actually work. ✅ Quick Checklist Before You Resubmit - The article is published and publicly visible, not a draft, preview, or password-protected page. - The URL you submitted is the final live URL, with no redirects or tracking parameters. - The page does not contain a noindex directive. - The article contains a clickable link to your target URL with the correct anchor text. - The link is part of the page content itself, not added later by a script. 🚫 How to Check and Fix a Noindex Problem A noindex directive can appear in a few places. Check each one: 1. Open the live article in your browser and choose View Page Source. 2. Search for the word noindex. If you find it inside a robots meta tag, the page is blocked from indexing. 3. Check the page's HTTP headers for an X-Robots-Tag: noindex value. A developer or the site's hosting settings can tell you if this is set. 4. Look at the site's SEO plugin or CMS settings. Common causes include a post-level option such as Allow search engines to show this post turned off, or a sitewide setting that discourages search engines. 5. Check whether the article sits in a section of the site that is set to noindex by default, such as a staging area, a tag archive, or a category used for sponsored content. Once the directive is removed, save the change, clear any site cache, and confirm in the page source that noindex is gone before you resubmit. Note: If the publisher controls the website, you may need to ask them to change the setting. Share the exact URL and tell them the page must be indexable. 🔗 How to Check and Fix a Missing Anchor If validation says the anchor is missing, the checker could not find the expected link in the page. Work through these points: - Confirm the link exists. Open the live article and look for the anchor text. Click it to check that it opens your target page. - Match the anchor text. The wording should match what was agreed for the placement. Small changes in spelling or wording can cause a mismatch. - Match the destination URL. Check for differences such as http versus https, www versus non-www, or a missing trailing slash. - Use a real link. The link should be a standard text link in the article body. Links added only by JavaScript, buttons, or images without text may not be detected. - Check the live version. Some editors save the link in a draft but strip it when the article is published. View the published page, not the editor preview. - Look for caching. If you just added the link, the public page may still show an older version. Clear the cache and reload. 🔁 How to Resubmit the Article 1. Fix the noindex directive, the missing anchor, or both on the live page. 2. Reload the live URL in a private browser window to confirm that you see the changes. 3. Return to the platform and submit the final live URL again. 4. Wait for validation to finish. If it passes, the placement will move forward. ⚠️ Common Mistakes to Avoid - Submitting a draft or preview link instead of the public URL. - Submitting a URL that redirects to a different page. - Assuming the page is indexable because it appears in your browser. Noindex is hidden in the code. - Editing the link wording after the article is live without updating the placement details. - Resubmitting repeatedly without changing anything. The result will be the same until the page is fixed. 💡 Tips to Prevent This in the Future - Before submitting, view the page source and search for noindex. - Always click the link in the live article to confirm it goes to the correct page. - Share the target URL and exact anchor text with the publisher in writing. - Ask publishers to confirm the article is set to be indexable before it goes live. 💬 Still Seeing the Error? If the page is indexable, the anchor is present, and validation still fails, there may be another issue such as a block on the checker or a delay in the page updating. Have the article URL and a short description of what you have already checked ready. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.

🛠️ Fix Publication Media Site Activation Failed

You added your site to Publication Media and placed the verification meta tag, but the site still shows as not active. You may also be wondering what the URL quality grade next to your site means. This article explains why activation can fail, how to fix it, and how to read your grade. 🔍 What Site Activation Does Before a site can be used in Publication Media, Search Atlas needs to confirm that you own or control it. You do this by adding a small verification meta tag to your website. Once the platform finds the tag, the site can be activated. If the tag can't be found, the site stays inactive or shows an activation failed message. ⚠️ Common Reasons Activation Fails In most cases the tag was added, but the platform can't see it. These are the most common causes: - Wrong location: The tag must be in the head section of your homepage, not in the body or a footer block. - Wrong page: The tag was added to an inner page or a blog post instead of the homepage URL you entered. - URL mismatch: The URL in Search Atlas doesn't match your live site. For example, you entered the non-www version, but your site redirects to the www version (or the reverse), or you entered http instead of https. - Cached page: Your website, CMS, or CDN is still serving an older copy of the page without the tag. - Tag edited or incomplete: A character was dropped when copying, or the editor changed the quotation marks. - Blocked access: A firewall, security plugin, or bot protection is preventing our system from reading your page. - Tag removed by your platform: Some themes, builders, or optimization plugins strip or rewrite custom tags in the head section. ✅ How to Fix an Activation Failure 1. Open your site's homepage in a browser, right-click, and choose View Page Source. 2. Search the page (Ctrl+F or Cmd+F) for the word meta and look for the Search Atlas verification tag. 3. Confirm the tag appears between the opening and closing head tags, and that it matches the one shown in your Search Atlas account exactly. 4. If the tag is missing, add it again using your CMS's header or custom code settings, then save and publish the change. 5. Clear all caches, including your CMS cache, caching plugin, and CDN, so the updated page is served. 6. Check that the URL you entered in Search Atlas is the same one your site loads when you visit it in a browser, including https and www. 7. Return to Search Atlas and run the activation check again. Allow a few minutes after clearing caches. 🧩 Tips for Specific Setups - WordPress: Use a header and footer code plugin or your SEO plugin's webmaster verification or custom head code setting. Then clear your caching plugin. - Website builders: Look for a custom code or header code area in your site settings. Some plans limit custom code, so check your plan if you can't find it. - Custom or older sites: Edit the shared header file or template so the tag appears on the homepage. Make sure you are editing the live file, not a copy. - Sites behind a firewall or security service: Make sure automated visitors aren't being blocked from loading your homepage. 📊 What the URL Quality Grade Means The URL quality grade is a quick rating that shows how strong a site looks as a publishing location. In general, it reflects signals such as the site's overall authority, content quality, and search visibility. A higher grade suggests a stronger, more trusted site. A lower grade suggests the site has fewer of these signals. A few important points: - The grade and activation are separate. A low grade doesn't mean your meta tag is wrong, and a high grade doesn't activate a site on its own. - The grade can change. As your site grows, gains traffic, and publishes quality content, its grade can improve over time. - It's a guide, not a penalty. Use it to compare sites and decide where to focus your efforts. 🚀 How to Improve Your Site's Quality Signals - Publish original, useful content on a regular schedule. - Make sure your important pages can be crawled and indexed by search engines. - Fix broken pages, redirect loops, and slow-loading pages. - Earn relevant links from trusted websites in your niche. - Keep your site secure with https and up-to-date software. 💬 When to Contact Support If you've confirmed the tag is in the head section of your homepage, cleared your caches, and the site still won't activate, our team can take a closer look. Have these details ready: - The exact site URL you entered in Search Atlas - A screenshot of the activation error - The URL quality grade you see for the site - The CMS or website builder you use If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.

🛡️ Fix SiteGround Robot Challenge Blocking OTTO

🔍 What Is Happening If your website is hosted on SiteGround and OTTO shows a Robot Challenge Screen instead of your real page, SiteGround's Anti-Bot protection is likely stopping the OTTO crawler. The crawler is treated like an unknown automated visitor and is shown a CAPTCHA it cannot solve. This is a server-side setting on SiteGround's network, not an error in your Search Atlas account or your website content. ⚠️ Why It Matters OTTO needs to read your pages to analyze them and apply optimizations. When the crawler is challenged, you may notice: - OTTO reports a Robot Challenge Screen or a CAPTCHA page as your site's content - Pages fail to scan or show incomplete data - Optimizations cannot be verified or deployed on affected pages - The issue shows up on several sites at once if they share the same SiteGround hosting ✅ How to Confirm the Cause 1. Open one of the affected pages in your browser. Normal visitors will usually see the page without any challenge. 2. Check whether the site is hosted on SiteGround. Your hosting dashboard or a hosting lookup tool will show this. 3. Look at what OTTO is reporting for the page. If the page text mentions a robot challenge, security check, or CAPTCHA, the crawler is being blocked. 4. Check whether the problem affects only SiteGround-hosted sites. If sites on other hosts work fine, SiteGround's protection is almost certainly the cause. 🛠️ How to Fix It The fix is to ask SiteGround to allowlist the OTTO crawler so it is no longer challenged. Follow these steps: 1. Gather the crawler details. You need the OTTO crawler user agent and, if available, the IP addresses it uses. If you do not have these, open the chat widget in the platform and ask for the current OTTO crawler details. 2. Send an allowlist request to SiteGround. Ask them to exempt the OTTO crawler from Anti-Bot protection for your domain or account. Include every affected domain in one request. 3. Wait for confirmation. Once SiteGround confirms the change, the crawler should no longer see the challenge screen. 4. Re-run the scan in OTTO. Trigger a fresh crawl of one affected page and confirm OTTO now reads your real content. 📝 Sample Message for SiteGround You can copy and adapt the message below: Hello, my websites (list your domains) are being blocked by the Anti-Bot AI CAPTCHA, which shows a Robot Challenge Screen to a legitimate SEO crawler used by Search Atlas OTTO. Please allowlist the OTTO crawler user agent and IP addresses (details below) so it can access my sites without a challenge. Thank you. Add the user agent and IP details you received before sending. 💡 Tips to Avoid Repeat Issues - Request the allowlist for all domains on your SiteGround account, not just the first one you noticed. - If you add new sites on SiteGround later, ask for the same exemption to be applied to them. - Do not disable all security features on your site. A targeted allowlist for the OTTO crawler is safer and just as effective. - If you also use a CDN or firewall plugin, check that it is not challenging the crawler as well. - Keep a record of the request in case the block returns after a hosting update. 🔄 If the Challenge Still Appears If the Robot Challenge Screen still shows after SiteGround confirms the change, try the following: - Wait a short time and run a new crawl, as server changes can take a while to apply. - Confirm that the user agent and IP details you sent are the current ones. - Check that the allowlist covers every domain and subdomain affected. - Make sure no other security layer, such as a firewall plugin or CDN rule, is also blocking the crawler. 💬 Need More Help? If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team. Please have your affected domain names ready, and mention that the sites are hosted on SiteGround, so we can help you faster.

🛠️ Fix Publication URL Field Not Accepting Input

🔍 What This Issue Looks Like When you click Add Publication, you may find that the Publication URL field is greyed out, won't let you type, or won't accept pasted text. This is usually caused by something in your browser or by how the URL is entered. It is rarely a problem with your account. The steps below fix most cases. 🤔 Common Causes - The page did not fully load, so the form is not yet interactive. - A browser extension, such as an ad blocker, password manager, or autofill tool, is interfering with the form. - Cached data in your browser is causing the form to behave incorrectly. - The URL has extra spaces, an unsupported format, or was pasted with hidden characters. - The form is waiting for another required field to be completed first. ⚡ Quick Fixes to Try First 1. Refresh the page. Close the Add Publication window, reload the page, and open the form again. 2. Click directly inside the field. Make sure the cursor is active in the Publication URL box before you type or paste. 3. Type the URL instead of pasting it. If pasting does not work, type it manually. If typing does not work, try pasting. 4. Check for other required fields. Fill in any other fields in the form, such as the publication name, then return to the URL field. 5. Try a private or incognito window. Log in to the platform there and try again. If it works, the cause is likely a browser extension or cached data. 🌐 Enter the URL in the Right Format Even when the field accepts text, an incorrectly formatted URL can be rejected. Follow these tips: - Include the full address starting with https:// (for example, https://www.yourwebsite.com). - Remove any spaces before or after the URL. - Use only the main site address, not a link to a specific page or a link with tracking parameters. - Check for typos in the domain name. - If you copied the URL from a document or email, paste it into a plain text editor first, then copy it again to remove hidden formatting. 🧹 Clear Your Browser Cache and Disable Extensions If the quick fixes did not work, try these steps: 1. Clear your browser cache and cookies for the Search Atlas platform, then log in again. 2. Temporarily turn off browser extensions, especially ad blockers, autofill tools, and password managers. 3. Reload the platform and try adding the publication again. 4. If you have turned off extensions and the field still does not work, try a different browser such as Chrome, Firefox, Edge, or Safari. 📱 Check Your Device and Screen - Use a desktop or laptop computer if you are on a phone or tablet, since some forms are easier to use on a larger screen. - Make sure your browser is up to date. - If the form looks cut off, zoom out (Ctrl and minus on Windows, Cmd and minus on Mac) so the whole form is visible. - Check that your internet connection is stable, then reload the page. ✅ Confirm the Site Was Not Already Added Before trying again, check your existing publications list. If the site is already there, you may not need to add it again. If you need to update it, open the existing entry instead of creating a new one. 📝 Information to Share If the Problem Continues If none of the steps above resolve the issue, collect the following details so our team can help you faster: - The browser and version you are using. - Whether the problem also happens in an incognito window or a different browser. - The URL you are trying to add. - A screenshot of the Add Publication form showing the field. - Any error message that appears on the screen. 💬 Need More Help? If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.

🛠️ Why Your Publisher Site Shows Inactive After Verification

🔍 What This Issue Looks Like You added a site as a publisher and completed the verification step, but the dashboard still shows the site as Inactive. You may also be unsure whether the site was approved, rejected, or deactivated. This is a common point of confusion. Verification and approval are two separate steps, and a site must pass both before it can show as active. 🧭 Verification vs. Approval: What's the Difference? - Verification confirms that you own or control the site. It usually involves proving access to the domain or site. - Approval is a review of the site itself. It checks that the site meets our publisher quality and eligibility requirements. A site can be verified and still show Inactive if it hasn't been approved yet, or if it didn't pass review. ❓ Common Reasons a Site Shows Inactive - Approval is still pending. The site is verified but hasn't finished review. - Verification is incomplete. The verification step may not have been detected, for example because of a typo in the domain, a missing file or tag, or a change that was never saved or published. - The site doesn't meet quality requirements. Sites with very little content, low-quality or copied content, or an unreliable or inaccessible website may not be approved. - The site was deactivated. A site can be deactivated if it stops meeting requirements, becomes unreachable, or its status changes after review. - The dashboard hasn't refreshed. Sometimes the status is correct on our side but an old version of the page is still displayed. - A duplicate or mismatched entry. The same site may have been added more than once, or with a different version of the domain (for example with and without www). ✅ Steps to Check Before Contacting Us 1. Open your publisher site list in the platform and find the site. Confirm the domain is spelled exactly as it should be. 2. Check the site's status label. Note whether it says Inactive, Pending, Rejected, or something else. 3. Refresh the page, or log out and back in, to rule out a display delay. 4. Confirm the verification step is still in place. If you added a file, tag, or code to your site, make sure it hasn't been removed by a site update, plugin, or cache clean-up. 5. Open your website in a browser and check that it loads properly, with no errors, password protection, or blocks on public access. 6. Check that the site has original, useful, publicly available content that follows our publisher requirements. 7. Check that you haven't added the same site more than once under slightly different addresses. 🔄 What to Do If Verification Failed or Was Removed 1. Re-run the verification step from the site's settings in your dashboard. 2. Make sure any required changes are saved and live on your website. If you use a caching plugin or CDN, clear the cache first. 3. Wait a short time and refresh the dashboard to see if the status updates. ⏳ What If the Site Is Pending Approval? If verification is complete and the site shows as pending or inactive without any rejection notice, it is most likely still in review. In this case, there is usually nothing you need to change. Avoid removing the site and re-adding it, because this can reset the review and cause further delays. 🚫 What If the Site Was Deactivated or Not Approved? If you see a deactivation or you believe the site was changed to Inactive without your action, the reason depends on the specific review of that site. Common causes include content quality, site accessibility, or eligibility requirements. We can't tell the exact reason from the status label alone, so a team member needs to look at the site's review details to confirm it. If the site was not approved, you may be able to improve it and request another review. Typical improvements include: - Adding more original, high-quality content - Fixing broken pages, errors, or slow loading - Making sure the site is publicly accessible - Removing spammy or irrelevant content 💬 What to Tell Us When You Need Help To get a faster answer, have the following ready when you contact us: - The exact domain of the site - The status you see in the dashboard - When you completed verification - Whether you saw any notice about deactivation or rejection - Any changes you made to the site recently If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team. 💡 Tips to Avoid This in the Future - Keep the verification element on your site permanently unless told otherwise. - Make sure your site stays online and publicly accessible. - Maintain regular, original content on the site. - Add each site only once, using its main version of the domain. - Check your dashboard status after changes to your site, such as a redesign, migration, or plugin update.

🔍 Fixing the AI Crawler Warning on Simvoly

🔎 What the Warning Means Site Audit reads your robots.txt file, a small text file that tells bots which parts of your site they may visit. If the file blocks AI and LLM crawlers (the bots used by tools like ChatGPT, Claude, Perplexity and Google's AI features), Site Audit shows a warning. This is a warning, not an error. Your site still works and can still rank in regular search results. The warning only tells you that AI tools may not be able to read your content, so your pages are less likely to be cited in AI-generated answers. 🤖 Which Crawlers Are Usually Involved These are the AI-related bots most often blocked in robots.txt files: - GPTBot, OAI-SearchBot and ChatGPT-User (OpenAI) - ClaudeBot, Claude-User, Claude-SearchBot and anthropic-ai (Anthropic) - PerplexityBot and Perplexity-User (Perplexity) - Google-Extended (Google's AI products) - CCBot, Bytespider, Applebot-Extended, cohere-ai and Amazonbot (other AI and data-collection bots) 🧐 How to Spot the Problem in Your robots.txt Open your robots.txt by typing your domain followed by /robots.txt in your browser, for example yourdomain.com/robots.txt. Look for a bot name on a line that starts with User-agent:, followed by a line that says Disallow: /. That combination means the bot is blocked from your whole site. Also check for a general rule that applies to every bot. A line reading User-agent: * followed by Disallow: / blocks everything, including AI crawlers and search engines. If you see this, fix it first, because it can hurt your regular search visibility too. 🛠️ How to Fix It on Simvoly Simvoly builds and manages your robots.txt, so the change is made in Simvoly, not in Search Atlas. The exact menu names can change as the builder updates, so use these steps as a guide: 1. Log in to your Simvoly account and open the website you want to change. 2. Go to the site-level Settings and look for the SEO area or a robots.txt option. 3. Open the robots.txt content. If an editor is available, you can change it directly. 4. Find each AI bot you want to allow. Delete its User-agent and Disallow: / lines, or change Disallow: / to Allow: /. 5. Leave any rules for private areas (such as admin or checkout pages) in place. 6. Save the change and publish your site so the new file goes live. 7. Reload yourdomain.com/robots.txt in your browser and confirm the update appears. If you can't find a robots.txt editor in your Simvoly plan, or the file keeps reverting after you save, the blocking rules may be added by a Simvoly default or a setting on your domain provider or CDN. In that case, check those settings, or reach out through our chat widget (details below) and share your robots.txt so we can point you in the right direction. ⚖️ Should You Allow AI Crawlers? It depends on your goals. Allowing them is usually a good idea if you want your brand and content to appear in AI answers and AI search results. Blocking them may make sense if you don't want your content used to train AI models. You can also take a middle path. Many sites allow AI search and citation bots (such as OAI-SearchBot, Claude-SearchBot and PerplexityBot) while blocking training bots (such as GPTBot or Google-Extended). If you choose to keep some blocks, the warning will stay in your audit. You can treat it as informational. ✅ Re-Run Your Site Audit 1. After publishing the change, confirm the live robots.txt shows your updates. 2. Open Site Audit in Search Atlas and start a new crawl. 3. Check the results once the crawl finishes. The warning should be gone if all AI crawlers are now allowed. If the warning still appears, the audit may have used an older copy of your file. Wait a short while, then run it again. 📇 Can You Update a Directory Listing After It's Published? Yes. Business information on directories such as Data Axle can be corrected after it is published, for example your business name, address, phone number, website or hours. A few things are worth knowing: - Updates go through the source. Each directory has its own process, so the change is usually submitted again to that directory rather than edited live on the page. - Changes are not instant. Directories and the sites that copy their data can take days or weeks to show new details. - Keep details consistent. Use the exact same name, address, phone number and website everywhere so search engines and AI tools see one clear version of your business. - Check your website link. If your site address or settings changed, update the listing so it points to the right place. To make a change, open the listing in your Search Atlas account, update the details and resubmit it if the option is available. Some directories limit which fields can be edited or how often. If you can't edit a listing, let us know which directory and which detail you want to change. 💬 Need More Help? If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.

🔍 Fixing Find Publishers Not Responding in Site Catalog

🔍 What Find Publishers Does In the Site Catalog, the Find Publishers button takes the site you are working on and searches for publishers that fit it. It does this by applying the Relevant for filter automatically, so your results focus on publishers that match your site's topic instead of the full catalog. When it works, the publisher list refreshes and the Relevant for filter shows your site as selected. ⚠️ What You Might See Some customers report that clicking Find Publishers appears to do nothing. Typical signs include: - The page does not change and the publisher list does not refresh. - The Relevant for filter is not filled in. - No loading indicator appears after you click. - If you open your browser's developer tools (for example, Chrome DevTools), the Console tab shows: Uncaught TypeError: Cannot set properties of null (setting 'value'). 🧠 Why This Happens That console message means the page tried to fill in the Relevant for field before that field was ready on the screen. The search then stops before it starts, which is why nothing happens and no publisher search is sent. This can be caused by: - The page not having fully finished loading when you clicked the button. - An outdated copy of the page stored in your browser (cached files). - A browser extension, such as an ad blocker or privacy tool, interfering with the page. - No site or project being selected, so the filter has nothing to apply. - An issue on our side with the page itself, which our team needs to look into. ✅ How to Fix It Work through these steps in order. Most customers are back up and running after the first few. 1. Confirm your site is selected. Make sure the correct site or project is chosen in the platform before opening the Site Catalog. 2. Wait for the page to finish loading. Let the Site Catalog and its filters fully appear, then click Find Publishers once. 3. Refresh the page. Reload the Site Catalog and try again. 4. Do a hard refresh. On Windows or Linux press Ctrl + Shift + R. On Mac press Cmd + Shift + R. This forces your browser to load the latest version of the page. 5. Clear your browser cache. In your browser settings, clear cached images and files, then sign in again if asked. 6. Try a private or incognito window. If Find Publishers works there, an extension or stored data is likely the cause. 7. Turn off extensions. Temporarily disable ad blockers, privacy tools, and script blockers, then reload the page. 8. Update or switch browsers. Make sure your browser is up to date, or try another current browser such as Chrome, Edge, or Firefox. 🛠️ A Workaround While You Wait If Find Publishers still does not respond, you can apply the filter yourself: 1. Open the Site Catalog. 2. Find the Relevant for filter. 3. Select your site manually. 4. Apply the filters to see matching publishers. If the Relevant for field is missing or will not open, that is useful information for our team, so make a note of it. 📋 What to Share If the Issue Continues If the steps above do not help, our team may need a few details to investigate quickly. Having these ready will save time: - The site or project you were working in. - The browser and version you use, and whether you are on Windows or Mac. - Whether the problem also happens in an incognito window. - A screenshot of the Console tab in DevTools showing the error message. - The steps you took right before clicking Find Publishers. To open the Console in Chrome, right-click the page, choose Inspect, and then select the Console tab. 💡 Tips to Avoid This in the Future - Keep your browser updated. - Let pages fully load before clicking action buttons. - Refresh the platform after a long period of inactivity. - Allow the Search Atlas platform in your extension settings if you use an ad blocker. 💬 Need More Help? If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.

🛠️ Fixing the Server Compression Warning on GHL

🔍 What the Warning Means The Site Audit flag Server compression not enabled means a page, script, or stylesheet was delivered without being compressed (usually with Gzip or Brotli). Compressed files are smaller, so pages load faster and use less bandwidth. Faster pages support better user experience and SEO performance. The audit reports the problem but cannot see how your site is hosted, so it does not tell you where the fix has to happen. 🧭 Why GHL Sites Are Different Compression is set on the server that delivers your pages, not at your domain registrar or DNS provider. A site built in GoHighLevel (GHL) is delivered from GHL's servers. That has two practical effects: - You normally cannot edit server settings such as compression rules inside GHL, as you could on your own hosting account. - Changing DNS records at another provider, such as Hostinger, does not switch compression on. DNS only tells browsers where to find your site. It does not change how the files are sent. If your domain is registered or managed at Hostinger but your site is built and hosted in GHL, Hostinger's hosting and compression settings do not apply to your GHL pages. ✅ Step 1: Check Whether Compression Is Actually Active Sometimes the warning is triggered by one file rather than the whole site. Confirm what is really happening before making changes: 1. Open the affected page in Google Chrome. 2. Right-click anywhere on the page and choose Inspect, then open the Network tab. 3. Refresh the page. 4. Click the main page file (the first item in the list) and open the Headers section. 5. Under Response Headers, look for content-encoding. If it shows gzip or br, that file is compressed. 6. Click a few of the larger script and stylesheet files and repeat the check. 1. Create an account with the CDN or proxy provider and add your domain. 2. Copy your current DNS records from Hostinger and save them somewhere safe. This is your backup. 3. Recreate the same records in the CDN provider, making sure the records that point to GHL stay exactly as GHL instructs. 4. Update the nameservers at Hostinger to the ones the CDN provider gives you, if the provider requires it. 5. Enable compression in the CDN settings (often called Gzip or Brotli). 6. Wait for DNS changes to take effect, which can take a few hours, then confirm your site loads correctly and the SSL certificate is valid. - Compress images before uploading them, and use modern formats such as WebP where possible. - Remove unused sections, large videos, and animations. - Limit custom code, plugins, and third-party widgets. - Avoid uploading large PDF or media files that are embedded directly on the page. - Your main page is already compressed: No action is needed. The warning is likely caused by third-party files. - Your page is not compressed and you want to fix it: Use the CDN or proxy method in Step 2. Since your DNS is at Hostinger, you would make the change there, either by updating nameservers or the records the CDN asks for. - You prefer not to change DNS: Focus on Step 3 to reduce page size and improve speed. If the main page is compressed and only a few third-party files are not, the warning is low risk. Those files are usually served by other companies, such as tracking or chat tools, and you cannot change how they are delivered. 🌐 Step 2: Add a CDN or Proxy in Front of GHL (Optional) If your pages are not being compressed and you want to control this yourself, the usual approach is to place a content delivery network (CDN) or proxy service, such as Cloudflare, between visitors and GHL. These services can compress files before delivering them. Because your DNS records are managed at Hostinger, this path involves changes at the DNS level: Important: A mistake in DNS can take your site offline or break your GHL domain connection. Always keep a backup of your original records, and make changes during a quiet period. If your CDN has a proxy mode, test your GHL domain verification and SSL after any change. ⚡ Step 3: Reduce Page Weight Inside GHL Even if you cannot control server compression, you can make your pages lighter so the warning matters less: 🔄 Step 4: Re-run Your Site Audit After making changes, clear your browser cache and run a new audit in Search Atlas. If the warning remains, check the Network tab again to see which files are still uncompressed. ❓ Which Option Should I Choose? If you were given a numbered list of options and are not sure what Option 2 refers to for your setup, our team can confirm the best choice for your specific site before you change any DNS records. 💬 Need More Help? If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.